Screaming in the Cloud - Episode 25: Kubernetes is Named After the Greek God of Spending Money on Cloud Services

Starting point is 00:00:00 Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Adam Seligman,

Starting point is 00:00:27 the VP of Developer Relations at Google. The VP of Developer Relations at Google. He's formerly at Salesforce, and before that, he was doing DevRel at Microsoft for a long time. Welcome to the show, Adam. Good morning. So, let's dive right in here.

Starting point is 00:00:42 What is Developer Relations at Google about? So we build platforms for developers at Google, and we love it when developers are happy. So there's a whole team of people here that wakes up every day and makes sure developers have great outcomes with our services, products, and also makes sure we're listening to them and bring all that feedback back into Google. So it's simultaneously an outbound role,

Starting point is 00:01:04 as well as being the, I guess, ears for the customer as well as just the voice? Yeah, that's super important. It doesn't do us any good to build developer products that developers don't love. So this whole team is kind of optimized around sitting really close, working closely with product management and engineering and bringing back all those lessons and insights and helping make the products great. And then we do spend a lot of time out all over the and insights and helping make the products great. And then we do spend a lot of time out all over the world talking and connecting with developer communities

Starting point is 00:01:29 and showing the stuff we're working on and writing open source. But it's not an outbound job. It's a developer relations job. So a large part of developer relations, as per people who are very active in that space, comes down to, I guess, storytelling, for lack of a better term.

Starting point is 00:01:46 What do you find is the part of the Google story right now that really resonates with the developer community? Google's got a lot of products and services used by developers, right? Like everything from Android and Chrome developer tools. You know, the V8 library inside Node.js comes from Google or started from google open source and then up in the cloud you know things like kubernetes and

Starting point is 00:02:12 k-native and tensorflow all these like hot emerging technologies so so a lot of what we do is make sure we've got great technologies available to developers. We like to sort of tackle everything in kind of an open source way. And, you know, ship it, get feedback, iterate, build communities. That's kind of the heart of it. So a story that's really seeming to resonate lately that goes beyond Google, although it didn't start off that way, is I guess the tale of Kubernetes, where it's in a very short period of time gone from this open source project that folks from Google really spearheaded. And from there turned into, I guess, something that is sweeping an industry.

Starting point is 00:02:58 We're seeing evolutions of this coming out of large enterprises. We're seeing small startups working on this. We're seeing a host of consulting and technology providers in this space. How does Google view Kubernetes today? Well, I think the tale of Kubernetes used to be a pretty cool 12-part Viking miniseries on Netflix or something, but I don't know if it's that dramatic. I'm relatively new to Google, but I've learned a lot about the history of how we built our platforms internally. Containerization and global scale was something we needed. See the rise of the containerization technology inside Linux Kernel with great companies like Docker.

Starting point is 00:03:42 I think there was opportunity for Google to kind of share some of this container management technology and philosophy out with the world. And it's taken a couple of years. Like we're still kind of at the beginning of this story, right? You know, the journey we're on to containerization, I think from what we've learned, what we're seeing from the customers and from developers out in the market is it's not just about packaging the app, right?

Starting point is 00:04:08 It's how do fleets of things run at scale, how do teams ship code to production and route traffic to it? It's kind of the end of the story is going to look very different than the beginning of the story, I think. And I think a lot of that story is still being written. I mean, right now, you can walk into a room with a straight face and tell people that Kubernetes is named after the Greek god of spending money on cloud services. And most people still don't have enough background on the service to question that. It's an interesting area. And we just saw at Google Next that I believe Knative is how it's pronounced, where effectively being able to deploy Kubernetes workloads back to on-prem. Am I misunderstanding how that works? Yeah, there's kind of two main announcements at Google Next. The first is Knative, and it's this

Starting point is 00:04:58 journey towards lighter weight, serverless-based applications. Small, lightweight applications can be packaged up, deployed on top of a container infrastructure. An eventing model, so you can fire them off events in kind of a nice, elegant way. I think the long story arc is we're seeing everything. I was kind of thinking

Starting point is 00:05:20 if I had a tagline at Google, it's like we run it all, big to small. And Knative is about in some, the small stuff, working really nicely in that Kubernetes-based substrate world. The second thing that we're seeing with customers and startups and developer teams and ops teams is a lot of Kubernetes running on-premise. People have infrastructure and they want to modernize it. They want to manage it with sort of modern DevOps practices. Kubernetes is open source to let them do that. But then once they've got that substrate running, they want to run apps that span across these worlds. And so we show this commercial product, GKE, on-prem, sort of a hybrid model of our GKE management service managing apps across both cloud and on-premise

Starting point is 00:06:07 Kubernetes clusters. And that's a neat new capability, I think. I think a lot of customers will get excited about. I would agree. That really came to my notice when employees of a large competitor, who I need not name at the moment, and I'd like to point out these are my words, not yours, were more or less mocking Google for the idea of bringing GKE on-prem. I find that to be a little unfair in the context of, at first, you can tease a large provider for not meeting their customers where they are, but then when they do it, you mock them for going in that particular direction. It really feels like, to some extent, whatever you do is going to upset some contingent of people on the internet. And you've almost hit a point at Google where you can't win.

Starting point is 00:07:00 I think that it's, you know, vendors play marketing games where they poke each other, and I think we're going to mostly sit out of that. We have a lot of experience now working with large banks, mega retailers, lots of different kinds of companies and they're running a mix. You know, they have infrastructure. It's not going to go away. You know, like we're all in the cloud. That's a Google point of view for sure. But if we could use open source and provide services that customers can use kind of on-prem to make their infrastructure better today, why not help them on that journey? And so this is why we do open source, right? Like a lot of this innovation, we don't want it locked up in any one particular cloud provider. So I don't know.

Starting point is 00:07:39 The mocker's going to mock, I guess, maybe is a good way to say it. But containers are going to contain. Containers are going to mock, I guess, maybe is a good way to say it, but container's going to contain. Containers are going to grow. From hearing the cheap seats, it's always easier to throw scorn and cynicism at people rather than it is to be supportive of something. Because if you, heaven forbid, say something nice about the wrong technology that doesn't win, well, what might happen from there? Well, in reality, nothing. But it doesn't always feel that way in the moment. One thing that does strike me as innovative that I wish some of your competitors would copy is that when I log

Starting point is 00:08:14 into the GCP console, there are two features that are absolutely revolutionary from a customer point of view. The first is anything that I spin up, I can terminate all billable resources assigned to that project. So I'm not left with a 20 cent bill in perpetuity for the rest of my life. And the second is when I click around and build something in the console, there's a tab at the bottom that says, oh, here's how you can build what you just built by hand programmatically if you'd like to. And those two things, I get that they're minor features, but from a usability perspective to someone new to the platform, that is transformative. There isn't anything like that in other providers. And it also gets away

Starting point is 00:08:59 from the idea that you have to be conversant with 12 different services that are only tangentially related to the thing you're trying to build before you can get somewhere productive. What is the strategy that goes into GCP's console development? The console's been a really neat experience for me, getting into working at Google and using the product to understand how we build things. I think you'll see all the different top cloud providers kind of evolve their point of view and the services they want to be great at. And sort of their company DNA starts showing through at the developer experience surface

Starting point is 00:09:35 area. We're building a great console, I think, with GCP so that customers can have great experiences and developers have great experience. It's pretty easy to navigate. Things are organized well. We take a lot of pride and put a lot of hard work in our documentation and make sure it's all linked really effectively into the console experience. You know, some people like CLI. That's totally fine. They want to script and automate. We make everything accessible that way also.

Starting point is 00:10:00 Things aren't exclusive to the web view or the CLI view. But I think you're going to see increasing intention to design in that console experience. You know, a lot of thoughtfulness around billing, a lot of thoughtfulness to have services or groups together, services or group together. We have tutorials embedded in there so you can sort of get started and go learn. I work personally, I spent some time with our vision APIs over the weekend, and it was a pretty delightful experience. To use AI research in the cloud are pretty computationally intensive. And so you need to go provision your account to go use those services. And I had a good experience with it. So I was feeling good about the teams and the doc teams

Starting point is 00:10:44 and all the hard work we put in to make those things easy to use. This is going to be an investment for us, so we're working on the next version of the console right now, iterations and improvements to the console. And I'm really excited about where the team is taking it. And I'll say to your readers, if you haven't kicked the tires in the GCB console, check it out. It'll surprise you.

Starting point is 00:11:03 I think all the consoles from the different vendors look different, but I think what we've done is we really delight some developers. I can absolutely echo that, given the fact that I'm not much of a developer myself. To that end, a few years back, I went through a Google interview series, and it turns out that Google has a hiring bar that is set at least at the level of should be able to write code. And if you can't write code, like me most days, it turns out you generally don't get hired. So we wind up going out into the world and writing code at other lesser places badly. The challenge with that, of course, is I then build an application that's, frankly, by Google's standards, terrible. It takes in none of the Google system design principles into

Starting point is 00:11:51 account. It starts entirely with me writing this ridiculous monolith. It's something that doesn't wind up falling into any of the traditional 12-factor app-style development model. So I've written this crappy thing that's architecturally fragile. And then I try to run it on GCP. How well these days is Google at addressing the needs of a workload that is about as on-Google-y as it's possible to get? Everything about engineering is about design goals and trade-offs and success metrics, right? There's not one right way to write software. And not every application is going to have a billion users.

Starting point is 00:12:37 So I think this is a big part of the story arc from Google building a great cloud platform. It's been not just to hit the sort of hyperscale kind of requirements and global footprint kind of requirements, but really supporting every developer. I think we're on a good path for that. It's definitely in the mindset. If you read our documentation, if you try our console, if you see our getting started, you'll see. You can stand up a relatively monolithic PHP app and get it up and running.

Starting point is 00:13:01 You can write a little Node.js service, uses AI like I did over the weekend. All those doors are open for you for every kind of developer. And how we hire and how we think about the core software engineers we put on staff is different how we think about supporting every developer out there in the universe and how she's going to write apps and learn our technology and try new things. So I think it's part of the long story arc. I don't think it's solved overnight, but absolutely Google wants to be welcoming to developers of every single background and meet them where they are. It's a very hard problem to solve, specifically because you have an entire world of industry out there where the constraints around what they build don't look anything like

Starting point is 00:13:47 any application Google would build internally or would consider building internally. Writing software in COBOL that runs traffic lights or displays ATM balances globally is very different than building a world-spanning search engine or a highly available email service. And at times, it seems almost like people who work in those, I guess, ancient and regulated industries sometimes feel that there's a sense of, I don't want to say condescension because it's too strong, but a sense of being left behind by all of the major providers in this space, just from a perspective of not being able to build something that comports to anything that looks cloudy in those constrained regulated environments. How do you find that bringing those people into the conversation generally plays out? I think there's a little bit of a, maybe a different conceptions of how software is built out there in the world. I think there's a conception that Google and similar companies

Starting point is 00:14:54 build hyperscale, read-centric, user-partitioned apps like mail, and don't build things like globally consistent data-driven apps like banks um and i think there's also a conception that you know software engineers at the top internet companies just like are like you know do code jujitsu and just write amazing things instantly and i think that's a little misconception too and i would like to maybe address both of those i'm going to the second one first. Kind of the interesting lesson I've learned, I worked at Heroku for a while. I actually ran Heroku for a little while. Adam Wiggins wrote the 12-factor application.

Starting point is 00:15:36 There's a lot of ethos at Heroku from, I don't know, a decade ago, the early days. And it was about being opinionated. You know, 12-factors is about an opinion of how apps ought to be architected. Similarly, at Google, we're surprisingly opinionated for a lot of things, how we help our internal engineers build things. And so actually, I think a lot of what a regular developer faces out in the world trying to build an application is actually a lot of choice. You know, there are not a lot of guidelines on how to go

Starting point is 00:16:06 build things, like what library should use, what framework should you use, what should your data to your architecture be, how should you manage partitioning and scale out and operations. It's just a world of choices and it's maybe an overwhelming

Starting point is 00:16:21 set of choices. One of the things that's kind of neat about this sort of container approach was something Google did internally, which was just make that stuff really easy for developers. They didn't have to worry about it. They could scale a workload out. It would load balance traffic against it. It would attach to data services that were scalable data services.

Starting point is 00:16:39 And so it was kind of about less choice. So I think that developers should always have the choice to use whatever they want. I think if you can take some of the cognitive and operating load of some of this complexity away and give developers the option to use happy paths that are well-paved and work really well, I think that could be a wonderful thing. And the second thing is the kind of applications, probably all the cloud providers are seeing this, but we're seeing like banks run core workloads on Google Now. We're seeing retailers run core workloads on Google Now. We are shipping databases like Spanner that are not

Starting point is 00:17:16 only kind of neat, globally consistent and scale elastically and read, but also accept distributed rights, which is like a really neat capability. We had to put atomic clocks in the data centers and private fiber networking to make this all work. But the end result is the user doesn't have to worry so much about high-scale relational databases spanning across the world. The card consistency problems are mostly taken care of for them. So we want to do the engineering work and build this great cloud so developers can do whatever they want, but also take advantages of services that just go and work and simplify

Starting point is 00:17:53 that part of the equation for them. Another example of that is ML, right? Like, we did TensorFlow. We did open source. You can do anything you want and run it anywhere. But at the other end of the spectrum, we have AutoML, where you can throw a bucket of images at it, and the computer, the cloud, will automatically create a model for you and provide it back as a REST service. So I think

Starting point is 00:18:15 developers should have lots of choice, but I think if we could also provide a world where for many of these use cases, we can make it simpler, I think that's going to be incredibly powerful and kind of liberating for developers. I think that one of the easy things to forget is that Google is at this stage a very, very large company. And I think for some people, they're still sort of stuck in the early 2000s, where Google was much smaller, but it was in some ways more focused with respect to offering fewer products. And it also tends to lead down paths where people's understanding of Google has not evolved or kept pace with Google itself. In many ways, you still wind up with people living in the past when Google had less than 2,000 engineers and not tens of thousands of engineers. And that, in many ways, seems to be,

Starting point is 00:19:05 I guess, an area where, at least personally, I still struggle to think of these giant companies as more than five or six people with ultimate decision-making authority. To that end, you've been at Google for approximately eight months now. Have you made any progress on determining the identity of the person who's responsible for killing Google Reader? We're waiting on a very blameful postmortem here. Yeah, I think the postmortem needs to be written on that. It's kind of funny how one application, an application that I loved and cherished, sort of disappeared from the internet. Although I like the Feedly product that kind of picked up the reins.

Starting point is 00:19:43 I imported everything there um i definitely think you know the enterprise customers the and i think even developers expect kind of a different level of trust in the provider than maybe just some experimental consumer app you know and i think google is it's been getting its head around that for the last i don't't know, 10 years of doing Google Cloud. Google is definitely on a journey to get the enterprise and get the sort of long-term support and reliability and sort of like all that enterprise interface stuff that companies kind of expect. It's pretty fun to see the rapid growth of cloud here. But I think you've got to go out and earn it every day, you know?

Starting point is 00:20:27 And, um, and I don't think it's as simple as what products or services you offer. It's also like the support and the high quality documentation and all that company interface stuff you have to provide, right? The sales and support and customer engineers. Um,

Starting point is 00:20:41 we're doing a lot to do things like teaching our customers AI with a sort of like a co-laboratory AI model with our customers. We're doing it around SRE. I think you had Liz on talking about SRE, and we're doing a lot of work with customers to sort of talk about our point of view on SRE and help adapt it and help the world kind of embrace these kind of operating models. So yeah, we're on a journey. You know, I think the company has gotten really big, but in all that, we have to stay really close with developers and, you know, customers and startups and stuff and connect with them in a way that makes sense.

Starting point is 00:21:18 To that end, there's also, I guess, a natural confusion where users see the name Google and there isn't a internal disambiguation for them of consumer-facing service like Reader and enterprise-facing service such as GKE. It seems from the outside that as a result that there's more of a focus at Google on developing new and exciting things than in supporting what's already been released. And when I talk to my friends at Google internally, I don't get that sense at all. But that's something that's difficult to, I guess, it's a difficult message to permeate out into the rest of the industry. Can you speak to that perception? I think the whole industry is kind of

Starting point is 00:22:03 on a treadmill of chasing the shiny things right now. I think, you know, when I look at the stats of sort of the rise of container use on GKE, like this industry is on a march to containerization. When I look at the consumption of our AI services, the industry is seeing incredible growth of AI services, programming with data across the whole industry. So I think there's a lot of noise out there and marketers going to market and talk about new stuff. Ultimately, what matters is that services get used and developers have great outcomes and we're listening to them to make those things better. You know, like we can't ship a client library and call it done. It's got to be

Starting point is 00:22:45 idiomatic. We can't just have functions. We need to support Go and cloud functions, right? We're racing to go do that. So there's definitely like some excitement when you can do breakthrough technology, but I think you got to follow through and make it real and make it robust and make it high quality and help ensure people have great outcomes with it. What do you think right now that the industry is getting wrong in its understanding or perception of GCP? I thought you were going to ask me a different question. It's like, what is the industry doing wrong overall? I actually want to tackle that for a second. Oh, absolutely. Well, to be fair, every conference where there's someone from a large tech company, if you're not careful, it comes across as, and now a large tech company tells a bunch of small companies what they're doing wrong. too that you know google can fall into this and all this cutting edge stuff we can all get wrapped

Starting point is 00:23:45 up on a treadmill so i'm kind of turning a spotlight back on us but i want to use it to tell a story of the industry please there's what 20 22 million developers in the world there's crushing demand for software and apps and innovation we don't like robocallers we like to press buttons on our phones. Things come to us. We like people to have great jobs so they can work productively and not like stamp paper forms. We like services to be automated. And yet we're not increasing the number of developers in the world.

Starting point is 00:24:18 We're stuck at 22 million. And that's because we're not including everyone we can include. And there's the human side of that, and there's the we're not including everyone we can include. And there's the human side of that, and there's the technology side of that. On the technology side, you know, more and more investment and easier onboarding for all different kinds of developers and the kind of technology that makes sense for them, web, cloud, a function, a mobile app, drag and drop, low code, you know, writing app script in Google Docs.

Starting point is 00:24:47 All those are great paths in. And I'd like to see all the vendors make those paths really, really easy and welcoming. And then on the human side, I think there's an obligation for us to go out all over the world and interface with developers and build these local communities and make them really welcoming, no matter which technology company you provide. I think Google falls into this trap. Like you said, what are we doing wrong? Give the Spanner example. We built maybe the most sophisticated database on the planet, but now I want to bring it to as many possible users as we possibly can and make it easy for them to consume. And the goal is not just to get them to as many possible users as we possibly can and make it easy for them to consume

Starting point is 00:25:25 and the goal is not just to get them to use our service the goal is to take this whole world of database complexity and start removing it for lots of use cases and simplify things for users so the developers can go build mega scale applications instead of dealing with replication sharding and and consistency issues. So I think if we do this right, in the long story arc, we're going to end with tens of millions more developers there with all different backgrounds from all different places and all different experiences. And I kind of want to see all the tech vendors

Starting point is 00:25:58 and all the hyperclouds and all the library providers really think about this and work on this. I think that you're going to see a lot of challenge in getting too far above the current number of developers for as long as you make developers continue to worry about things like replication delays, how to build out other things, having to deal with, I guess, the general housekeeping that they have to do today before they ever write one line of business logic or something that solves a problem. I think you're right about meeting people where they are. To that end, you mentioned that there's an event coming up, a DevFest. What is that exactly? Oh, I'm super excited about this. So we have,

Starting point is 00:26:40 Go has about 800 Google developer groups around the world. They're community organized. They get together every couple of weeks. They hold meetups. They do study jams and a lot of different things to kind of build a local community and write code together. And the technology to really anchor on our web, Android around the world is a really big platform and increasingly cloud. So we're holding a series of – the community is holding a series of events this fall called DevFest. And they're going to happen in 500 cities with on the order of 100,000 members of our community. We're also going to do like an online version for people that can't join in person.

Starting point is 00:27:21 But I kind of hope everybody that's kind of interested in Google technology gets plugged in locally, not to talk to Google necessarily, but to get to hear from other community members and hear what they like and what they don't like. But, you know, the Google developer group in Lagos, Nigeria has over 1,000 members. And Femi, who runs that, says it's an absolutely thriving startup scene and developer community.

Starting point is 00:27:44 So all over the world, there are these really kind of neat communities that have sort of formed around Google technologies, and we want to really support them. And DevFest this fall is going to be a lot of fun. Well, I'm looking forward to seeing it. I'll definitely make it a point to attend if it comes to a city near me.

Starting point is 00:27:59 Well, I don't know where you would be. You know, like, a lot of cities is 500 cities. So we'll get you set up. But community is super important to the health of platforms, and so we really want to support our communities as they put these things together. Well, thank you very much for taking time out of your week to speak with me. Yeah, Corey, this is a lot of fun, and I really like that the community is getting its hands around who Google is

Starting point is 00:28:23 and who we're growing up to be and our aspirations. And I think a lot of dialogue and a lot of listening is helping us make our products better and the whole sort of user experience around Google and Google services even better. I would agree. Thank you once again. Adam Seligman, VP of DevRel at Google. I'm Corey Quinn, and this is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever fine snark is sold.

Screaming in the Cloud - Episode 25: Kubernetes is Named After the Greek God of Spending Money on Cloud Services

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.