From Excel to Kubernetes – Super Dope Conversation with Kelsey Hightower

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, it's Keith Townsend, Principal of the CTO Advisor, and we have a guest and we'll shortcut to it. He's been on the podcast before, Kelsey Hightower. We've talked about culture and enterprise, we've talked about technology, but we got into a quick back and forth on Twitter about Kubernetes and Google Autopilot and a bunch of other stuff. There's parts about Kubernetes that I just get stuck from an architectural perspective. We're going to dive into that. But first off, we'll start out with some basics that are not about Kubernetes, but about some of the problems we're trying to solve in enterprise IT and IT in general.

Kelsey, welcome back to the show. Oh, happy to be here. So first off, let's talk about something that you were talking about last year a lot. Some of it was joking, but a lot of it was kind of serious because I think as people who are looking to solve problems with technology, it's the desired state. So let's start with the desired use of computing. This whole idea of no code, like ideally, I want to be able to give someone a tool that allows them to use AI, ML, big data sets that's as simple to use as Excel and democratizes compute, allows the accountant or the person in marketing to use their data sets to the best of their ability.

So can you walk me through like conceptually problems that no code solves to serverless problems that serverless solves? And then as we get into kind of these more infrastructure-related technologies like Kubernetes and cloud native, we can kind of set the stage for the conversation. Yeah. So I think, so when we talk about the fundamentals, when this applies to infrastructure, like this concept of promise theory, and you can go into some deep research, Mark Burris is the guy that kind of really coined this, wrote about it, and then it was applied to config management.

But the thing is, we missed the fundamentals. If you think about humans and the promises we make, let's talk about the post office for a second. That stamp, you buy a stamp and you get an envelope and you put your stuff inside and you put the address on it. And so now you're declaring that I want this letter to go to that destination. And the price for that was the stamp. That's our contract. Now behind that is a really complex system, right?

We're not just talking about how the post office operates, but they have mail sorters. There are trucks that need to have engines and transmissions to transport things back and forth. There's a whole airline industry around this. These are all complex distributed systems behind a simple contract. So for most people who are not building post offices or logistical networks, they are just using stamps and writing addresses. We can only dream presenting certain interfaces like that in our world. So a lot of us are builders.

We either building trucks or airplanes or mail sorters. We're not really talking about the absolute end user that will consume our platform. So when we say no code, right, if you think about the person who walks in front of their computer and opens up Excel spreadsheet, just to use your example. Now they have a column, a couple of rows full of numbers. Now we could say they could go get JavaScript, Python. We give them some libraries. They download the spreadsheet, turn it to CSV, add the numbers and put it back into a column.

That's the current thinking we do today. The no code process would be highlight all the columns and rows and then right click and hit some. That's the no code mentality. We don't need code to do all of these common things, but then we have to figure out what are we going to embed these actions in so that way you don't have to write code in order to leverage it. So you can call a function without writing code. I think Excel is a great example of having a tool that can do visualizations by just highlighting some regions and then creating a graph from it.

That's the ultimate experience in terms of the systems we build. Now to the next part of your thing, when we talk about serverless. For some people, they would say there's one more level above that, which is SaaS, right? Like I just want a user solution, not build one because when I hear serverless, you're still customizing. You're still you're still if we go back to your post office analogy, we're building trucks and there's still a layer of people who need to build roads before we actually get to the actual usable functionality of putting something in my mailbox and one of the trucks comes to pick up the thing from the mailbox.

Exactly. So if I was just trying to mail an envelope, I don't want to have a discussion about cars, even if it's a self-driving car, like I'm still not interested in that particular thing. So let's start with SaaS. So behind that spreadsheet might be Google Docs. I go there and I launch a spreadsheet. Cool. For me, that's a serverless environment. There's no software to configure. I just get to interact with it and use it. Below that becomes to me serverless, meaning, OK, I need some custom functionality here that I can't find somewhere else.

So I think the goal is not to be writing a bunch of functions or serverless containers, but that glue says I got some data coming in from somewhere or something that needs to be done. And I'm going to give you that bit of custom logic that I can't find somewhere else. But again, that's all I'm interested in. So I don't want to know about servers or Kubernetes. I just want you to run this logic and allow me to wire up the data in and the data out.

And then I want to be done with it. So that serverless mentality is all about doing just enough with existing tools that I can just drop in my one concern in and be done with it. And then as we walk down, it's more about more customizations, right? Like maybe I have some software that does metrics in a way that you don't. And I really, really want to use it because it integrates with other systems that you don't support. So you're forcing me now to bring in maybe Prometheus open source project, but I got to run it somewhere.

And I happen to need a VM because I can optimize how it runs. So I'm going to be now I'm building my own cars. So before we get into that discussion, because I love the analogy and again, to bring it back to where an executive might look at this, this is saying we literally I can build a CRM in Excel, like I can run my business in Excel, but I chose to go out and buy a CRM solution that's a SAS solution because they can do it much better than I can and simpler because frankly, I just want to I just want to know I just want to get an alert when I need to follow up for contact.

I want to be able to follow the contacts. I want some integration into my email platform. But to your example, when that thing gets big enough, I want to start pulling analytics out of it that aren't necessarily available in the platform. Maybe I run that analytics, maybe I export it as CSV stuff and run it in Excel, or maybe I want to, like you said, use a truck to parse that data and give customized analytics that I can't get. So that's when we're bringing in our data scientists, et cetera, and they're using these tools.

So this is the point where where we have to use trucks. And the question is, who's building the trucks? Why are these trucks running? Who's driving the trucks, et cetera? Yeah, I think that's a good point. You know, like if a SAS provider is doing everything, you know, if you're a retailer and you want real time information about customers behavior inside the store. So at that point, you may have to glue together two independent systems. One might be just how do you even gather the data from the store and make it available on that SAS offering?

But that SAS offering may say, hey, we can't take and ingest that kind of data. That's not what we do. What we can do, though, is you can send your data to some other system and we'll allow you to take data from our system. You can put them together and do whatever you want in terms of gaining insights or maybe doing a little bit of email to feed your models. That's up to you. But that's not our play. And that's where that need to customize comes into.

So for executives listening to this, this is our SAP HANA's of the world where we're taking, you know, you might hear the term data lakes where we're taking data from this separate systems, putting it together in SAP HANA, and then our data scientists are running queries or writing applications that take advantage of that. This is the raw investment in power of these tools. But we get to a point where we just don't want to run the computer or technologies behind that. We want our developers to simply just write code against some type of service, whether that's a SaaS service or something that we run.

And I think this is where we're starting to get into the area that Mia, you play a lot in, which is the infrastructure needed to run SAP HANA or the infrastructure needed to run the application code that our developers and data scientists type up. So I think the one thing that we haven't hit on head on is serverless. So what type of solutions does serverless solve when it comes to running code? Yes, when we start talking about code platforms, you know, classic serverless offerings would be things like Heroku, now owned by Salesforce, App Engine by Google, Lambda by Amazon, Azure Functions, you know, IBM serverless, you know, functions.

So you'll have all these things. So, OK, what makes them serverless? Well, what makes them serverless is they try to eliminate the concept of infrastructure. So they will have some entry point, right? Like the post office wants to stamp in an envelope. They may say, you got to give me a container or you got to give me a zip file with your function code in it. But you have to fit within this, though, because if it doesn't fit, we're not doing it.

Like you go to a post office, it don't fit in one of these boxes or one of these envelopes. We're not messing with it. Right. Like we can we just got to get a bigger box. But either way, it's going to get boxed up so it can actually work with our efficient logistics chain. Right. So that's like the price of admission. So you look at that and you say, OK, cool, I get all of this value as long as my workload will fit in their box.

And that's where the that's where the efficiency comes from. And I can give you a pricing model to match that. So maybe I can do something like per usage. You know, if you give me something that's packaged that suits my platform, then here are the capabilities I can give. And here's how much it's costing. It will cost you. I don't have to charge you for a whole operating system. I don't have to charge you for all of these extra little security demons you want me to support because that's not the contract that I'm giving you.

Right. So I think that's the way you have to think about it. The problem with serverless, though, is let's say you've been around for a while, like 30 years, 40 years, 50 years, then you got some application that you've written that really needs something from the mainframe. It has a hard dependency or it's doing something really crazy on a Linux or Windows server. And you look at the serverless platforms, a lot of them don't really support Windows in terms of the lower levels of Windows.

So then you might have some applications that don't conform. They say we can't ship that, that that don't meet our guidelines. I love this analogy of the post office because we can keep using it and, you know, we can take everything from a ladder to ladder to a certain size box. But let's say that I have the business need to ship a vacuum. A vacuum isn't something that we ship through the post office normally. However, if I break the vacuum down to smaller bits, I can fit those in smaller boxes and ship that via the system.

But I need something to I need a process. I need a business process on my end to disassemble, package and ship the vacuum cleaner then on the other end to reassemble that vacuum cleaner and use it. If my thing does not conform to the post office, I have to use some other system to ship it, whether it's UPS, FedEx or something else. I have to use something else that doesn't conform to the post office limitations. Right. So this is why we have more than one serverless product in the world.

Right. So FedEx may say, hey, we can optimize for very heavy things. Right. We have a great ground network. Right. We also can do overnight air to anywhere in the world. So this is where you start to get competitors show up. Sometimes they show up with a clean niche. Some some competitors like DHL right back in the day, they focused on last mile. If you get to the airport, we'll get it to the location because your network ain't big enough.

We can come in and do last mile. That is the same in the serverless world. Right. So I think when people kind of look at this, they got to say, hey, you know, what serverless platform, because it may not just be one, you know, maybe my mail goes through the post office, but that vacuum cleaner goes through FedEx. But here's another thing. Look at IKEA. They actually change their products to that whole flat pack model. They've optimized to be streamlined.

So over time, FedEx looks at all the other furniture vendors, whether it's Havarties or whoever, they're like whole couches got to sit in warehouses and you got to go to the warehouse. Now, IKEA is like, yo, this whole Internet stuff, this whole ability to distribute efficiently and control inventory. If we flat pack it and make the user assemble it. So we're not going to try to sell a whole couch. We're going to sell all the pieces to the couch, put them in individual boxes.

And you see people walking out of IKEA with twenty five boxes for their dining table because they can go home and assemble it. And that may make the most sense. Right. So you got to look at what are you willing to do to leverage these serverless platforms? So one of the early battles in the term of serverless was that whether or not, you know, things like Lambda versus Cloud Foundry versus Roku and all these other platforms, whether or not they're serverless or not, I think for our definition, they're serverless in a form that you're packaging code, you're shipping the code via something other than virtual machines and containers.

It is you're using someone else's facilitating the compute stuff, stitching together the compute parts of it. It's just which which flavor of serverless do you want to use? And then we get out of kind of serverless into I don't want to say that it's because this is where I think most people get hung up in the concept of serverless because we're using the terms containers and shipping and all of that. We automatically default to Kubernetes, which, you know, orchestrates containers. But we're using you are interchangeably using this term containers to talk about code.

Is that by accident? It was by design because we could talk about letters. But that's not what they don't ship letters at the post office. They ship things in the envelope. So when we you can be writing any of the programming languages, right, the popular ones would be like Java and C++. There's just so many that you can't build an efficient system by trying to target each of those individually. And this is why we up level the conversation. So we deal with letters and boxes.

So containers and zip files are our letters in boxes so we can be efficient. And, you know, this dream of multi cloud and switching vendors, you ain't doing that if you start dealing with stuff at the very lowest levels, you need that container because you need a contract like DVDs back in the day. Right. All the movie studios put things on a DVD so you don't have to go buy a Paramount DVD player, universal DVD player. No, you just can go buy a DVD player and then studios can make a DVD.

So we need to up level the conversation. So it's not about just app and code. It's about software that's ready to be delivered. So the container is what we mean. A container is software that's ready to be delivered. So let's dig into that a little bit. Software that's ready to be delivered. I really struggled with this concept early on because I was not a Linux person. I was used to receiving package software. So I really struggled with the concept of packaging software because to me, a package software was an MSI or ESE file that I got in Windows.

And I'm like, what do you mean package software? I get ESE files all the time. I double click on them and they run. What was I mixing, missing in those early conversations, early days? I don't think you were missing anything. You know, it was the state of the art at that time. You know, when everyone was writing towards Windows, Windows was saying, look, we got everything you need right here. All you got to do is put your business logic and your code in a MSI.

That was their container for Windows. In the Windows ecosystem, that was the end all be all. If you're in the Apple ecosystem, there's a package that you give to Apple and they can distribute it to all the iPhones. That works fine, but it only lets you do Windows. Now, what we're talking about is I now got Amazon, I got Azure, I got Google, I got Alibaba Cloud, and I'm not trying to have them all present to me their own unique operating system.

And honestly, most operating system stuff is now commoditized because of things like Linux. So we're at the point now where you're saying, hey, I'm going to use lots of different languages and frameworks and I need to be way more efficient in how I deliver that software. So this is where that containerization comes in, because whether you're Microsoft, which also supports containers, it allows us all to streamline. And also as a platform provider, I also want to focus on value, not trying to figure out how to deal with the different low level packaging formats because they're not universal.

So it's just a stronger contract, right? I don't want you to come to me and say, hey, Kels, here's a bike and here's all the parts. Do you support shipping bikes? I don't want to have that conversation between you and my folks. I want to say, if you put it in the box, we'll weigh it and we don't really care if a bike is in there. So it's a better contract and it's a better way in 2020 of packaging software.

Same concepts, but the contract is stronger because we've learned a lot since then. So I was on a car ride. The 13 year old looked at a shipping yard for trains and she said, isn't those the things that go on boats? And I left because I was preparing for this conversation. And I said, exactly. And I explained to her how the shipping industry works. Until shipping containers were a thing, it was very difficult to coordinate shipping in between organizations, countries, et cetera.

So I get the point of containers. And this is where we get to kind of the architectural question and where my brain breaks because I've never done containers and Kubernetes in production. I've done traditional VMs in production for years. I've migrated tens of thousands of workloads from data center to public cloud or from data center to data center. So I understand the VM container because that's one way to package applications is via a VM. I came with this expectation with Kubernetes and we'll just generically say Kubernetes for containers, Kubernetes and container orchestration that I'm finally going away from this abstraction layer that mapped to CPU, disk and storage.

So this is where I kind of got to your point of POTS being an important concept in Kubernetes or in containers in general. In my mind, when I consume something like a Google Autopilot, which makes the muck of the roles and disorders and all of that much simpler, I still just want to package the app. I just I still just want to package the application and send the application. I'm personally missing some of the complexity in that promise or that engagement. What am I missing?

So, you know, when we talk about VMs, right, what we don't say is, you know, we use the car analogy. When you talk about VMs, you know you need more than the VM. You need load balancers, firewalls and all, but you're so used to it, you don't even think about it. So this is the equivalent of saying, oh, I know what to do with the engine transmission doors. I know how to put them together. We make cars all the time and we might even automate the making of cars.

But you can't deny you making cars. And then when that car is done, you put somebody in, you drive them off. But that's exactly what you're doing. But we're so good at it that we don't talk about it anymore. The cloud came along and said, hey, you know, you got muscle memory, so you still want to make cars. Cool. Here's some APIs and we will just make the cars for you. But you can have a virtual firewall. Have fun with it.

Now, when we move up the stack and you say, hey, look, I'm only making cars or VMs so my apps can run on them. So if you're going to manage the infrastructure for me, if you're going to just give me the car, then all I want to do is drive. Like I want just give me the steering wheel. I just want to drive. So you, the human, are the app. So the app just needs an IP address so it can do its thing.

And the car is like, look, just give me the car and I can do my thing. I'm going to drive it around because you've taken care of the infrastructure. There's one thing missing here. Where do you want to go? This is the configuration piece, whether you drive the car, GKE Kubernetes, or we drive the car, Autopilot, GKE Autopilot. So the analogy here would be if I sent you a self-driving car. And it pulls up, you don't even got to drive anymore, that's GKE Autopilot, you can now get in the backseat.

You still got to tell me where we're going. And I think this is a great, great, I think, filler for me because I'm thinking about my son when he went to one of his first coding competitions, it was based off of one of the legacy cloud providers that's now no longer in the business. They were infrastructure focused, VM focused. He got the VM, he knew what to do, but then it asked the question of firewall. What, how do you want to configure your firewall rules?

And he was like, wait, he called me up and like, Dad, what's a firewall? You know, I wrote this really cool Twitter, this app based on Twitter APIs. It works at home, but it doesn't work when I'm trying to deploy it in the cloud. And I think what the other cloud providers got right was that they packaged that stuff in a way that we didn't have to know it initially. Not, it was done, to your point, it was done automatically, but we didn't have to really notice.

They didn't use terms like firewalls, et cetera. They just made assumptions for us. And Kubernetes and the whole world is that in order to be effective, to your point, we have to be able to tell it where we're going because we and my son's defense, you know, he he was a developer. He would normally hand that code off to me and I would make those decisions for him and I would deploy the application. But when you expose this naked capability to to to someone, someone has to make the decisions.

And that's where pods and configuration files and all that come into play. Yes, so the pod is the place where you say it can be as simple as you want. If you try to just deploy a very simple app, you can write eight lines of YAML. I have this container image. It has this version. I want three of them and they own this port. You're explicit, you give it and Kubernetes does all the other work. And there's a lot of work that people keep looking past, even though it's basic.

But then remember, Kubernetes is for all of the organizations and for all of the workloads. This is not like serverless where we make a big trade off on what you can and can't run. We're saying pretty much everything you could do with the VM. We're going to let you do it, too. But here's the thing. This is self-driving car land now. So you just got to give us direction. So if you want a volume, then I'm going to have a section that you can tell me what kind of volumes you need and I'll mount them.

Don't worry. I know how to mount NFS and make sure that it stays mounted. But you got to at least tell me you want NFS. If you want to use Datadog for your metrics or some other tool, you just got to tell me. I want to use Datadog with these credentials. You got to tell somebody. I'm just saying I'm forcing you like they say, writing is thinking. So when you create a pod, you're thinking, you're saying, what do we want to happen?

And then once you do that thinking, now we can do security policies because we have it written down now. We know what the system is going to do. So it's a big leap forward. So I think for people that are coming from the VM world, you know, 90 percent is just that you've never been forced to turn what you know into something like a data model. You haven't been able to serialize your experience. We've been writing scripts and automation. That's not you just writing stuff down and hoping people ran it.

OK, this is different. We're now serializing our skills into this thing we call Kubernetes. So the more capabilities it grows, the more fields will show up in that pod. So it will seem complex because there's a lot of things it can do. But the way you need to approach it is before you even look at Kubernetes, just write down. Here's what I need. And then Kubernetes says, well, here are my fields that will help you do what you need.

That's how it works. And then last thing I'm going to say here is pod is just the first abstraction that comes out of the box. You can create new. You can create an abstraction that's not called pod. You can create an abstraction that's called app that then sets a bunch of default values. So no one ever has to make these 25 decisions. If you know you're going to always need NFS, then don't ask that question and just do it.

So you have it's a framework for serializing expertise and experience, and you can put a data layer on top. That config layer is like the stamp and the address on the envelope. So Kelsey, I'm going to respect your time. I think we can go deep into the second layer of conversation of why that's even needed. The whole conversation around pods and interaction with infrastructure and the many advantages where containers and Kubernetes come in, because that's where I absolutely see the portability and the ability to leverage containers.

For those that want to follow you on Twitter, because you tweet a lot. Kelsey Hightower, full name at Twitter, DMs are also open. Thanks a lot, Kelsey. Talk to you next. We'll definitely schedule this follow up conversation. Awesome.