Season 5 Episode 7 Jun 23, 2021

The History of the Cloud

Pitch

Where do clouds come from?

Description

In this episode, we talk about the history of the cloud with Kelsey Hightower, staff developer advocate for the Google Cloud Platform, and Jeffrey Meyerson, founder of Software Daily and the host of the Software Engineering Daily podcast.

Hosts

Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Vaidehi Joshi

Creator - Base.cs

Vaidehi Joshi is a software engineer, creator of the Base.cs blog series, and co-host of the Base.cs podcast.

Guests

Kelsey Hightower

Kelsey HIghtower is a staff developer advocate at Google.

Jeffrey Meyerson

Software Engineering Daily - Host

Jeffrey Meyerson is the founder of Software Daily and the host of the Software Engineering Daily podcast.

Show Notes

Audio file size

74589280

Duration

00:51:48

Transcript

[MUSIC]

 

[AD]

 

[00:00:01] What you build and where it takes you shouldn’t be limited by your database. CockroachDB, the most highly evolved distributed SQL database on the planet, helps developers build and scale apps with fewer obstacles, more freedom, and greater efficiency. So you can forget about the database and trust that it just works. Sign up for your forever free database and get a free T-shirt at cockroachlabs.com/devdiscuss.

 

[00:00:27] Cloudways is a leading edge Managed Cloud hosting platform built for your PHP projects. If you simply wish to focus on your business, Cloudways is the way to go. They take over server management and security and free uptime that you can dedicate to growing your business and acquiring new clients. If you want to give them a try, use promo code, DevDiscuss.

 

[00:00:48] Scout APM is the leading edge application performance monitoring designed to help developers quickly find and fix performance issues before the customer ever sees them. See why developers call Scout their best friend and sign up for your free 14-day trial, no credit card needed, at scoutapm.com/devdiscuss.

 

[00:01:10] RudderStack is the CDP for developers. It makes it easy to deploy event streaming, ELT, and reverse ELT pipelines. It’s open source and doesn’t store any of your customer data, and you can integrate it into your existing workflow with features like the Transformations API, which lets you run JavaScript functions on your data streams from a GitHub repo. Sign up for free at rudderstack.com.

 

[AD ENDS]

 

[00:01:38] JM: The narrative was that the cloud was only for startups and it took a long time for there to be penetration in the larger enterprise.

 

[00:02:00] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a Co-Founder of Forem.

 

[00:02:07] VJ: And I'm Vaidehi Joshi, Software Engineer and Creator of the Base.cs series. Today, we’re talking about the history of the cloud with Kelsey Hightower, Staff Developer Advocate for the Google Cloud Platform, and Jeffrey Meyerson, Founder of Software Daily and the host of the Software Engineering Daily Podcast. Thank you so much for joining us.

 

[00:02:29] JM: Thanks for having us.

 

[00:02:30] KH: Yeah, thanks for having me.

 

[00:02:31] BH: So I want to start off with a bit of your technical background. Jeff, since you haven’t been on this podcast before, let’s start with you.

 

[00:02:38] JM: Sure. I graduated with a degree in computer science from UT and I worked at several different companies, none of which I worked at for longer than eight months. So I am not great as an actual line software engineer, but after last working at Amazon, I started Software Engineering Daily, which is a podcast I host five days a week, and I’ve done probably 1,300 interviews with a lot of different people in the software industry. So I know a lot of the history and the context of why people use certain technologies.

 

[00:03:15] VJ: Can you tell us a little bit about the impetus for starting Software Daily and the Software Engineering Daily Podcast? What led to that happening?

 

[00:03:23] JM: I started Software Engineering Daily when it was kind of early in the world of podcasting, I would say. I mean, it wasn’t early in the sense that podcasts had been out for 10 years or 11, 12 years, but it was early in the sense that like today everybody starts a podcast like it’s a blog. Six and a half years ago, when I started the podcast, there were just not very many podcasts about software engineering. So I figured I could start one up. Since I was doing it as a full-time job, I could do it daily and really just grind on it and try to perfect the craft. My plan was always to use Software Engineering Daily as a media company to generate cash flows and bootstrap ideas for software companies. In retrospect, this was a terrible idea because doing two things at once was really hard. And one of those ideas that I worked on with Software Daily, which is basically like a homegrown platform for my media company. So that’s what Software Daily is, but really like the main thing that has worked for me across time has been the podcast and podcasts have just grown in popularity. So that’s really my bread and butter these days is still the Software Engineering Daily Podcast.

 

[00:04:29] BH: Before we get into the rest of the show and before we talk to Kelsey and we can’t wait to do that, can you give us a bit of a high level of your favorite things you’ve explored in Software Engineering Daily over the years?

 

[00:04:41] JM: At this point, I think crypto is probably the most interesting thing that we’ve covered in the last six and a half years. I know I’m saying that in the midst of crypto hype. I did a series of shows about crypto way back in like 2015. I did not invest back then, unfortunately. But I was sort of mystified by it back then. I noticed this very weird corner of the software world where it seemed like everybody I talked to in the space was incredibly smart and yet they were working on stuff that was so far afield from where most of the people I was interviewing were working at. Most of the people I was interviewing are from Google or from startups and they’re working on enterprise software. Those are the same people that are sponsoring my show. So that’s kind of the stuff that I produced the most content about. At the same time, over the years, you do more and more shows about crypto and the stuff that they’re working on, so the problem space is clearly, really, really difficult and clearly something was there, but I never really fully grasped the importance of the space like many people until very recently when you really start to see the applications coming out. But aside from that, I think the second most important space is just the continued rise of cloud and mobile, which continues to be unstoppable.

 

[00:06:04] VJ: So Kelsey, we got into your background a little bit back in Season 1, Episode 3, where we talked about the unpopular opinions of software development. But I was wondering if you could give us a little refresher about your background and what you do and how all of that relates back to the cloud.

 

[00:06:21] KH: Yeah. I spent the early parts of my career kind of self-taught. Actually, I opened a computer store before applying for a job and what people would consider the real world and building custom PCs for people, service calls, tech support for your local insurance company, that kind of thing. And after a few years, I got my first job in a Google data center. So you go in and you see, I guess, these state-of-the-art data centers. You’d think they all looked at. And I would say the other parts of my career, seeing that other people’s data centers don’t look like that. And so I’ve worked in finance, various ISPs, and then there was this kind of transition to open source. So while I was working in financial services, I started getting into the Python community, contributing there and to a lot of the DevOps tools like Puppet, where I spent a couple of years as an engineer at Puppet Labs, kind of building tools for that generation. And then full circle would be, you know, during the dawn of the cloud, we also saw a different movement, which was the whole containerization and changing the abstractions that even the early days of cloud didn’t deliver.

 

[00:07:23] BH: Last time you were on the show, that episode was just kind of a holistic, unpopular opinion episode. It was also Season 1, Episode 3. It was Jess and I interviewing you and we were just figuring out our own show and it was a lot of fun. And I urge folks to go back and listen to that, especially if you liked this episode. But one thing you talked about as an unpopular opinion, I think it was something along the lines of, “Cloud is going to kind of eat everything or everything should be in the cloud,” or something along those lines. Maybe I’m misremembering a little. But can you sort of speak to maybe that one thing you said and maybe kind of elaborate on that? Just like where that can be your perspective as like in some circles it’s unpopular and in some it’s kind of like, “Oh, that doesn’t seem unreasonable. That just kind of seems how it works.”

 

[00:08:10] KH: Yeah. At some point, all technology will have to start dealing with societal issues, government issues, regulations. So as much as the major cloud providers are providing tools and services for most developers, we’re already at a point where there are now things like the CLOUD Act where if you are running in a US-based company’s cloud, even if it’s in a region in your home country, the government agencies may have the right to subpoena your data, even though it runs in another country. So let’s say you’re a government in that other country, you may say that won’t work. We can’t as our local government be susceptible to those rules. That’s the thing that’s a real challenge. So that means that no matter how good the cloud is, they have to learn to conform with that, and that’s still being worked out. There is no obvious answer there, and that’s not about just technology. That’s just regulations and human saying, “Until we trust each other, until we have some type of agreements of how this is going to work, we may delay progress in those areas.” So this is where when people say, “Everything’s going to move to the cloud,” until you have answers for those things, that will just be the gating factor. Now for other people who see the progress, like there’s things like CDNs, if you want to distribute content globally, that’s very hard to do from your own data center in Nebraska, right? That’s not going to necessarily scale. There’s no way you’re going to be guaranteed to get enough power to even do it if you tried. So that’s where things start to become and feel like it’s a little bit obvious that if you want to be able to operate globally, you’re probably going to need some help, and it’s no way most companies will be able to afford to break ground in every country in the world or in enough places to give low latency for these kind of things. So that’s where it’s kind of an unpopular opinion, but an obvious one, depending on where you’re coming from.

 

[00:09:58] BH: And that’s a pretty forward-looking take in this episode is more about looking backwards. And before we specifically get into the history of the cloud, can you get into a little bit about why you think developers in general should dig deeper into the backgrounds and history of what made up their technology, like how we got here today?

 

[00:10:19] KH: I mean, if you’re a developer, just think about the fundamentals are roughly the same, right? You write code. Hopefully, you checked into some repository and your goal is to produce an artifact that can be deployed to do something. That’s kind of the fundamentals, right? Whether it’s a web API, your insurance company or some website, that’s kind of your goal. And then normally you’re going to be collecting and producing data of some sorts. Right? So these are very fundamental things and then you have the concept of security hoping that the thing you built works exactly as intended and no more. So those high-level fundamentals, typically companies tried to provide the infrastructure to do those things themselves. But if you’re a developer and let’s say your platform team has adopted things like CI/CD, they have some automation tools, in the extreme cases, you wouldn’t know the difference whether your team was using things on-premise or things in the cloud. It just wouldn’t necessarily need to be something that leaks out to you. And I think that’s where as a developer, that is the dream. Now the problem though is, classically, every iteration of infrastructure leaks to the development team. “Hey, we’re using a mainframe. So programming this language and here are the restrictions. We’re doing bare-metal machines now. Here’s your SSH key. Oh, we’re doing virtual machines. Here’s Vagrant. Docker is cool. Install that too. Now we’re using Vault. Here’s where you get your secrets.” So when you leak infrastructure, then you start to burden developers with understanding how everything is moving. So for a lot of developers, when they were introduced to the cloud, they were introduced with the set of cloud provider accounts, logging in and clicking around saying, “What can I use? What should I use?”

 

[00:12:00] BH: And if any of our listeners are interested in any of these terms, I don’t think the episode here is really where we get into that. But Season 2, Episode 7 was called Serverless and the Cloud 101. And I think that is a really good listen. And it’s not as introductory as maybe 101 seems. It was a good listen. So I think that’s a lot of good additional context there. Vaidehi, you’ve done a lot of your own project work, your own pretty important ventures for I think folks in tech. When it comes to the history of computer science in general, you did a series called Base.cs and you also had something called Byte Sized. And do you want to get into a little bit about what you learned through all of that and what they were?

 

[00:12:45] VJ: Yeah. For folks who aren’t familiar, Base.cs was a writing series I did a couple of years ago when I realized that I didn’t know that much about computer science fundamentals, and I wanted to fill in those gaps for myself. So I went and tried to teach myself, computer science fundamentals. But I’m also someone who really likes to peek under the hood. So I would learn about something and then I would be like, “Oh, but how did they come up with that?” And then I would go into these rabbit holes and realize that one data structure was based on another data structure that came 15 years before it and an algorithm that showed up in the ’60s couldn’t have been created without an algorithm that came before it. I got very in the weeds with some of that stuff. But what Kelsey mentioned earlier about having all of these different things that make your code work that you may not necessarily have to think about until the moment comes where someone hands it to you or you have to suddenly go and learn it. That really resonated with me. And I think when you’re working in this industry in particular, there’s so much you don’t know and there’s so much you don’t actually need to know until the day comes that you do need to know it and then the rubber hits the road and then you’re like, “Well, I guess I’m learning about Docker today. Today’s the day.” I didn’t know that’s what I was going to do when I woke up, but I kind of just love to peek under the hood of things when I get the opportunity, mostly because I think there are all these systems in place for why things were made the way they were and the cloud is something that I don’t even have the full context for. And it is very much like this wild, wild west, especially for web developers who think about their code and applications kind of isolated. And then the moment you think about scalability, the moment you think about hosting, the moment you think about where does my code actually live and how does it run. And I don’t think about that, but now I have to, that’s like a whole other can of worms. And so I’m very excited to open that can of worms today, I guess, is what I’m saying.

 

[MUSIC BREAK]

 

[AD]

 

[00:14:53] RudderStack is the CDP for developers. Its 150 integrations make it easy to connect your data sources to all of the tools used by your marketing, product, and data science teams. With RudderStack, you can say goodbye to the headache of managing custom-built integrations and easily manage all of your customer data pipelines in one place. Sign up at rudderstack.com to give it a try.

 

[00:15:16] Scout APM pinpoints and resolves performance abnormalities, like N+1 queries, memory bloat, and more. So you can spend less time debugging and more time building a great product. With a developer centric UI and tracing logic that ties bottlenecks to source code, get the insights you need in less than four minutes without dealing with the overhead of enterprise-platform feature bloat. You can rest easy knowing Scout’s on watch to help you resolve performance issues with Scout’s real-time alerting and weekly digest emails. As an added bonus for DevNews listeners, Scout APM will donate $5 to the open source project of your choice when you deploy. Visit scoutapm.com/devnews for more information.

 

[AD ENDS]

 

[00:16:06] BH: Let’s get into the history of the cloud. And this question might not be so straight forward, but can we define a time in the history of computing and maybe commercial computing where the cloud that we might know it today or even the term originated?

 

[00:16:23] JM: So my understanding is that this term just got popularized after AWS. And before that, there wasn’t a clear terminology for it. So I’m not sure if AWS took a term that was already out there and really put a ton of marketing dollars behind it or if they invented it. But my understanding is it was immediately post S3 and EC2.

 

[00:16:45] KH: Yeah. I’m not sure who should get credit for like the cloud. I think there were SaaS offerings where there was this concept of no more software. You have like the sales forces of the world and you have the e-commerce of the world. And a lot of people were like, “Well, where’s the stuff running?” Right? And maybe someone said, “In the cloud.” But in those days, it wasn’t for you, right? It was just that you get to consume applications and services in the cloud. And I think it wasn’t to Jeff’s point until Amazon really came out with a place to run your own tools and services that then the cloud became accessible to the general public. And I think that’s why we have that term like the public cloud where you can come and run your infrastructure on shared infrastructure by a cloud provider.

 

[00:17:36] BH: So I have a weirdly precise recollection of when I learned what the cloud was and what I was doing at that time and how precise it was. I just don’t remember when I learned about a new concept so precisely, but I was in college and this was probably around like 2009 and I abstractly knew that like code could run on the internet. And in fact, I'm maybe a kind of cloud native because my first introduction to any sort of software is GeoCities, which is essentially cloud computing and just not called the cloud. But I saw a commercial for a Microsoft cloud product, which is for consumers, like I was watching it on TV. It was part of Windows, like kind of like an iCloud alternative. And I don’t know what was going on with me at the time, but I kind of clicked what the whole cloud was about, just from a fundamental way, something about it, like really resonated with me, just the realization. And I ran to my friend’s house on foot to tell them all about how amazing the cloud is. And they didn’t do anything with computers. They were thoroughly uninterested in my little personal discovery. And it stuck with me to this day. I don’t do that with a lot of other stuff, but I kind of had this feeling about how big this thing was after seeing a commercial with a consumer bent that kind of implied some of the grander of the cloud itself. And it stuck with me. I don’t know. I don’t think about that a lot, but it’s a weird memory.

 

[00:19:23] VJ: I’m curious, for folks who might be listening who could benefit from a little bit of definition, how would you both define the cloud? What does it encompass and what does it not include? Just like in really simple terms for someone who’s new.

 

[00:19:37] KH: There’s a range. When Google started, their cloud product, this is where I work, App Engine was the only service, right? So Google Cloud Platform only had one thing and it was App Engine and to manage databases and the place to store files and things like that. So that’s all it was. And so for people would say that cloud providers had a single offering and things built around it. Some would argue that Heroku is also a cloud platform. Right? It’s a serverless type of cloud platform. But we really think about the cloud, it’s typically an umbrella of infrastructure, and depending on how high you go up, you may have high level APIs like data loss prevention APIs or something to do fraud detection for you. But typically when we think about today in 2021, a hyper-scale cloud provider will have everything from bare metal through APIs, virtual machines, virtualized infrastructure, and then higher level platforms like hosted Hadoop to do your data or something like data flow, if you really want to use a standard protocol for dealing with your big data, or tools like BigQuery that say, “Give us all your data and we’ll let you do analytics over it using our API.” So you have to think about now it's just kind of a range of collection of services and the reason why it’s that way and the reason why it continues to evolve is because most major cloud providers are servicing customers across that entire spectrum. Right? So don’t think of cloud hosting as like one single set of products, but a range of services that typically try their best to work together and solve a range of problems.

 

[00:21:13] JM: And just to piggyback on what Kelsey said, what I see as where things are going is just more and more simplification and more and more streamlining and more and more specificity. So whether you look at Gatsby and their Gatsby Cloud as offering, a narrower hosting platform for people who are involved in Gatsby, or you look at something like Render where it’s just the latest iteration of a high-level hosting platform all on Heroku eight, ten years ago, or you look at Zeit or Vercel and you look up a platform that basically started based around functions as a service and has evolved into its own sort of unique hipster take on deployments, you’re just going to see, I would say, higher and higher level and more and more niche offerings for how to do software deployments in software development.

 

[00:22:12] BH: Yeah. And our product that we sell now at Forem, it’s early on, it’s called Forem Cloud, and it’s kind of modeled after Gatsby Cloud or in some of these other ways, you mentioned Render, and we were just chatting with them the other day. They actually already have a Click to Deploy Forem on their docs already. We actually told them to hold their horses because we’re still like a few months away from loving the idea that people are just doing this randomly on their own because there could be a couple of breaking changes. But it’s certainly entered our work life more than ever and I think modeling that future is with those kinds of specialty providers, the things that are unique and interesting. And when we have to think about it, sometimes we have to think about we’re kind of just doing commodity web hosting, but it’s kind of complicated. The web has come along. Our application is more complicated. That’s kind of part of the deal. And it’s just kind of interesting. And since you sort of mentioned some of those services, I kind of wanted to tie it into kind of the work we’re doing. But I also want to ask you Jeff, to get into a little bit about the origins of AWS. And if we’re going to talk about for better or worse, AWS is certainly the origins of the cloud, as the behemoth we know it today. They really prove that it’s a huge, huge, huge deal. I think we can all say that regardless of where the credit might lie in some of the origins, Jeff, would you want to get into your version of the history of AWS?

 

[00:23:49] JM: Sure. So the extent that I understand or recall the history of AWS is that Amazon had just moved or was in the process of moving to their service-oriented architecture. And they had gone through all these pains of how to get all these different teams to standardize their deployments of their various services. And they, along the way, had some discoveries about how to run infrastructure and some opinions on how to run infrastructure and some predictions about how infrastructure would be managed in the future and basically decided to set up kind of a SkunkWorks couple of teams to work on this problem and see if they could come up with a product. And it took, I think, multiple years to finally get S3 off the ground. I think S3 was the first product and then it was closely followed by EC2, which is the first remote server provider from Amazon. Although there had been some services like that from other companies like Slicehost prior to that. But really it was Amazon coming out with EC2 and S3 and then really proving the product market fit there. And then the team just rapidly expanded and they started to come up with things like Elastic Beanstalk and it took off after that.

 

[00:25:19] KH: Yeah, I think, and then there’s also like SimpleDB. And I think when SimpleDB came out was that the cloud is going to be more than… the joke back then was, “It’s just someone else’s computers,” because people felt that they could already run virtual machines in their own data center using Xen or VMware. And so when you saw like a one-to-one of and I think definitely had a much better API, but when they went beyond storage and things like SimpleDB and Block Storage that you can attach and detach on the fly, that’s when I think this cloud thing starts to separate from the pack. But I think you’re spot on there that that’s pretty much the evolution of those early days of cloud.

 

[00:25:59] VJ: What else was going on at this time? We talked about how AWS sort of came to be an S3 as the first product, but what was going on in the space at that same time? What was Google up to when AWS came about? Why did Google Cloud not come first? Why did AWS come first? Were they doing something different or what was going on?

 

[00:26:19] KH: Yeah. So if you really think about what was happening at the time, Google didn’t really do more of that traditional infrastructure for themselves, right? They’re not running virtual machines this way. They already have BORG. They already have these higher level abstractions. They already have things like gRPC that we know today and things like Service Mesh. So for them, they had already virtualized their network and they had already started to become application centric. So when Amazon went their path, it came from Amazon’s heritage and the way they ran infrastructure. Right? And they did a good job of meeting the majority of the world where they were. Google in some ways is on their own digital island. They were building things like MapReduce and they had Borg and they were using distributed systems and not traditional racks like most people were thinking about at the time. So when they came out around a couple of years later with App Engine, App Engine had been around for a very long time at this point. And so they look, “Oh, the world wants to focus on apps. Who would want to have a virtual machine where you can just have an app?” And that was a bit of a miss at that time because the majority of the world was just getting up to speed and it’s also important to remember what was also happening at that time. Right before that, this is when the term DevOps comes out. At the time, this is DevOps and now people were starting to go from a bunch of bash scripts to using tools like CFEngine, Puppet, Chef, Ansible. All of those tools came out within like a four or five-year span and this is when everyone was like, “We should be automating these servers and starting to hide them behind other obstructions.” So you have this DevOps thing and you had config management that kind of really set the stage to say, “I can adopt those virtual machines and I almost need virtual machines for these tools to really excel at the time.” So that was kind of the gravity that was happening at this time. The world was looking for abstractions.

 

[00:28:17] BH: So DevOps happens and the cloud happens and those are kind of a chicken egg a little bit. Can you get into how culture needs to evolve as some of these things happen and how people get to realize, like, “I may not need to actually change how I think about things, not just what I’m using and stuff”? How do people actually start thinking at this time?

 

[00:28:40] KH: I always thought that cultural angle was never fair. And the reason why I say that is I worked in financial services for three years and we had a big brand new mainframe. I even walked through it one time and there’s benches in there and all of that. And that mainframe is fast. And it’s faster than generic runtimes like Java, et cetera, because the languages, the way you compile, this is when someone taught me what a nibble was, half a bite. Right? You can express most numbers in the nibble and the file formats we have were optimized to be loaded in machine memory and process super-fast. And they were like, “Your PC bot is no match for this.” It is not. Just do the raw benchmarks. You are no match for this hyper-specific platform. So you have this thing running and churning and really delivering value for 20 years prior. And then we introduced things like Java because there are some benefits to doing things in the web and network services. So what happens to a team over time? Every couple of years, someone is showing you a new event. So you’ve got mainframe, you’re getting value. You got your pizza boxes, you’re getting value. Solaris comes along, you’re getting value. Solaris goes away, guess what? You still have all those Solaris boxes, mounting NFS shares. Oracle told you to run their database on Solaris and you got really good at that. So as time goes by, you just tend to keep adding things, right? So over time, if you’ve been around for a while, like 40 years, 60 years, it looks like a computer science museum because you have some of everything and then you’re asking these people, the same group of people, because not all of these teams were able to grow. They’re trying to manage all four or five of these stacks and reality sets in that you’re never going to rewrite all the stuff from the mainframe to run on the new VMWare thing that came 25 years later. So I think that’s where a lot of times people don’t have time for the culture to evolve because they’re constantly being responsible for the previous one.

 

[00:30:40] VJ: We’ve talked a little bit about the history and the origins and getting into DevOps, but what was the reaction and the reception to all of this as it sort of started to take hold? This is a kind of a new concept, things started rapidly coming out and developers, I’m assuming, started making use of it. How do people react to that?

 

[00:31:02] JM: Well, if I recall, the cloud was adopted most aggressively by startups. And the narrative was that the cloud was only for startups and it took a long time for there to be penetration in the larger enterprise. And I think that slow penetration continues to today and this dovetails with the DevOps stuff. When you have the kind of Gene Kim crowd celebrating, bringing DevOps and cloud into the large old enterprise and delivering tactics for how to adopt this technology, I think to this day, it probably remains pretty hard to retire the on-prem infrastructure and the on-prem mindset. But at this point, the impetus is certainly there to bring cloud capacity and DevOps strategy into every organization, at some level.

 

[00:31:59] KH: I would say I remember when I was learning Java at the time. So I started kind of from a system administration back in and I learned Java. So I can actually like get the apps to start playing nice with the infrastructure, like do things like real health checks in the app, instead of writing bash scripts in Nagios that would then try to scrape the app for health, structured logging and a little bit of business logic, depending on what we’re doing. So there was a bit of tension, I think, between who should be working on what, how much should developers really need to know about low-level infrastructure, how much should ops people need to know about applications. And then you start kind of having this kind of divided stance on, “We need to focus and we need specialists,” but how big and broad to those things be? And so when the cloud came out, remember at that time you have full access to a machine, all the CPUs are yours. There are no noisy neighbors. There’s no one saturating the network. There’s no one abusing the hypervisor. And so when you go to the cloud, and remember at the time VMWare had just came out with things like live migration of a VM. So you could run like your Oracle database on VMWare and have it certified by Oracle that it would crash the data volume and the VM would move to another machine with very little downtime. So it took a long time to get there. So when you went to the cloud, I remember in the early days, because I was using Amazon in the early days at different companies, there used to be this warning, like, you should design your app that the app could go away at any time because the VM, if it crashed, there was no live migration at the time. So it could just go away. So you’re always taught. You need to have at least three instances behind a load balancer. And you remember, most people knew this was a good idea, but you were really forced to make sure you then the pros and cons of distributed systems. Load balancers matter. You need to think about multiple zones if you care about uptime. And of course, those things rapidly got better over time, but it really did test the resiliency of your application. And some people need to learn some new tricks around clean shutdowns, how to start things up and what health checks were for the first time.

 

[00:34:15] BH: And so while this is going on and to kind of talk about where it evolved, the notion that it was for startups, folks had to learn some new behaviors, enterprise would have been slower to kind of learn a whole new way to do things or think about things inherently, but there’s going to be some skepticism. Can we talk about Microsoft entering the game as an enterprise company in general and how they got into the cloud and how that could have shifted some of the culture itself? I said culture again and I know you said you’re not sure about that, that word in this context, Kelsey.

 

[00:34:53] KH: No, culture is fair. When you think about the overall practice of what we’re doing and learning from each other, that is a fair use of the word culture.

 

[00:35:00] BH: Yeah.

 

[00:35:01] KH: So you got to remember, the genius part about Amazon was they established a new technology relationship even against the inertia of the existing technology partners. So if you look at the Microsoft world, they’ve already done a really great job of having on-prem software. In many ways, some people had an entire Microsoft stack. They broke things in .NET. They ran on Windows servers. Their customers had ruined those clients. That was their technology of choice. And also Microsoft moved them through computing for the previous 30 years. So while enterprises were hesitant to move to the cloud, when you look at Microsoft’s timing, they come in and imagine this, they say, “Hey, look, we’re going to take your office licenses. I’m going to make them available in the cloud. Who really wants to run SharePoint? We’ll do it for you. You want some Windows servers? We got those. You know what’s even better? I’ll let you use your same licenses you already bought and you can just run them here and just pay for the compute.” So if you look at Microsoft from a technology partner, they already had a huge percentage of relationships with customers around the world. So when they kind of catch up with their cloud offering, it tends to make sense, especially where most of their customer base what’s ready for, which was virtualized infrastructure, running their existing apps but somewhere else with a lot more convenience.

 

[00:36:33] JM: The only thing I remember about the early days with Microsoft was that they were a few years behind AWS in getting started. As soon as they realized how important the cloud was, they really, really made a momentous shift and then shortly after triple down on that by making Satya CEO.

 

[MUSIC BREAK]

 

[AD]

 

[00:37:12] Cloudways platform offers a choice of IAAS partners, AWS, Google Cloud, Digital Ocean, Linode, and Vultr. In addition, you get a performance optimized stack, managed backups and staging environment where you can test your code before pushing it to live servers. Best of all, composer and kit come pre-installed so you can get your projects up and running quickly. All this power, simplicity, and peace of mind falls right with their brand slogan, moving dreams forward. If you want to give them a try, use promo code, DevDiscuss.

 

[00:37:45] Scaling an SQL cluster has historically been a painful task. CockroachDB makes scaling your relational database much easier. The distributed SQL database makes it simple to build resilient, scalable applications quickly. CockroachDB is Postgres compatible, giving the same familiar SQL interface database developers have used for years. But unlike older databases, scaling with CockroachDB is handled within the database itself. So you don’t need to manage charts from your client application. And because the data is distributed, you won’t lose data if a machine or data center goes down. Host it on-prem, run it in a hybrid cloud and even deploy it across multiple clouds. Sign up for your forever free database and get a free T-shirt at cockroachlabs.com/devdiscuss.

 

[AD ENDS]

 

[00:38:33] BH: Jeff, would you say that Microsoft doubling down and really committing obviously in hindsight? We can say Microsoft is doing really well in this business. But there were other companies in the vague space, Oracle, IBM, companies that weren’t in cloud, but they’re in cloud today, they didn’t quite move as fast as Microsoft. Would you say that Microsoft really identified this and they knew what they were doing in that moment, even if they were late to the game compared to some other folks?

 

[00:39:04] JM: Completely. I mean, Microsoft has just acted heroically in taking advantage of the cloud opportunity, the size of the cloud opportunity. I don’t know if it had to do with kind of the balance sheet economics. Maybe that was why they were able to make this shift more aggressively or because of the culture or because they were smarter strategically. But for whatever reason, they were able to make the shift more aggressively than the other players. And even, I think, in terms of market share, I think they’re still ahead of Google, but that probably has more to do with like their sales relationships and their ability to sell Azure into enterprises that are already like heavily on Microsoft.

 

[00:39:49] VJ: So when Microsoft entered the game, was that the big moment that the cloud really became this household technology that everyone was talking about? Was that when it became really integral to developers and just the tech sector in general? Or did that moment come later? And what was that moment? When did that shift happen?

 

[00:40:08] JM: I think in retrospect, it happened pretty quickly after S3 and EC2. I think that shortly after S3 and EC2, you had Heroku and then you had Uber and Airbnb and Netflix. Well, actually, I’m not sure when Netflix moved to the cloud, but I think Uber and Airbnb were pretty quick after the launch of the cloud. And I think when Azure first came in, people sort of saw it as an also-ran. I don’t know who was really paying much attention to Azure until they really started to gain a lot of momentum.

 

[00:40:44] KH: Yeah. I think Amazon did a good job of setting the bar for what cloud was supposed to be. So I would say that early days, Amazon was the bar. You had to have VPCs. You had to have APIs for everything. You have to remember, there was a Period 2 of the clones. Remember OpenStack tried to checkpoint Amazon APIs and build a whole project because before Amazon, we had Rackspace. I don’t know if you all remember. You could pay like $99 a month and get a dedicated server and you could do it through a form. You can go on website and you can click around and you’ll get an IP address and say, “Here’s your server,” because people were using these for their own gaming servers back then. So you kind of had this notion of shared infrastructure back in the early web serving days, right? Whether it’s web press hosting, virtual private hosting, or I just want my own server in the cloud. So that was kind of already a thing. But when Amazon came out, it’s like they had an API for everything. It was all unified, not just the machine, but storage and firewalls and this concept of security groups and it would grow on from there. And that metadata service was a big game changer as well when you start to think about IAM. So when they set that bar, you start to see things like Eucalyptus, OpenStack. All of them said, “Hey, we can do the same things now that we know what it should look like.” And they try to keep pace with Amazon, but Amazon quickly group hashed just a bunch of virtual machines and infrastructure. And I think OpenStack was no longer able to keep up. And OpenStack comes from Rackspace in an attempt to try to get on the same footing.

 

[00:42:24] VJ: You sort of mentioned that there were these early adopters when Amazon really set the bar. I think you mentioned Uber, maybe Airbnb, some other ones. What was the compelling reason for those companies to make that switch? Why did they place their bets that this was the future? Why did they make that switch? Because I imagine that’s kind of a risky move to make, especially early on when it’s a new technology and you may not always be so sure about the future of it or whether that’s the best thing to do, especially as the first few companies to make that change.

 

[00:42:55] KH: I don’t know if I have a definitive answer because I used to work at a subsidiary service of Rackspace called ServerBeach. And I remember when I joined that engineering team, they got bought by a company called PEER 1. And I went to San Antonio where the data centers were and I think a good chunk of the infrastructure was all YouTube. That’s where YouTube started.

 

[00:43:13] VJ: Wow!

 

[00:43:14] KH: So when you think about why would you choose a different provider? Right? Because you’ve got to remember, getting data center space isn’t cheap, building your own data center isn’t cheap, and then having remote hands to help you figure things out as you go isn’t cheap. So if you’re a company like the ones you’ve mentioned, you’re trying to focus on just leveraging the internet, right? Because a lot of these things require some access online. So you already have that dependency on public infrastructure to even be born and do your business. So when you look at the other side of that equation, it kind of makes sense, saying, “Wow! I can also outsource my infrastructure, look at my choices, build my own data center, go with co-location, go with something like Rackspace,” and some of those companies you mentioned did. And then you looked at Amazon, you say, “You know what? This is it,” especially now that OpenStack is out here trying to copy their APIs. You go out and you try it and you say, “Yo! This works.” And also those providers had really good internet connections, probably better than the ones you could actually get on your own. So I think they were also at a risky part of their company’s life cycle because early on, there was no guarantee they were going to survive anyway. Why not? Why not take a bet on the up-and-coming technology that you were able to try out with a simple credit card and no sales rep? So I think it made a lot of sense to make those things work in the beginning.

 

[00:44:36] JM: I think just convenience was why people chose the cloud. It just offered a very convenient way of accessing infrastructure.

 

[00:44:43] BH: I want to add some thoughts on that front. And I started thinking about this as soon as Uber, I think, left Jeff’s mouth. Uber by this point has raised over $25 billion in capital. And I think with the way they finance their company, there was a lot of capacity to throw money at problems. I can’t help but think they had an easy time spending on the cloud and the cloud really had a lot of fun selling to them. So when Uber is swiping that credit card, they were spending on everything, user acquisition and stuff. So that their cloud costs felt like nothing and a lot of companies that had maybe predated them were a little bit tighter on their spend and ushered in a whole new era of spending, I think, for brand new startups. And that certainly had to have helped that era in the cloud a lot.

 

[00:45:39] KH: Yeah. But if you’ve ever tried to like even buy data center space in another country, Right? Because remember, they want it to be global day one. They had a vision to be global. So when you think about the entire calculations, and I’ve worked at a company that tried this, you buy a bunch of servers and you ship them to another country. The custom says you can’t bring these in, you have to pay this additional tax. We don’t even know what this is. So the tax is like a million bucks. What you're going to do about it? Your hardware is being held hostage. You pay the tax and then who was going to set them up? Your people? You're going to set them up where? Is there enough power? What’s the bandwidth looking like in that particular country? Who’s going to guard the servers? And so when you think about that entire cost, even if you wanted to do it, you probably didn’t have anyone that knew how to do it. Right? Just getting your taxes straight globally is hard and people have been doing that for a hundred years. Setting up compute in a different country? That can be almost impossible. So when you look it, having Amazon have done all of that work already, it just kind of makes sense to piggyback and then just focus on building your product.

 

[00:46:47] BH: So when we talk about the proliferation of the cloud, obviously you two both come from an infrastructure perspective. We’re developers. We understand how we operate with the cloud. But Apple has a thing called iCloud. It’s a mainstream thing beyond our space. And iCloud essentially predates AWS. So when we talk about the origins of the cloud, when we talk about that, it’s not so clear, but I think we’re also talking about the cloud in a certain way, but I’m wondering what further mainstreaming of the cloud kind of looks like and then we’re kind of going to wrap things up and maybe if you two kind of want to speak to what you think of as the future of the cloud, kind of touching just normal people, touching DevOps and future practices and stuff like that.

 

[00:47:40] KH: I think once you have widespread infrastructure, the next wave of innovation is possible. Right? Once you have freeways and airports, then you can have FedEx. Once you have the cloud, now it makes sense to start Vercel. It makes sense to start these kinds of curated developer experiences, because now you can kind of pick your market without a huge capital investment to go after it. And I think that’s what’s important here. So what I’m thinking is going to happen now, just like with restaurants, right? Once you have a farm and what you have trade, you can have restaurants all over the globe selling any variety of food and there’s not going to be one chain, right? McDonald’s is not going to serve and provide all the menu items. You're going to have the chipotles. You’re going to have all the different types of restaurants that want to specialize in a particular set of things. And I think the key to this long term though is going to be interoperability. What we can’t continue with is a bunch of walled gardens, right? So if I deploy my app into your platform and I have no way to use a database that maybe being run by Mongo Cloud or CockroachDB or something like Snowflake, then that’d be creating too much attention and then you’re going to end up with the data gravity problem dictating who the winners are. Right? If I go to Azure and I put all my data there, then I’d rather wait for Azure to give me a service for my compute because it just won’t work. So I think what we have to solve in the future is that all platforms need to figure out how to make sure that we don’t ruin the internet, which is the ability to have clean network connectivity. If we solve that, and we have enough standards to make this work, where we’re starting to standardize around identity and security. So once you can say, “Hey, even though your app is deployed in Forem, you can use your identity, have it be trusted by Amazon and still access things in S3.” That is the final evolution I think that people are really looking forward to. So now developers can truly pick and choose what services they want and not worry about being cut off. Right? A lot of people talk about lock-in, but the last thing you want is to pick a provider that locks you out of everything else.

 

[00:49:55] JM: The other way of looking at the future of cloud is the low-code manifestations. And it’s hard to imagine how that world will actually evolve because we really haven’t seen any big startups that have actually come out of the no-code world. All we’ve really seen are people that are standing up like pretty nice looking web flow websites or pretty cool apps on bubble or pretty cool internal tools with retool. We’re not really seeing any full-fledged startup ideas come out of the low-code world, but it’s inevitable. And that I think is pretty interesting. On the infrastructure front, I agree with everything that Kelsey said. I’ll throw one other piece in there and that’s just the crypto side of things. As I mentioned earlier, crypto is a new kind of cloud. It is the money cloud. And if you’re not taking crypto seriously right now, you’re kind of making a mistake or you’re staying in your lane, which is fine, but it is real and it is validated at this point. And the way that crypto sees the cloud is much, much different than what we’ve been discussing, but it is a cloud nonetheless.

 

[00:51:04] VJ: Kelsey, Jeff, thank you both so much for joining us today.

 

[00:51:07] JM: Absolutely. Thank you.

 

[00:51:08] KH: Awesome. Thanks for having me.

 

[00:51:19] VJ: Thank you for listening to DevDiscuss. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email pod@dev.to and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM US Eastern. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.