Screaming in the Cloud - The Future of Google Cloud with Richard Seroter

Episode Date: November 11, 2021

About RichardHe’s also an instructor at Pluralsight, a frequent public speaker, and the author of multiple books on software design and development. Richard maintains a regularly updated blog (seroter.com) on topics of architecture and solution design and can be found on Twitter as @rseroter. Links:Twitter: https://twitter.com/rseroterLinkedIn: https://www.linkedin.com/in/seroterSeroter.com: https://seroter.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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. This episode is sponsored in part by our friends at Vulture, spelled V-U-L-T-R,

because they're all about helping save money, including on things like, you know, vowels. So what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that, well, sure, they claim it is better than AWS's pricing. And when they say that, they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently elastic and open. They can mean the

same thing sometimes. They have had over a million users. Deployments take less than 60 seconds across 12 pre-selected operating systems, or if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something of the scale on their own. Try Vulture today for free by visiting vulture.com slash screaming and you'll

receive $100 in credit. That's v-u-l-t-r dot com slash screaming. You know how Git works, right? Sort of. Kind of. Not really. Please ask someone else. That's all of us. Git is how we build things, and Netlify is one of the best ways I've found to build those things quickly for the web. Netlify's Git-based workflows mean that you don't have to play slap and tickle with integrating arcane nonsense and webhooks, which are themselves about as well understood as Git. Give them a try and see what folks ranging from my fake Twitter for pets startup to global Fortune 2000 companies are raving about.

If you end up talking to them, because you don't have to, they get why self-service is important, but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y dot com. Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, back in the days of VH1, which was like MTV, except it played music videos, would have a show that was Where Are They Now? looking at former celebrities. I director of outbound product management. At that point, he basically had stars in his eyes and was aspirational around everything

he wanted to achieve. And now it's a year later and he has clearly failed because it's Google. So outbound products are clearly the things that they are going to be deprecating. And in the past year, I am unaware of a single Google Cloud product that has been outright deprecated. Richard, thank you for joining me. And what do you have to say for yourself? Yeah, where are they now? I feel like I'm the Leif Garrett of Cloud here joining you. So yes, I'm still here.

I'm still alive. A little grayer after 12 months in, but happy to be here chatting Cloud, chatting whatever else with you. I joke a little bit about, oh, Google winds up killing things. And let's be clear, your consumer division, which is, you know, Google, is prone to that. Understanding a company's org chart is a challenge. A year or two ago, I was of the opinion that I didn't need to know anything about Google Cloud, because it would probably be deprecated before I really had to know about it. My opinion has evolved considerably based upon a number of things I'm seeing from

Google. Let's be clear here. I'm not saying this to shine you on or anything like that. It's instead that I've seen some interesting things coming out of Google that I consider to be the right moves. One example of that is publicly signing multiple 10-year deals with very large, serious institutions like Deutsche Bank and others. Okay, you don't generally sign contracts with companies of that scale and intend not to live up to them. You're hiring Forest

Brazil as your head of content for Google Cloud, which is not something you should do lightly and not something that is a short-term play in any respect. And the customer experience has continued to improve. Google Cloud products have not gotten worse. And I'm seeing in my own customer conversations that discussions about Google Cloud have become significantly less dismissive than they were over the past year. Please go ahead and claim credit for all of that. Yeah, I mean, that changed a year ago when I joined. So Thomas Kurian's made a huge impact on some of that. You saw us launch the enterprise APIs thing a while back, which was, hey, here's, for the most part, every one of our products that has a fixed API. We're not going to deprecate it

without a year's notice, whatever it is. We're not going to make certain types of changes. Maybe that feels like, well, you should have had that before. All right, all we can do is improve things moving forward. So I think that was a good change. Oh, I agree. I think that was a great thing to do. You had something like 80 some odd percent coverage of Google cloud services and great. That's going to only increase with time I can imagine, but I got a little pushback from a few Googlers for not being more congratulatory towards them for doing this. And look, it's a great thing. Don't get me wrong, but you don't exactly get a whole lot of bonus points and kudos and positive press coverage,

not that I'm press, for doing the thing you should have been doing all along. This is great. This is necessary. And it demonstrates a clear awareness that there was, rightly or wrongly, a perception issue around the platform's longevity, and that you've gone significantly out of your way to wind up addressing that in ways that go far beyond just yelling at people on Twitter they don't understand the true philosophy of Google Cloud, which is the right thing to do. Yeah. I mean, as you mentioned, look, the consumer side is very experimental in a lot of cases. I still mourn Google Reader. Like those things don't matter. Of course. So I get that.

Google Cloud, and of course, we have the same cultural thing. But at the same time, there's a lifecycle management that's different in Google Cloud. We do not deprecate products that much. You know, enterprises make decade-long bets. I can't be swap changing databases or just turning off messaging things.

Instead, we're building a core set of things and making them better. So I like the fact that we have a pretty stable portfolio that keeps getting a little bit bigger, not crazy bigger. I like that we're building a core set of things and making them better. So I like the fact that we have a pretty stable portfolio that keeps getting a little bit bigger, not crazy bigger. I like that we're not just throwing everything out there saying rock on. We have some opinions. But I think that's been a positive trend.

Customers seem to like that we're making these long term bets. We're not going anywhere for a long time. And our earnings quarter after quarter shows that, boy, this will actually be a profitable business pretty soon. Oh, yeah. People love to make hay. And by people, I stretch the term slightly and talk about investment analysts say that Google Cloud is terrible because at the beginning of your last annual report, you were losing something like $5 billion a year on Google Cloud. And everyone

looked at me strangely when I said, no, this is terrific. What that means is that they're investing in the platform. Because let's be clear, folks at Google tend to be intelligent by and large, or at least intelligent enough that they're not going to start selling cloud services for less than it costs to run them. So yeah, it is clearly an investment in the platform and growth of it. The only way it should be turning a profit at this point is if there's no more room to invest that money back into growing the platform given your market position. I think that's a terrific thing, and I'm not worried at all about it losing money. I don't think anyone should be. Yeah, I mean, strategically, look, this doesn't

have to be the same type of moneymaker that even some other clouds have to be to their portfolio. Like, look, this is an important part, but you look at those 10-year deals, Corey, that we've been signing. When you look at Univision, that's a YouTube partnership. You look at Ford that had to do with Android Auto. You look at these others. Like, this is where us being also a consumer and enterprise SaaS company is interesting. Because this isn't just who's cranking out the best IaaS. I mean, that can be boring stuff over time.

It's like, who's actually doing the stuff that maybe makes a traditional company more interesting because they partner on some of those SaaS services? So those are the sort of deals and those are sort of arrangements where cloud needs to be awesome and successful and make money. It doesn't need to be the biggest revenue generator for Google. So when we first started talking, you were newly minted as a director of outbound product management. And now you are not the only one. There are apparently 60 of you there, and I'm no closer to understanding what the role encompasses. What is your remit?

Where do you start? Where do you stop? Yeah, that's a good question. So there's outbound product management teams, mostly associated with the portfolio area. So network, storage, AI, analytics, database, compute, application modernization, these sort of stuff, which is what I cover. Containers, dev tools, serverless. Basically, I am helping make sure the market understands the product and the product

understands the market. And not to be totally glib, but a lot of that is we are amplification. I'm amplifying product out to market, analysts, field people, partners. Do you understand this thing? Can I help you put this in context? But then really importantly, I'm trying to help make sure we're also amplifying the market back to our product teams. Are you getting real customer feedback? Do you know what that analyst thinks? Have you heard what happened in the competitive space? And so sometimes companies seem to miss that and PMs poke their head up when I'm about to plan a product or I'm about to launch a product because I need some feedback. But keeping that constant pulse on the market, on customers, on what's going on. I think that can be a secret

weapon. I'm not sure everybody does that. Spending as much time as I do on bills, admittedly AWS bills, but this is a pattern that tends to unfold across every provider I've seen. The keynotes are chock full of awesome managed service announcements, things that are effectively turnkey at further up the stack levels. But the bills invariably look a lot more like, yeah, we spend a bit of money on that. And then we run 10,000 virtual instances in a particular environment. And we just treat it like it's an extension of our data center. And that's not exciting. That's not fun, quote unquote. But it's absolutely what customers are doing. And I'm not going to sit here and tell them that they're wrong for doing it.

That is the hallmark of a terrible consultant of, I don't understand why you're doing what you're doing, so it must be foolish. How about you stop and gain some context into why customers do the things that they do? No, I send around a goofy newsletter every week to a thousand or two people just on things I'm learning from the field, from customers, trying to make sure we're just thinking bigger, right? A couple of weeks ago, I wrote an idea about modernization is awesome. And I love when people upgrade their software. By the way, most people, migration is a heck of a lot easier than if I can just get this into your cloud. Yeah, I don't love that. That's not the most interesting thing to move VMs around.

But most people in their budget don't have time to rewrite every Java app to go. Everybody's not changing.NET Framework to.NET Core. Like, who do I think everybody is? No, I just need to try to get some incremental value first. Yes, then hopefully I'll swap out my self-managed SQL database for a spanner or a managed service. Of course, I want all that. But this idea that I can turn my line of business loan processing app into a thousand functions overnight is goofy. So how are we instead thinking more pragmatically about migration and then modernizing some of it? Right. But even that sort of mindset, look, Google thinks about innovation, modernization first. So also just trying to help us take a step back and go, gosh, what is a normal path? Well,

it's a lot of migration first, some modernization, and then there's some steady state work there. One of the things that surprised me the most about Google Cloud and the market across the board has been the enthusiastic uptake for enterprise workloads. And by enterprise workloads, I'm talking about things like SAP HANA is doing a whole bunch of deployments there. We're talking big iron style enterprise-y things that, let's be honest, contravene most of the philosophy that Google has always held and espoused publicly, at least on conference stages, about how software should be built. And I thought that that would cut against them and make it very difficult for you folks to gain headway in that market. And I could not have

been more wrong. I'm talking to large enterprises who are enthusiastically talking about Google Cloud. I've got to level with you. Compared to a year or two ago, I don't recognize the place. I mean, some of that, you know, honestly, in the conversations I have, and whatever, I do a handful of customer calls every week. I think folks still want something familiar, but you're looking for maybe a further step on some of it. And that means like, yes, is everybody going to offer VMs? Yeah, of course. Is everyone going to have MySQL? Obviously. But if I'm an enterprise and I'm doing these generational bets, can I cheat a little bit? Maybe if I partner with a more of an innovation partner versus maybe just the easy next step, am I buying some more relevance for the long term? So am I getting into an environment that has

some really cool native zero trust stuff? Am I getting into an environment with global backend services and I'm not just stitching together a bunch of regional stuff? How can I cheat by using a more innovation vendor versus just lifting and shifting to what feels like hosted software in another cloud? I'm seeing more of that because these migrations are tough. Nobody should be just randomly switching clouds. That's insane. So can I make maybe one of these big bets with somebody who feels like they might actually even improve my business as a whole

because I can work with Google Pay and improve how I do mobile payments or I could do something here with Android or heck, all my developers are using Angular and Flutter. I'm not going to get some benefit from working with Google. So we're seeing that kind of add-on effect of maybe this is a place not just to host my VMs, but to take a generational leap. And I think that you're positioning yourselves in a way to do it. Again, talk about things that you wouldn't have expected

to come out of Google of all places, but your console experience has been first rate and has been for a while. The developer experience is awesome. I don't need to learn the intricacies of 12 different services for what I'm trying to do just in order to get something basic up and running. I can stop all the random little billing things in my experimental project with a single click, which that admittedly has a confirm, which you kind of want, but it lets you reason about these things. It lets you get started building something. And there's a consistency and cohesiveness to the console that, again, I am not a graphic designer by any stretch of the imagination. My most commonly used user interface is a green screen shell prompt,

and then I'm using Vim to wind up writing something horrifying, ideally in Python, but more often in YAML. And that has been my experience. But just clicking around the console, it's clear that there was significant thought put into the design, the user experience, and the way of approaching folks who are starting to look very different from a user persona perspective. I can, I mean, I love our user research team. They're actually fun to hang out with and watch what they do. But you have to remember Google as a company. I don't know, cloud's the first thing we had to sell. We didn't have to sell Gmail. I remember 15 years ago, people were waiting for invites and who buys maps or who buys YouTube? Like for the most part, we've had to build things that were naturally interesting

and easy to use because otherwise you would just switch to anything else. So everything was free. So some of that does infuse Google cloud. Like let's just make this really easy to use. And let's just make sure that maybe you don't hate yourself when you're done jumping into a shell from the middle of the console. So that should be really easy to do or upgrade a database or make changes to things. So I think some of the things we've learned from the consumer good side have made their way into how we think of UX and design, because maybe this stuff shouldn't be terrible. There's a trope going around where I wound up talking about the next million cloud customers. And I'm going to have to write a sequel to it because it turns out that I've made a fundamental

error in that I've accepted the narrative that all of the large cloud vendors are pushing to the point where I heard from so many folks. I just accepted it unthinkingly and uncritically, and that's not what I should be doing. And we'll get to what I was wrong about in a minute. But the thinking goes that the next big growth area is large enterprises, specifically around corporate IT. And those are folks who are used to managing things in a GUI environment, which is fine, and clicking around in web apps. Now, it's easy to sit here on our high horse and say, oh, you should learn to write code or YAML, which is basically code. Cool. As an individual, I agree. Someone should, because as soon as they

do that, they are now able to go out and take that skill to a more lucrative role. The company then has to backfill someone into the role that they just got promoted out of, and the company still has that dependency. And you cannot succeed in that market with a philosophy of, oh, you built something in the console. Now throw it away and do it right. Because that is maddening, that user persona. Rightfully so. I'm not that user persona, and I find it maddening when I have to keep tripping over that particular

thing. How did that come to be from your perspective? First, do you think that is where the next million cloud customers come from? And have I adequately captured that user persona? Or am I completely off in the weeds somewhere? I mean, I shared your post internally when that one came out, because that resonated with me of how we were thinking about it. Again, it's easy to think about the cloud native operators, it's Spotify doing something amazing, or this team at Twitter doing something or whatever. And it's not even to be disparaging.

Like, look, I spent five years in enterprise IT and I was surrounded by operators who had to run a dozen different systems. They weren't dedicated to just this thing or that. So what are the tools that make my life easy? A lot of the software just comes with UIs for quick install and upgrades. And how does that logic translate to this cloud world? I think that stuff does matter. How are you meeting these people a little better where they are? I think the hard part that we will always have in every cloud provider is, I think you've said this in different forums, but how do I not sometimes rub the data center on my cloud or vice versa? I also don't want to change the experience so much where I degrade it over the long term. I've actually somehow done something worse. So can I meet those people

where they are? Can we pull some of those experiences in, but not accidentally do something that kind of messes up the cloud experience? I mean, that's a fine line to walk. Does that make sense to you? Do you see where there's a, I don't know, you could accidentally cater to a point. At some point, what they're asking for becomes actively harmful or disadvantageous to wind up providing for them. I want you to run my data center for me is, on some level, what some cloud environments look like. And I'm not going to sit here and tell people they're inherently wrong for that. Their big reason for moving to the cloud

was because they keep screwing up or placing failed hard drives in their data center. So we're going to put it in the cloud. Is it more expensive that way? Well, sure. In terms of what actual cash outlay, it almost certainly is, but they're also not going down every month when a drive fails. So what's the value of that? It's a capability story. That becomes interesting to me. And I think that trying to sit here in isolation and say that, oh, this application is not how we would build it at Google. And it's, yeah, you're Google. They are, insert an entire universe of different industries that look nothing whatsoever like Google. The constraints are different. The

resources are different. And their approach to problem solving are different. When you built out Google, and even when you're building out Google Cloud, look at some of the oldest, cruftiest stuff you have in your entire, all of Google environment, and then remember that there are companies out there that are hundreds of years old. It's a different order of magnitude as far as era, as far as understanding of what's in the environment,

and that's okay. It's a very broad and very diverse world. Yeah. I mean, that's again, why I've been thinking more about migration than even some of the modernization piece. Should you bring your network architecture from on-prem to the cloud? I mean, I think most cases, no, but I understand sometimes that edge firewall internal trust model you had on-prem. Okay. Trying to replicate that. So yeah, like you said, I want to meet people where they are. Can we at least find some strategic leverage points to upgrade aspects of things as you get to a cloud to save you from yourself in some places? Because all of a sudden you have 10 regions and you only had one data center before, so

many more rooms for mistakes. Where are the right guardrails? We're probably more opinionated than others at Google Cloud. I don't really apologize for that completely, but I understand. I mean, I think we've loosened up a lot more than maybe people would have thought a few years ago from being hyper opinionated on how you run software. I will actually push back a bit on the idea that you should not replicate your on-premises data center in your cloud environment. Sure. Are there more optimal ways to do it that are arguably more secure? Absolutely. But a common failure mode in moving from data center to cloud is, all right, we're going to start embracing this entirely new cloud networking paradigm. And it is confusing. And your team that knows how the data center network works really well are suddenly in way over their heads and they're inadvertently exposing things they don't intend to

or causing issues. The hard part is always people, not technology. So when I glance at an environment and see things like that, perfect example. Are there more optimal ways to do it? Oh, from a technology perspective, absolutely. How many engineers are working on that? What's their skill set? What's their position on all this? What else are they working on? Because you're never going to find a team of folks who are world-class experts in every cloud. It doesn't work that way. No doubt. No doubt. You're right. There's areas where we have to at least have something that's going to look similar to let you replicate aspects of it. I think it's, again, it'll just be interesting to watch. And I have enough conversations with customers who do ask,

hey, where are the places we should make certain changes as we evolve? And maybe they are tactical and they're not going to be the big strategic redesign their entire thing. But it is good to see people not just trying to shovel everything from one place to the next. This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals, having the highest quality content in tech and cloud skills and building a good community that is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. It's both useful for individuals and large enterprises, but here's what makes this something new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are.

For the next four weeks, you'll have a chance to prove yourself. Compete in four unique lab challenges where they'll be awarding more than $2,000 in cash and prizes. I'm not kidding. First place is $1,000. Pre-register for the first challenge now. One that I picked out myself on Amazon SNS image resizing by visiting cloudacademy.com slash Corey, C-O-R-E-Y. That's cloudacademy.com slash Corey. We're going to have some fun with this one. earlier. What I think I've gotten wrong by accepting the industry talking points on is that

the next million cloud customers are big enterprises moving from data centers into the cloud. There's money there, don't get me wrong, but there is a larger opportunity in empowering the creation of companies in your environment. And this is what certain large competitors of yours get very wrong where it's we're going to launch a whole bunch of different services that you get to build yourself from popsicle sticks right that is not useful but companies that are trying to do interesting things or people who want to found companies to do interesting things want something that looks a lot more turnkey. If you are going to be building cloud offerings that, for example, are terrific building blocks for SaaS companies, then it behooves you to do actual investments rather than just a generic credit offer into spurring the creation of those types of companies. If you want to build a company that does payroll systems in a SaaS, cloud way, partner with us, do it here. We'll give you a bunch of credits. We will introduce you to your first 10 prospective customers and effectively actually invest in a company's success as opposed

to pitch deck invest, which is, yeah, we'll give you some discounting and some credits, and that's our quote-unquote investment. Actually be there with them as a partner. And that's going to take years for folks to wrap their heads around, but I feel like that is the opportunity that is significantly larger, even than the embedded existing IT space. Because rather than fighting each other for slices of the pie, I'm much more interested in expanding that pie overall. One of my favorite questions to get asked, because I think it is so profoundly missing the point, is, do you think it's possible for Google to go from number three to number two, wherever the number happens to be at some point?

And my honest considered answer is, who gives a shit? Because number three or number five or number 12, it doesn't matter to me, is still how many hundreds of billions of dollars in the fullness of time? Let's be real for a minute here. The total addressable market is expanding faster than any cloud or clouds are going to be able to capture all of. Yeah. Hey, look, whoever can be more profitable solving user problems, I really don't care about the final revenue number. I can be the number one cloud tomorrow by making Google Cloud free. What's the point? That's not a sustainable business. So if you're just going for who can deploy the most vCPUs or who can deploy the most whatever, there's ways to game that. I want to make sure we are just uniquely solving problems better than anybody else. Sorry, forgive me. I sort of zoned out for a second there because I'm just so taken aback and shocked by the idea of someone working at a large cloud provider who expresses a philosophy that isn't lying awake at night fretting over the possibility that someone

who isn't them is making money somewhere. I mean, your idea there, though, I mean, it'll be interesting to watch your kind of the maker's approach of, you know, are you enabling that next round of startups, the next round of people who want to take? I mean, I like honestly, I like the things we're doing building block wise, even with our AI. We're not just handing you a vision API. We're giving you a loan processing AI that can process certain types of docs. It's more packaged version of AI. Same with health care.

Same with whatever. I can imagine certain startups or a company idea going, hey, maybe I could disrupt or serve a new market. I always loved what Square did. They've disrupted emerging markets, small merchants here in North America, wherever, where I didn't need a big expensive point of sale system. Like you just gave me the nice right building blocks to disrupt and run my business. Maybe Google Cloud can continue to provide better building blocks, but I do like your idea of actually investment zones, getting part of this. Maybe the next million users are founders, and it's not just getting into some of these companies with, frankly, 10, 20, 30,000 people in IT. I think there's still plenty of room in these big

enterprises to unlock many more of those companies, much more of their business. But to your point, there's a giant market here that we're not all grabbing yet. For crying out loud, there's tons of opportunity out here. This is not zero-sum. Taking a step further beyond that. And today, if you have someone who's enterprising early on in their career, maybe they just got out of school, maybe they have just left their job and are ready to snap, or they have some severance money that they want to throw into something, great.

What do they want to do if they have an idea for a company? Well, today that answer looks a lot like, well, time to go to a bootcamp and learn to code for six months so you can build a badly done MVP well enough to get off the ground and get some outside investment and then go from there.

Well, what if we cut that part out entirely? What if there were building blocks of, I don't need to know or care that there's a database behind it or what a database looks like? Picture Visual Basic in a web browser for building apps. And just take this bit of information I give you and store it and give it back to me later. Sure, you're going to have some significant challenges in the architecture of something like that as it goes from this thing that I'm talking about as an MVP to something planet scale, like a Spotify, for example. But that's not most businesses, and that's okay.

Get out of the way and let people innovate and iterate on what it is they're doing more rapidly and make it more accessible to teach people. That becomes huge. That gets the infrastructure bits that cloud providers excel at out of the way. And all it really takes is packaging those things into a golden path of what a given company of a particular profile should be doing, unless they have reason to deviate from it. And instead of having this

giant paradox of choice issue, it's, oh, okay, I'll drag, drop, build things accordingly. And under the hood, it's doing all the configuration of services, and that's great. But suddenly you've made being a founder of a software company, fundamentally, accessible to people who are not themselves software engineers. And I know that's anathema to some people, and I don't even slightly care because I am done with gatekeeping. Yeah. No, it's exciting if that can pull off. I mean, it's not the years ago where how much capital was required to find a rack and do all sorts of things with tech and hire some developers. And it's an amazing time to be software creators now. The more we can enable that, yeah, I'm along for that journey. Sign me up. I'm looking forward to seeing how it winds up shaking out.

So I want to talk a little bit about the paradox of choice problem that I just mentioned. If you take a look at the various compute services that every cloud provider offers, there are an awful lot of different choices as far as what you can run. There's the VM model, there's containers like 3AWS, you have 17 ways to run those, and you wind up in the serverless function story and other things here and there and manage services. I mean, and honestly, Google has a lot of them, nowhere near as many as you do failed messaging products, but still an awful lot of compute options. How do customers decide? What is the decision criteria that you see? Because the worst answer you can give someone who doesn't really know what they're doing is,

it depends. Because people don't know how to make that decision. It's what factors should I consider then while making that decision? And the answer has to be something somewhat authoritative, because otherwise they're going to go on the internet and get yelled at by everyone because no one is ever going to agree on this except that everyone else is wrong. Yeah, I mean, on one hand, look, I like that we intentionally have fewer choices than others, because I don't think you need 17 ways to run a container. I think that's excessive.

I think more than five is probably excessive, because as a customer, what is the trade-off? Now I would argue, first off, I don't care if you have a lot of options as a vendor, but boy, the back ends of those better be consistent. Meaning if I have a CICD tool in my portfolio and it only writes to two of them, shame on me, right? Then I should make sure that at least CICD, identity management, log management, monitoring, arguably your compute runtime should be a late binding choice. And maybe that's blasphemous because somebody says, I want to start up front knowing it's a function or I want to start it to VM. How about as a developer, I couldn't care less. How about I just build cool software? And maybe even at deploy time, I say this better fits in running in Kubernetes. This is better in a virtual machine. And my cost of changing that later is meaningless because, hey, if it is in

the container, I can switch it between three or four different runtimes. The identity management's the same. It logs the exact same way. I can deploy CICD the same way. So first off, if those things aren't the same, then the vendor is messing up. So the customer shouldn't have to pay the cost of that. And then there gets to be other actual criteria. Look, I think you are looking at the workload itself, the team who makes it and the strategy to figure out a runtime. It's easy for us. Google Compute Engine for VMs, containers go in GKE, manage services that need some containers or some apps around them or cloud functions in Cloud Run. Like it's fairly straightforward. It's going to be an or situation,

not an and situation, not an or, which is great. But we're at least saying like the premium way to run containers in Google Cloud for systems is GKE. There you go. If you do have a bunch of managed services in your architecture and you're stitching them together, then you want more serverless things like Cloud Run and Cloud Functions.

If you want to just really move some existing workloads, GCE is your best choice. I like that that's fairly straightforward. There's still going to be some it depends, but it feels better than nine ways to run Kubernetes engines. I'm sure we'll see them in the fullness of time. So talk about Anthos a bit.

That was a thing that was announced a while back and it was extraordinarily unclear what it was. And then I looked at the pricing and it was $10,000 a month with a one-year minimum commitment. I was like, oh, it's not for me. That's why I don't get it. And I haven't really looked back in a sense,

but it is something else now. It almost feels like a rapper brand in some respects. How's it going? Lending anywhere? Yeah. Consumption, we'll talk more upcoming months on some of the adoption, but we're finally getting the hockey stick,

which always comes with delayed with platforms because nobody adopts platforms quickly. They buy the platform and a year later, they start to actually build new development, migrate the things they have. So we're starting to see this sort of growth. But back to your first point, and I even think I poorly tried to explain it a year ago with you. Basically, look, Anthos is the ability to manage fleets of GKE clusters wherever they are. I don't care if they're on-prem. I don't care if they're in Google Cloud. I don't care if they're Amazon. We have one customer who only uses Anthos on AWS. Awesome. Rock on. So how do I put GKE clusters everywhere, but then do fleet management? Because look, some people are doing an app per cluster. They don't

want to jam 50 apps in a cluster from different teams because they don't like the idea that this app requires root access. Now you can screw around with mine or you did an update that broke the cluster. I don't want any of that. So you're going to see companies more doing even app per cluster, app per developer per cluster. So now I have a fleet problem. How do I keep it in sync? How do I make sure policy is consistent? Those sorts of things. So Anthos is kind of solving the fleet management challenge and replacing people's first gen app platform. Seeing a lot of those use cases, hey, we're retiring our first version of Docker Enterprise, Mesos, Cloud Foundry, even OpenShift saying, all right, now's the time for our next version of our app platform. How about GKE plus Cloud Run on top of it plus other stuff?

Sounds good. So going well as a sort of, as you mentioned, there's a brand story here, mainly because we've also done two things that probably matter to you. A, we changed the price a lot. No minimum commit, remarkably 20% of the cost it was when we launched on purpose because we've gotten better at this. So much cheaper, no minimum commit, pay as you go. Beyond premises on bare metal with GKE, pay by the hour. I don't care. Sounds great. So you can do that sort of stuff. But then more importantly, if you're a GKE customer and you just want config management, service mesh, things like that, now you can buy all of those independently as well. And Anthos is really

the brand for fleet management of GKE. And if you're on Google Cloud only, it adds value. If you're off Google Cloud, if you're multi-cloud, I don't care. But I want to manage fleets of compute clusters and create them. We're going to keep doubling down on that. The big problem historically for understanding a lot of the adoption paradigm of Kubernetes has been that it was, to some extent, a reimagining of how Google ran and built software internally. And I thought at the time the idea was, from a cynical perspective, that, all right, well, your crappy apps don't run well on Google-style infrastructures, so we're going to teach the entire world how to write software the way that we do. And then you wind

up with people running their blog on top of Kubernetes, where it's one of those, like, the first blog post is like, how I spent the last 18 months building Kubernetes. And, okay, that is certainly a philosophy and an approach, but it's almost approaching Windows 95 launch level of hype, where people who didn't own computers were buying copies of it in some level. And I see the term come up in conversations in places where it absolutely has no place being brought up. How do I run a Kubernetes cluster

inside of my laptop? And it's, what you got going on in there, buddy? What you think you're trying to do here? Because you just said something that means something that I think is radically different to me than it is to you. And again, I'm not here to judge other people's workflows. They're all terrible except

for mine, which is an opinion held by everyone about their own workflow. But understanding where people are, figuring out how to get there, how to meet customers where they are and empower them. And despite how heavily Google has been into the Kubernetes universe since its inception, you're very welcoming to companies and loudmouth individuals on Twitter who have no use for Kubernetes. And working through various products you offer, I don't ever feel like a second-class citizen. There's really something impressive about that, of not letting the hype dictate the product and marketing decisions. Yeah, look, I think I tweeted it recently. I think the future of software is managed services

with containers in the gap. For the most part, whereas if you can use managed services, please do use them wherever you can. And if you have to sling some code, maybe put it in a really portable thing that's really easy to run in lots of places. So I think that's smart. But for us, look, I think we have the best container workflow from dev tools and build tools and artifact registries and runtimes. Plenty of people aren't running containers and you shouldn't be running Kubernetes all over the place. If it makes sense for the workload, I think it's better than a VM at the retail edge. Can I run a small cluster instead of a weird point of sale Windows app? Maybe. Maybe it makes sense to have a lightweight Kubernetes cluster there for consistency purposes. So for me, I think it's a great medium for a subset of software. Google

Cloud's going to take whatever you got, which is great. I think containers are great. But at the same time, I'm happily going to let you deploy a function that responds to you adding a storage item to a bucket, or at the same time, give you a SaaS service that replaces the need for any code. All of those are terrific. So yeah, we love Kubernetes. We think it's great. We're going to be the best version to run it, but that's not going to be your whole universe. No, and I would argue it absolutely shouldn't be. Right. Agreed. Now, again, for some companies, it's a great replacement for this giant fleet of VMs that all runs at 8% utilization. Can I stick this into a bunch of high density clusters? Absolutely, you should. You're going to save an absolute fortune doing that and probably pick up some resilience and

functionality benefits. But to your point, do I want to run a WordPress site in there? I don't know. Probably not. Do I need to run my own MySQL? I'd prefer you not do that. So in a lot of cases, don't use it unless you have to. That should go for all compute nowadays. Use managed services. I'm a big believer in going down that approach just because it is so much easier than trying to build it yourself from popsicle sticks because you theoretically might have to move it someday in the future, even though you're not. Right. It lets me feel better about a thing that isn't going to be used by anything that I'm doing in the near future. I just don't pretend to get it. No, I don't install a general

purpose electric charger in my garage for any electric car I may get in the future. I charge for the one I have now. I just want it to work for my car. I don't want to plan for some mythical future. So yeah, premature optimization over architecture or death in IT, especially nowadays where speed matters. Don't waste your time building something that can run in nine clouds. Richard, I want to thank you for coming on again a year later to suffer my slings, arrows, and other various implements of misfortune. If people want to learn more about what you're doing, how you're doing it, possibly to pull a Forest Brazil and go work with you, where can they find you?

Yeah, we're a fun place to work. So, you know, you can find me on Twitter at rseroter, R-S-E-R-O-T-E-R. Hang out on LinkedIn. Annoy me on my blog, seroter.com, as I try to at least explore our tech from time to time and mess around with it. But this is a fun place to work. There's a lot of good stuff going on here.

And if you work somewhere else too, we can still be friends. Thank you so much for your time today. Richard Seroter, Director of Outbound Product Management at Google. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, of outbound product management at Google? I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast,

please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment into which you have somehow managed to shove a running container. If your AWS bill keeps rising managed to shove a running container. Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point.

Visit duckbillgroup.com to get started. This has been a humble pod production stay humble