Voices in Cloud – Episode 11: A Conversation with Randy Bias of the OpenStack Foundation

Guest

Randy Bias is an entrepreneur, writer, speaker and futurist in cloud computing. He accurately predicted the geometric growth rate of AWS, is an advocate for open source technology and was among the first to identify the 30-year shifts from mainframe to client/server to cloud. Randy popularized the pets vs. cattle meme as a construct for describing the fundamental difference between how enterprise stacks and cloud stacks are managed.

Randy is a pioneer and early, vocal advocate for the OpenStack project, and has led teams that achieved numerous cloud firsts, including the first public cloud in Korea, the first global carrier NFV cloud, and the first “cattle cloud” for a Fortune 5 company. As a strategic R&D lead at Dell EMC, Randy led the open sourcing of several products, and today serves as Vice President Technology and Strategy, Cloud Software at Juniper Networks.

Transcript

Dave Linthicum: Hey guys, welcome to the GigaOm Voices in Cloud podcast. This is the one place where you can hear from industry thought leaders providing no-nonsense advice on how to succeed with cloud computing, IoT edge computing, and cognitive computing. I’m Dave Linthicum, best-selling author, speaker, and executive, and B-List geek. And this week, my special guest is Randy Bias, good friend of mine. Randy is a recognized influencer in cloud computing, an entrepreneur, writer, speaker, futurist. Randy accurately predicted – I love this, Randy – predicted the geometric growth rate of AWS. He is an advocate for open source technology as a foundational business model element company traditionally tied to proprietary models. Notably, Randy has initiated and led successful open sourcing efforts for several traditional ISVs, independent software vendors. He has been declared a top-10 cloud pioneer by Information Weeks Digital Influencer by Forbes. I hope I got through that okay. Sofill us in, Randy. I haven’t talked to you in like three, four years. What you been doing since then?

Randy Bias: Has it really been that long, Dave?

Yeah, it was before Cloud Technology Partners got sold.

Wow, it doesn’t seem like it’s been quite that long. I mean, I feels like it’s been that long but...

I’ve known you since 2003, so that’s been 16 years, believe it or not. The years are running together. We’re getting to be old men, old cloud men.

Yeah, old cloud men. Yeah, I’ve just been most recently working for Juniper Networks, where I have been helping them really figure out their open source models. They are really transitioning, like a lot of the industry, from being exclusively a hardware company to really a hardware and software company. And as we all know, there’s sort of an ongoing shift towards open source first strategies for most enterprises. And so, Juniper’s trying to meet that need with their open source software called Tungsten Fabric, which is nested controller. And I’m one of the folks that’s driving open source strategy across Juniper and helping them with being a better open source company.

That’s awesome, and you’ve been there for a while now. Hasn’t it been like four or five years?

It’s coming up on three years, actually.

Wow, that’s great man. Congratulations on the success there. So, what are they working on besides the open source stuff that you’re leading?

To be honest, a lot of it’s not really the interesting stuff. It’s sort of the nuts and bolts of, how do we make sure that we consume open source software in the right ways, consume the right licenses? How do we contribute back in the right ways? How do we manage our risks? Just the real kind of big company-type pieces – that, for me, hasn’t been the interesting part. The interesting part’s really been on the Tungsten Fabric side, where we had to take a piece of software that we had launched as open source that was Contrail, which became OpenContrail. And then, we realized that we hadn’t really done it in a way that was sort of the standards and best practices, so we relaunched or rebooted the community, rebranded OpenContrail to Tungsten Fabric, put Tungsten Fabric into Linux Foundation, and then have been going through all of the work of aligning Juniper to be a better open source contributor.

That’s just a really sort of much more drawn-out process than I would expect. It’s not a startup, right? There’s all this momentum. There’s a lot of relearning and building new muscle memory around how you run an open source community, how you contribute to the open source software, and how can you be a good participant, not just sort of the one dominant contributor in the room.

Speaking of open source, you got one topic that I’m really interested in talking about. Has OpenStack finally found itself? You and I, I think in all the podcasts we’ve done, and there’s been probably a dozen in the last ten, fifteen years, have talked about kind of open source stuff, the emerging cloud market, and then more lately, kind of the OpenStack market and where things are going. You were kind of a leader in that space when it first came out, but also, I think you’re productively critical, in terms of where OpenStack needed to go. I think you turned out to be right. But, has it finally found itself, Randy?

I personally don’t think so. I know some folks that are still sort of in that ecosystem that do believe that there’s an opportunity to complete this pivot. For those that aren’t paying a lot of attention, right, you had the OpenStack foundation, which is doing all these OpenStack summits twice a year, and the big boom and hype cycle. Then a year or two ago, they started this kind of very subtle pivot where they created a whole new governance structure and technical governance structure called Open Infrastructure, and really have been trying to become the Open Infrastructure Foundation. They launched with somebody called Kata Containers. What they are doing is they’re side-stepping the mess that really got made in OpenStack land because there are real problems, real structural problems with the way that the board and the TC operated, the way that they interacted, and the way the developers – the culture that sort of rose in that OpenStack developer community. They kind of tried to make a whole new community with Kata Containers, but I sort of feel like it’s too little, too late.

I mean, Kubernetes has already risen to the top. A lot of the Kubernetes ecosystem is very active, and then it’s not really talked about very much, but there’s a certain amount of tension between some of these foundations. I do think that the OpenStack folks are more sort of predisposed to play nice with others, but not all the other foundations necessarily want to play nice with each other in open source land, which is sort of a shame because we’re all in it together, in terms of building public comms that are good for everybody.

Yeah, I noticed that open source groups – they have a tendency to have some distrust of each other, even though they’re all really kind of moving after the open source stuff. Some of the research I did, and certainly if you’re talking about OpenStack – is there any public cloud instances of OpenStack left, or is it all just private cloud stuff?

There are, but they’re all small. There’s IBM Cloud, which is still not only OpenStack. There’s CloudOps out of Montreal. There’s a bunch of little kind of hosting providers that are running small OpenStack deployments. And OpenStack – to be honest, the maturity has increased. It’s gotten better, easier to deploy, easier to manage. But really, foundational problems have never been addressed, like using Keystone for identity management, which was always a huge mistake. Neutron has never gotten to where it needed to get in terms of being the networking component. And sort of first-order support for Kubernetes’ isn’t really there. You’ve got to go to Kata Containers to get that. So, it's a lot better, but it’s not something that you could use to compete against Amazon. Probably people would disagree with me, but I don’t even think you can compete against VMR. And if you can compete against VMR, I’d like to see where that’s happening because as far as I can tell, it’s never happening.

Yeah, I used to run into it a ton back in 2013, and even did some OpenStack projects, but I haven’t seen it too much. I haven’t seen it being actually pushed out of some of the enterprises as people move into the public clouds. I think that’s just kind of a general trend.

Yeah, the place where it’s won is really the carriers, the carriers and niche sort of applications like these hosting providers. It’s been pretty much totally unsuccessful in the enterprise. Now, some people point to some really large deployments, like Walmart or whatever. But, success in the enterprise means broad adoption, like VMR has. It doesn’t mean sort of a few lighthouses. That doesn’t help anybody.

So in ten years, do you think we’ll be still talking about OpenStack?

No.

Yeah, I agree with you.

In fact, I don’t think we’ll be talking about VMR because I believe that we’ll get to a point where we’re using something like using Kubernetes on their metal. Those things, VMR, OpenStack, and most of the virtualization layer don’t really add a lot of value going forward in the future. So, I think you’re going to see them progressively removed as Kubernetes on bare metal matures.

Yeah, Speaking of Kubernetes – so why has that infrastructure kind of taken off and kind of accomplished what OpenStack couldn’t?

I think the hilarious part, and this is what drives me nuts, is because it’s got an opinionated architecture. And the reason that drives me nuts is my startup at the time, that was one of the first three startups for OpenStack land, we were predicated on having a prescriptive approach where we made our OpenStack product look as much like Amazon Web Services as possible, the APIs, the behaviors, everything. I’ve talked about this so many times, gave so many presentations about it. But at the time, nobody wanted a prescriptive approach. Everybody wanted their science project. So, then hen they all piled into OpenStack. They made a zillion snowflakes. 80 to 90 percent of those snowflakes failed horribly because science experiments are just – excuse me, but IT guys scratching the itch or doing mental masturbation in a way that is unproductive.

And the reality is that you want to get the stuff up and running as soon as possible. So, just because your hobby horse is you want to make Cisco work, or EMC work, or some random storage system work with OpenStack that doesn’t today, it just adds a risk. And, Kubernetes came along and said, hey, we don’t care what the infrastructure is. We care about your applications because that’s where the business is. And, this is the way your applications need to be architected. This is how they’re going to be deployed. This is how they’re going to be scaled. This is how they’re going to be upgraded. This is how you plug networking in. This is how you plug storage in. It was a much smarter approach. And then, there was a certain amount of fatigue, I think, around the sort of snowflakes. And people were like, ahh this is a breath of fresh air. We’re just going to use Kubernetes. We’re going to follow this model. It seems to have won. And I really think it was because it was a prescriptive approach that it won.

Yeah, I couldn’t agree with you more on that. I think ultimately, that just really the sound architecture of Kubernetes really kind of saved the day. So, looking at the other alternatives out there, Mesos, and Swarm, and things like that, and doing projects on all of those, it was just so much easier to deal with the Kubernetes. Now that the ecosystem has grown up around that and supported all the various cloud providers and private cloud providers, it’s really kind of a no-brainer. And it’s so much so that I think many tech companies, high-tech companies are aligning their strategy behind Kubernetes, which I haven’t seen in a long time. I guess they aligned their strategy behind OpenStack a while ago, but now they’re looking to Kubernetes to kind of get them out of the woods. What’s your thought on that?

Oh yeah, Juniper’s been adopting it pretty dramatically. We moved the whole Tungsten Fabric control plane to Kubernetes-based model, which was fantastic! It made scaling it, updating it, distributing it, everything just significantly easier. We’re working on an internal project right now called Atom, which is meant to be sort of a very light-weight, network-centric platform as a service system that we can refactor all of our software onto. So, it runs on one common platform, and that’s all Kubernetes-powered. And I'm seeing that over and over again. And the reality is, Kubernetes is just lightweight enough that you can pretty much do it anywhere. So, I see a lot of folks who have already invested in OpenStack. They start moving towards the edge.

And you had kind of the OpenStack folks trying to make a play for the edge, but OpenStack can’t really be trimmed down. I mean it’s sort of a pain from resource perspective, and it’s just not designed from scaling perspective. It’s not designed to be distributed. So, you see people putting Kubernetes on metal at the edge. Like, the eBay guys are doing this. A lot of the carriers are doing this, and sticking with OpenStack in their centralized data centers. But again, as we were talking about earlier, I think over time, even those centralized data centers will put Kubernetes on top of OpenStack and then slowly move OpenStack out of the middle because it doesn’t add any value.

So are we picking Kubernetes because of the architecture, or because of the ecosystem support, or because the hype behind it?

Well before the hype, there was use. I think we had this race in the early days between Docker, Kubernetes, and Mesos. It all sort of materialized when Kubernetes won that race, and again, because of that more prescriptive approach. I think it’s a combination of the architecture and it being a winner. I mean I know some people think that everybody’s just jumping on the bandwagon, but I saw that with OpenStack. And I saw it with Kubernetes. And I can tell you that there’s a material difference in that people are actually getting – there’s broad adoption of Kubernetes, and people are getting huge amounts of value from it. I can’t point to lots of failed Kubernetes deployments, where I could point to just metric tons of failed OpenStack deployments. The whole Expedia team that deployed OpenStack and failed – the entire team was let go at one time back in the day. I’m not going to name names.

But there have been some epic failures on the OpenStack front because of how it was architected, the inability of that community to understand that there needed to be a prescriptive approach, and the inability of the community to understand that big tent had to be a real thing. Instead, they pretended to be big tent, but in the reality, in the day-to-day, there wasn’t a big tent. They didn’t allow competitive projects. They didn’t allow people to sort of put the different components together in different ways. They pretended that it was all different projects, but then they forced everybody into this single monolithic six-month release cycle where all the projects had to be released and tested together. As you step back and think about that, everything I just said there – it clearly was doomed to fail.

Yeah, and I think that open source kind of has its own attraction, especially for small startups. Think about it. OpenStack was certainly an instance of this, and I think Kubernetes is as well. I can get a free license to very powerful software, and I can create a business model around it. In essence, I kind of don’t have to do a lot of R&D efforts, maybe do a lot of components or add-ons, things that I can sell that’s around the particular stack that I’m selling. And that’s a business. I think ultimately, do you think that these things – if you were advising small companies, do you think this would be a viable strategy going forward? I know you’ve kind of gone that way yourself. Is there some risk that’s over and above the traditional risk of creating proprietary things?

You mean just adopting an open source software in general?

Starting an open source business. And so, in other words, I’m going to do OpenStack or I’m going to do Kubernetes, and I’m going to build add-ons on top of it in a service-based practice in a distro for the particular system where I’m kind of automating the integration of these various things. And that’s my business. And the cool thing about that is I don’t have to spend a lot of R&D, but I can sell some pretty powerful software. And the viability of that seems to be in question if a lot of these open source things kind of fall by the wayside. In the future, do you think that this is maybe just how you place the bets, or the open source business in general?

So there’s a lot in that question, Dave. Let me try to unpack it. So,I think the first thing is that we’ve definitely seen a change to adopting open source first, what I call an open source first strategy, whether it’s a startup or large enterprises. Most everybody’s trending that way. Second, is that when it comes to building business models around open source, we’re seeing a certain amount of thrashing. And, you see that with Redis and MongoDB, where small startups have created open source software that then gets broadly adopted, but people take that software and then start to run it as a service. And, that’s created a lot of tension because it’s possible for large companies like an Amazon to come along and say run Redis as a service. And then, Redis the company is freaking out because they’re like, oh I’m losing against Amazon Web Services. But I think part of what gets lost in all that sort of discussion is that ultimately, this is about business agility. This is about product market fit. This is about the way that you attack the marketplace.

If you can’t be competitive, it’s your fault. Right? The reason that startups have always existed and that they’ve been successful against large enterprises is because they’ve got agility and the ability to zig and zag in a way that large businesses can’t, even Amazon Web Services of this world. You know, when they’re bringing up a new service, it’s taking them several years to bring that thing into production. They have to run it at such a scale that they’ve got to smooth all the rough edges because they could have thousands and thousands of customers on day one. Small startups don’t have to worry about those kinds of problems. They can bring up a new service in three to six months or write new software in three to six months. So, when they can’t compete successfully, it’s because of a leadership failure. It’s because of business strategy failure. It’s not because Amazon came along, and took your software, and is running it.

You should be able to out-execute Amazon at your size, no problem. And so, I just don’t have any room for those kinds of excuses. And then, the last thing there is that it’s very clear to me, that kind of back to that first point, that the power of open source is something that has been overlooked for a long time. Even inside of Juniper, as I’ve been having conversations with people about how we do open source and how we participate in other communities, I have to keep reminding people, how many years has Juniper benefitted from other people, open source. Right? Without FreeBSD, Junos wouldn’t have come along as fast or as quickly as it did in the early days. And then you could go down the line, and you could talk about the compilers. You could talk about all the open source libraries and other tool chains that people are using. And that’s incredibly powerful to have this public common as a software that everybody can benefit from. And, I don’t think that’s going to go away anytime soon. That’s here to stay.

And then it really just becomes a question of, given that that’s landscape, there’s all this free software. It’s expanding rapidly. It’s getting better in quality. How do you compete? Whether you’re putting pieces of it together with your own closed source software or taking some other approach, how do you compete in that sort of new environment? And I think that’s part of why people are struggling, but I think the outcome’s inevitable.

So larger enterprises that are looking to adopt open source, ultimately, this is kind of scary to them because they’re dealing with stuff that’s designed by committee or designed by a number of different developers that are working together. What would your advice be to them in terms of kind of quelling their fears?

Well I mean, one of the funniest things about that attitude is that they don’t know it, but they’ve got all kinds of open source widely deployed inside their enterprise already, and have had for a very long period of time. So, what they really tend to be concerned about is, they tend to be concerned about open source that’s more closely related to their core business. What I mean by that is, while they might be using the GNU Compiler or other open source tool,hey don’t really think about that as being open source. They may not even be aware that they’re using that at the business level. They’ve got developers and project managers making tactical decisions from day-to-day. Where they start to get squirrely is, say, if it’s a networking company, and they’ve got a piece of networking software that they’re gonna open source, or they want to adopt somebody else’s networking software. And now it’s close to home, right? Now it’s close to sort of what drives revenue for them, and that’s when they start to get squirrely, I think.

And then they start to ask questions like, well if we open source this, are our competitors going to take it and use it against us? Or, if we adopt this networking software and use it, are people going to think that we are not a very good networking company because that’s our core business? And that’s when I think sort of that at the business level, some certain amount of thrashing happens. And I say hey, just relax. It’s not about the what maybee’s or what if’s; it’s about actual outcomes. If you can release some software as open source or consume somebody else’s open source software that’s close to your competitive advantage, and you in some way get business advantage from that, or drive new revenue streams, or create some kind of success for yourself, that’s all that matters. Overthinking sort of the future in that way – I think it leads to analysis paralysis.

Yeah really, I always tell them, what other way of consuming software where you have more control over the source code than a proprietary system that can go away very quickly and get bought by someone you don’t want to buy them? So, I don’t really get the argument, but I do hear it from time to time. So, what are open source conferences like these days? What’s working? What’s not? Which ones should we go to? Which ones should be ignored?

I don’t know. It’s really hard to say, actually. I mean, I’m a big fan of KubeCon and CloudNative because I just think that’s where there’s a lot of action. And usually, that means there’s a lot of new ideas. I think the general problem, though, is that from that perspective in open source land and to a degree cloud land, there’s a lot of conference and even foundation fatigue, right? Last I checked with the Linux Foundation, I think they had 200 some odd sub-foundations. And you know, you’ve got OpenStack creating other foundations. So, I mean, I just think it’s making it hard, right? Every business has a fixed budget. They tend to have a lot of OffEx pressure. And if you add another 20, 30 conferences a year, it doesn’t help anybody, right? So, more and more, I’m seeing folks really pushing back at various enterprises against new conferences. They’ll say, why can’t we just do this at one of the existing venues? And, it’s almost like we should move to a model where there’s like a couple of major annual conferences in the same place where we just put a lot of these folks together.

Like you know how Oracle world or RSA become these kind of crazy annual events, with 60,000 plus? I know that’s hard to manage, but you almost want to see some of these foundations get together and just aggregate everybody so that people could be planning six, eight, nine months in advance to be to these major events. And they could just go and show up where they need to be. I know it’s a lot because that becomes a mega event, and mega events are expensive, and painful, and hard to coordinate. But, it almost seems like that would be better for a while, rather than having dozens and dozens and dozens of different events for each little niche every year.

Yeah, I think all the larger events are vendor-led. I mean it’s Reinvent, and Google Max, and all these other things. They’re going to be controlled by the vendor, and I wouldn’t anticipate anything different. They’re paying for it. Typically, the food’s better. It’s not as expensive to go to. But, these smaller conferences – the ability to really focus on dev-ops, and multi cloud-based development, and all these other things that just kind of fallen by the wayside. And it’s a little concerning to me because I think that we need to have these independent voices in the area so we can kind of get people speaking about what’s really happening out there, versus kind of hearing everything through the voice of the vendor, which is getting louder and louder.

Yeah, no that’s a really good point. I don’t know if making sort of a mega event helps or hurts that. I do know that the smaller events, like meetups and the other side, are incredibly valuable for that reason you just outlined. I think what we’re identifying is there’s that space in the middle where there’s a lot of value for regional or sort of mid-sized events where you can get more voices and less-heard voices in the room.But, if you have hundreds of those, it just makes it very difficult for people with limited travel budgets to get there. You almost want something that’s like an event that is composed of many, many small mini events.

Where you can get the leverage of everybody traveling to the same place, staying at the same hotel for a fixed period of time, but you’re opting into sort of a sub-event at a larger event, but that’s controlled by the sub-event people. The one thing you don’t want is complete top-down management because as somebody who’s helped organize conferences before, I can say that there’s a high level of variance between the conference organizers’ competence. And, you’re going to have the good conferences survive because they’re well-organized, and you don’t want to quash that by trying to do a top-down across 20 different sub-events.

Yeah, we’ll see where it morphs now that these days, where you can do video on demand and things like that. We do have electronic distribution of these things where you don’t have to attend in person and still get the experience. It’ll be interesting, the way these conferences kind of grow. But, I still notice that hundreds of thousands of people pick up every year and go to these big vendor conferences. And, that seems to be the case moving forward. Anyway, please pick up a copy of my book, Cloud Computing and SOA Convergence, available on Amazon and other places books are sold. Also, make sure to follow me on Twitter at @DaveLinthicum, l-i-n-t-h-i-c-u-m, as well as LinkedIn, where I have several cloud computing courses on LinkedIn Learning. So Randy, where can we find you on the web these days?

I’m the same everywhere. Randy Bias on Twitter, LinkedIn, GitHub, you name it – just RandyBias, all one word.

And, make sure to go follow Randy Bias right now. He’s one of the better brains in the industry. I’ve known Randy for a long time, and he’s always getting things right. Until next time, best of luck in building your cloud-computing architectures. We’ll talk to you soon.