Command Line Heroes - Crack the Cloud_Open

Episode Date: March 13, 2018

“There is no cloud. It's just someone else's computer.” Or server, to be exact. Big cloud providers offer a relatively easy way to scale out workloads. But what’s the real cost? In this episode, we talk about the battle in the clouds, where any winner is still very much up in the air. Major Hayden, Microsoft’s Bridget Kromhout, and others help us understand the storm that’s brewing and where that leaves open source developers. Please let us know what you think of the show by providing a rating or review in Apple Podcasts. Drop us a line at redhat.com/commandlineheroes, we're listening...

Ingrid Burrington wanted to walk inside a cloud. Not just a cloud, though. The cloud. I don't know what the internet looks like. I don't think it looks like this. I wanted to kind of just find out. Ingrid's a journalist. For a series she wrote for The Atlantic, she talked her way into one of the data centers where more and more of our online lives play out. What she found there wasn't all fluffy and white.

It was downright physical. First up, getting her photo taken for an ID tag. Next, going through security checkpoints and signing a non-disclosure agreement. Finally, she gets to see the machines. The server rooms are basically warehouses. Think Costco, but bigger. And there's something beautiful about that warehouse look. Because everything's just there, on display.

Racks of naked servers, and above them, all the cables connecting them to the world, running along tracks on the ceiling. There's a sort of fancy blue light going on, kind of a Tron thing. But mostly, it's rows and rows of very hungry servers.

Data centers use up more energy each year than the whole of the United Kingdom. And that means they're throwing off crazy amounts of heat. Which is why, when Ingrid looks around... This is a building that's mostly designed around having the most perfect HVAC system

imaginable. Ingrid discovered that everything about a data center is pragmatic. So yeah, just a bunch of machines, a bunch of cables, a bunch of fans on lots of cheap land using lots of cheap water to keep it cool. Not quite what the word cloud represents, but on the other hand, it's our lives, our work, our voices bouncing around in that warehouse of machines. Yeah, it can be a little surreal because it's not as though it's like, I know that machine has like someone's email and that machine has something else. But realizing just kind of how much is kind of like

happening around me implicitly that I can't see, but like I can kind of like hear in the sense of like the worrying of the machines and the larger kind of like operation of the space. There is something like a little bit eerie about it. And I mean, there's sort of like a, you know, industrial awe. It's so important to remember that these buildings really are there somewhere, humming behind the fence. Because here's the thing, when we talk about storing stuff on the cloud,

or building an app on the cloud, we sometimes fool ourselves into thinking it's like a cloud in the sky, something nobody can touch. But the reality is exactly the opposite. And once we remember where the cloud lives, we can start talking about who owns the cloud. Who controls all those servers and cables and fans? And how does that change the way developers build the future?

Because in Cloud City, we're all living there together. I'm Saran Yitbarek and this is Command Line Heroes, an original podcast from Red Hat. Episode 6, Crack the Cloud Open. There is no cloud, it's just someone else's computer. Chris Watterson is a designer who grew annoyed at the confusion around the cloud.

That word had softened the edges of data centers, like the one Ingrid visited. When he put that slogan on a sticker, he became internet famous. That line, there is no cloud, it's just someone else's computer, is now on T-shirts, hoodies, coffee mugs, posters, coasters,

and more than a few keynote presentations. People sort of still use the cloud as in it's going up there. People that don't understand fully what it is, they can still take it sort of the wrong way and not understand that their data is actually going across, you know, copper cables or fibres or whatever it may be into a storage device that's actually managed and owned by someone else. Which obviously some people, if they've got, you know,

private content they want to hide, could be quite scary. So think of Chris's sticker next time you're tossing something onto the cloud. Where are you really tossing it? Same goes for working on an app. For all the talk of going serverless, there's really no such thing. It's somebody else's server. Somebody else's computer. In a sense, this is a story about growing up.

All season long, we've been tracking the evolution of open source. From its rebellious origins with the free software movement and the emergence of Linux, all the way to today, when open source tools and methods have taken us far from home into the cloud. Think of it this way. When a person finds an apartment to rent,

she's going to sign a contract, move in, and make it her own. When developers go looking for a cloud provider, they have to do the same thing. That's the moment we're in right now. The moment when a whole world of developers is making their move onto a series of clouds and starting to figure out what the rental lease actually says. So just for the record, why are we in such a rush to hop onto a cloud in the first place? Developers don't want to have to manage the infrastructure that is running their applications. This is Brandon Butler. He's the senior editor at Network World, and he's been

covering cloud computing for years. They want to develop apps, and they want to deploy those apps, and they want the apps to just run. And more and more, we've seen things like serverless computing and functions as a service and containers and container management platforms like Kubernetes. Check out episode five, by the way, for a rundown on containers and Kubernetes. All these things are helping to abstract away the underlying infrastructure that applications need to run on. And that's going to be a trend that we're only going to see continue to develop into the future. A big part of that attraction is summed up by the word hyperscale. With the cloud providing all your infrastructure, you can take a startup and scale it up or down as fast as you want.

You're not building your own infrastructure anymore. You're just renting out however much of the cloud you need. Brandon explains what hyperscale means for a startup. This whole model of using the public cloud for application development has been a huge advance for application developers. It's created a whole new range of startups and companies that have grown past startups

and become major publicly funded companies. You think about a company like Netflix that runs much of its backend infrastructure on Amazon's cloud and other cloud providers as well. They were able to turn into what they are because they are using the cloud. So the impact that the cloud has had on developers cannot be understated.

It's been the major shift in application development over the last decade. Nick Bush, a sysadmin at Meadowbrook Insurance, remembers what a pain infrastructure changes were before the cloud. Before it was somebody would come up with an idea to do a certain project, and we would say that would need hardware to do that. And they would ask, well, how do we do that? So we were always constrained by memory, and VMware usually was the hard part. And we would be constrained on how many virtual machines we could spin up at any one given time. So we would have to go get a quote for new processors new memory you know new hardware you know five hundred thousand dollars added space and stuff like that and once we get those quotes

from a couple different vendors it would go to management and they would take time and it was a long drawn-out process just to get the hardware in let alone then we build the vms and you know turn them over and test and stuff like that. So, I mean, there are several months of front-end work versus now we can definitely, you know, get that okay within a couple hours usually and go spin it up and turn it over to them the next day. So it is a big turnaround difference. Between scalability, speed, and price. The cloud can look very tempting. To go back to the apartment rental analogy, cloud options can feel like you're getting a butler and a driver at no additional cost. It's hard to say no.

And today, we've got four very ambitious cloud providers doing the tempting. They all want to be your new landlord in Cloud City. But hold up. Everyone who's rented a home knows it's not the same as buying. You can't just knock down a wall or install a new jacuzzi. You got to go through the landlord. In some ways, could we be stuck if we find ourselves beholden to a single proprietary company? Brandon Butler. When you use a proprietary cloud vendor, there are different ways you can use it. You can use it in a way that embraces open source standards and open source platforms and run those open source platforms on top of a cloud that even may be proprietary. Or you can use native tools to those cloud providers that may not be as open source,

but they may have stronger integrations to the public cloud platform. So it's a big trade-off that end users have to consider. Do I want to use tools that are native to the cloud provider that may be more heavily integrated with the services this cloud provider offers and other services that I might want to use also on that cloud? Or do I want to prioritize using an open source platform that will give me more freedom to run that maybe on my own infrastructure or on another cloud provider's infrastructure. As the clouds we rely on keep growing and the big four cloud providers elbow past each other for dominance, we developers have a choice. Do we give up some of our independence relying on a single cloud provider to protect our work?

Or can we take another road, maximize the scalability of the cloud while keeping our independence? In other words, can we sign a lease that says, sure, do what you want with the place. Knock a wall down. Make it your own. So what's the problem with giving up a little independence? If you're a developer, it might not be so obvious. That's because it's mostly been the ops teams who've been encouraging us to tread lightly. They notice the nuts and bolts issues. Here's Major Hayden.

He's the principal architect at Rackspace. Developers will often find that over time they may have requirements for different things like a certain specialized kind of storage or they may want to have a certain sized VM or maybe they want a type of offering that the cloud provider doesn't offer. And there's also some of those things that you do have to look at that developers aren't always the first ones to

look at where you have to do that cost benefit analysis to understand, you know, okay, I have a lot of flexibility in public cloud, but how much does that really cost me? Major points out another issue, one that goes beyond practicalities and speaks to the heart of what developers like me believe in. I'm talking about open source practices. Even if cloud providers allow you to use your open source tools, they're not themselves open. So open source in the cloud is an interesting subject to tackle because there's plenty of open source technologies that allow you to take advantage of a public cloud. But not all public clouds have their infrastructure offered as open source. So, for example, if you take Amazon, you're not able to actually see what they're using to build VMs or build other services.

So if you want to make an adjustment for that, you really wouldn't be able to. Or if you wanted to look behind the scenes and understand more of how it fits together, that would be difficult. If you listened to our episode on DevOps, you know there's a lot we can gain by tearing down the wall between developers and operations.

Architects, like Major, give us some crucial insights. And then there's sysadmin Nick Bush. He's on a team where people are ready to jump on the cloud. Developers are tired of being stuck with physical hardware that ages every five years. And everyone likes the idea of expanding as fast as they want. But Nick wants to flag things that developers might not be considering. Yeah, I mean, there is inherent latency. I mean, that is a database server in Montana versus my 10 gig connection down the street.

So just doing local database calls is going to take longer. It is a longer path to get there. And there's other, you know, security stuff that's out there that we didn't have to worry about physical premise. You know, here we were in control of our hardware and stuff like that. Once you're in the cloud, you got to think about the other connections coming into that. You got to worry about security, I think, a little bit more. And it is a price thing. Every month, you want to spin up VM, take up storage space. It is a cost per gigabyte, you know, transferred as well as stored,

where before we had a one-time purchase and we just had it there, and we could store it, use it, you know, we didn't have to pay any more money as long as, you know, we had space for it. For the record, Nick does think the pluses outweigh the minuses. He just doesn't want us to pretend it's a perfect system. What happens if your provider has an outage

and you want to redeploy an application in another cloud? Or what if there's a price advantage to using different clouds for different things? A lot of the issues that the ops folks bring up can fit under a single label, vendor lock-in. You're probably familiar with this term. It's the concept that building on someone else's server gets you more and more tied to their platform. You get locked in. Suddenly, you're being force-fed upgrades, cost changes, new limits you wouldn't have chosen for yourself. You get the idea.

When we put our DevOps hats on, we can work together to see lock-in coming and plan around it. But when we're buried in our own code, we sometimes forget to look at the whole picture. What about finding the right mix, working on both public and private clouds? The ultimate solution might be in a hybrid cloud, the best of both worlds. I called up Bridget Kromhout to get her perspective. She's a principal cloud developer advocate over at Microsoft and knows this stuff backwards and forwards.

So if we think about the hybrid solution, having a little bit of that public cloud, but then also some of that private cloud, is that the perfect balance between the two? Is that the ideal solution for developers? If it's hybrid, then I can kind of like do whatever I want and use whatever tools that I want on my end, but then still get some of the benefits of the big public cloud providers. Absolutely. And so like, for example, I have friends who work in high performance computing research at manufacturing companies, and they have all sorts of top secret NDA, whatever stuff that they don't feel comfortable putting in public cloud. And so maybe they're going to work in their data centers on these workloads, you know, crunching these customer numbers or whatever, these research numbers.

And then they may have other, they do have other workloads that they feel comfortable having out in public cloud. But I think this is kind of a question of, and sometimes there's questions too of whether public cloud has suitability for some of the workloads. Like if you're planning on using InfiniBand interconnects between your nodes, how much of that are you going to be able to provision in public cloud? But this isn't necessarily the perfect solution. Bridget does think that hybrid clouds come with their own headaches. The problem with hybrid is sometimes people fool themselves and think that they can take something that really wasn't working. So if they had their old processes with a two-week wait time to even get a single VM, if they have a whole scenario like that and it wasn't working well, and then they have a bunch of people who have just started taking their credit cards to the public cloud providers because they're frustrated.

And then they try to somehow glue those together, but then there's problems with data provenance and latency and, I don't know, desynced data sets. There's a lot of ways it can go wrong. I think if you work with your cloud provider so you can add some of the direct connection things that are available so that you can sync things better that can help? Yeah. So when we talk about the cloud in the context of open source, I feel like as developers, we, I think most of us really like open source,

especially if you're listening to this podcast, right? You want everything to be open and transparent and share the code and all that. But I feel like when we talk about the cloud, because it doesn't feel like its own code base, doesn't feel like its own project, it's the environment, it's the thing that we can use to help us run our code. Are developers as insistent on that part of the story being open source and transparent the way that we sometimes feel very strongly about when it comes to our projects and our code base? You know, I think that's a really reasonable question. And I think that might also come down to

exactly where in the stack are you going to pick to care about? Because if you think about it, how much access to and info do you have about the chips? That's yeah, that's true. That's fair. They're sitting over there with some silicon and some secrets like they're not necessarily giving that to you. That's a good podcast name, by the way. Right? Maybe the question is like, not is everything open, but is everything open that you need to be open? And of course,

is your provider going to have transparency with you when things don't operate exactly as they should? Because hopefully they will. So I get Bridget's perspective as a public cloud provider. And she makes an interesting point. How granular does the developer's control need to be on the cloud? As for me, I look at it differently. What don't I want to sacrifice in order to get some of that public cloud goodness? Say an app is running on a public cloud. And then, wait a minute, now I've scaled up. Or there's new compliance requirements, and it makes more sense for my app to be in a

private cloud. Moving that app point to point, I need to know it's going to work. I need to know things are packaged the same way, configured the same way. In other words, I need to know that jumping from cloud to cloud is always possible. What's the alternative? Getting locked into just one cloud provider? A provider that might even gain a total monopoly over all the others? Not having the option to move to a different environment? That's like trying to code with one hand tied behind your back.

So, we don't want to be trapped and beholden to any one cloud. We want to be able to cloud hop when it suits us. In the immortal words of rock legend Queen, I want to break free. We want access to that fantastic scalability you find in public clouds, but without giving up the freedoms that we've come to expect from using open source tools and methods. Here's the good news. The work on those hybrid clouds is

well underway. Mike Ferris, VP of Business Architecture at Red Hat, gives a great explanation of how hybrid clouds help us maintain that open source ethos. Open source is really the base for almost every cloud in the world, and now many, if not most, of the application infrastructures in the world. And the tooling evolves from that, the management capabilities, everything that people are using to build and deploy mission-critical applications, as well as non-mission-critical applications, if it's all based on open source. This concept of hybrid really flows along with it, meaning that they have the ability to use these things wherever they are to take advantage of the best feature sets on what infrastructure is there, all based upon this concept that open source is really helping define

the standards that are driving this next generation of development while they continue to leverage all the investments that they've made in the past. I think the cloud wants to be open. We've spent a lot of time this season talking about the origins of open source. You can even make the case that some version of hybrid would be an extension of those same ideals. What has changed in the open source development activities over the past several decades has been that many more people have gotten involved, including people like Microsoft, IBM. You know, name a big corporation, they're either using open source for their offerings or they're building open source and being what was originally intended to displace, you know, the Solaris and Unix environments to something that's the basis for not just community and hobbyist use, but also certainly mission critical enterprise use. Open source is growing up fast. And now we have the chance to make sure we remember where we come from.

As we hop on the cloud, we can claim part of it for ourselves and keep the cloud open. Luckily, building open source bridges between clouds is getting a lot easier, thanks to work like the OpenStack platform. Major Hayden, principal architect at Rackspace, describes its origins. It really came from Rackspace and NASA getting together and saying, hey, look, this is a new way to build infrastructure, and we should do it out in the open.

We should get more of this input. We should talk to more people. We should get more use cases. And so what OpenStack is, it's a group of applications that work really well together to create infrastructure, to manage infrastructure all across the board. So whether you need complex virtual machines, complex networking, you have strange storage requirements, OpenStack can usually fit most of those.

Major's talking about adding something that open source knows how to deliver. Adaptability. So when I look at OpenStack, I look at it as an interconnected set of open source applications that allow you to build the infrastructure that you want. And if it can't build what you want, then you can go in the community and make changes to it. I love the reaction when I go and talk to customers and they say, well, we want to change this. We want to change this. And we say, well, you can.

How do we make sure that level of adaptability is enshrined in the cloud of tomorrow? Like many issues we've talked about in past episodes, it's all about strong communities. Brandon Butler, Senior Editor at Network World. So for example, we've seen the Cloud Native Computing Foundation be created to create standards in the use of application containers and Kubernetes. And we've seen the OpenStack Foundation be created to bring OpenStack users together to talk about best practices when creating open source infrastructure service clouds. So the communities that underpin these open source communities are hugely important for developing the next wave of open source tools, for learning best practices about how to use

these open source platforms, and for encouraging these vendors, these public cloud vendors, to embrace these open source standards. Once we start building that hybrid cloud, making it as open as possible, the potential really seems endless. Here's Major. What I'm most excited about is just to see more things that can come together on top of different clouds. So for example, OpenStack provides a great base layer of infrastructure, but then you can do so much on top of it. And I think sometimes different companies will adopt OpenStack and then say, man, what do I do now? I have all this freedom. I don't know what to do. It's kind of like when you have a refrigerator full of food and you're like, oh, I don't know what to make. I love having that problem.

So Chris Watterson might have been right when he told us. There is no cloud. It's just someone else's computer. But that's not the end of the story. With hybrid clouds, we get to write ourselves back into the next chapter. The key to creating a hybrid cloud app probably hasn't been cracked yet. Managing work across multiple clouds, that's going to be a huge job for today's command line heroes. There'll be a lot of trial and error, but it is so worth it.

Because the one thing we do know is that staying open source means developers can always build the world they want to work in. And that kind of flexibility is how we're going to hold on to the rebel spirit that open source does best. Next episode, our season finale. We're zooming out for a big picture view of what open source looks like as a global phenomenon in ways that are going to surprise you. We'll also look to the future of open source. How are developers preserving the spirit of heroes like Linus Torvalds, even as they reinvent their industry?

Command Line Heroes is an original podcast from Red Hat. For more information about this and past episodes, go to redhat.com slash command line heroes. Once you're there, you can also sign up for our newsletter. And to get new episodes delivered automatically for free, make sure to subscribe to the show. Just search for Command Line Heroes in Apple Podcasts, Spotify, Google Play, CastBox, and other podcast players.

Then hit subscribe, so you'll be the first to know when new episodes are available. I'm Saranya Tbarek. Thanks for listening, and keep on coding. Thank you. you're going to need to fine-tune or augment models with your data for your use case. And you need a common platform for that, where data scientists, app developers, and ops teams can all collaborate, especially as you start to scale. And then this is iterative. It's rinse and repeat. So really, it's about making that fast path from idea to model to production and back again.

And that's what Red Hat OpenShift AI does. Head to redhat.com to learn more.