Announcer: 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.

Corey: This episode is sponsored in part by our friends at Vultr. 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—while sure they claim its better than AWS pricing—and when they say that they mean it is 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 going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve 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 Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you’ll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.

Corey: You know how git works right?

Announcer: Sorta, kinda, not really Please ask someone else!

Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I’ve found to build those things quickly for the web. Netlify’s git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, 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.com

Corey: 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 will not use the term washed up because that’s going to be insulting to my guest.

Richard Seroter is a returning guest here on Screaming in the Cloud. We spoke to him a year ago when he was brand new in his role at Google as 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?

Richard: 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 twelve months in, but happy to be here chatting cloud, chatting whatever else with you.

Corey: I joke a little bit about, “Oh, Google winds up killing things.” And let’s be clear, your consumer division which, you know, Google is prone to that. And 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 ten-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 Forrest Brazeal 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.

Richard: Yeah. I mean, the changes a year ago when I joined. So, Thomas Kurian has 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.

Corey: 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 [laugh] all along.

It’s, “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.

Richard: 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—

Corey: As do we all.

Richard: 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 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 it—boy, this will actually be a profitable business pretty soon.

Corey: 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 your last annual report you’re 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.

Richard: 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. Look, this is an important part, but you look at those ten-year deals 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, 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 sorts of deals and those sorts of arrangements where cloud needs to be awesome, and successful, and make money, doesn’t need to be the biggest revenue generator for Google.

Corey: 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?

Richard: 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-y 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. You’re 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.

Corey: 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?

Richard: 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. 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 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 of 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? 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 the normal path? Well, it’s a lot of migration first, some modernization, and then there’s some steady-state work there.”

Corey: One of the things that surprised me the most about Google Cloud in 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, countervene 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 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 a level with you, compared to a year or two ago, I don’t recognize the place.

Richard: Mmm. I mean, some of that, 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, and 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 environment that has some really cool native zero-trust stuff? Am I getting into 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; aren’t I 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.”

Corey: 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.

Richard: 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 is the first thing we had to sell. Did have to sell Gmail. I remember 15 years ago, people were waiting for invites. And who buys Maps or who buys YouTube? 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 because everything was free.

So, some of that does infuse Google Cloud, “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.” It’s like, 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 to how we think of UX and design because maybe this stuff shouldn’t be terrible.

Corey: 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 to 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 often the weeds somewhere?

Richard: 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
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 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 certain audience too much, and change the experience for the worse?

Corey: Yes, and no. My philosophy on it is that you have to meet customers where they are, but only 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 replacing 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 actual cash outlay, it almost certainly is, but they’re also not going down every month when a drive fails, so once 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—

Richard: Sure.

Corey: —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 craftiest 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.

Richard: 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 say, 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 ten 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 [laugh] would have thought a few years ago, from being hyper-opinionated on how you run software.

Corey: 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.

Richard: No doubt. No doubt, you’re right. There’s areas where we have to at least have something that’s going to look similar, let you replicate aspects of it. I think it’s—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.

Corey: 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 the is rich and full of IT and engineering professionals. You wouldn’t think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it 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 $2000 in cash and prizes. I’m
not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image
resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That’s cloudacademy.com/corey. We’re gonna have some fun with this one!

Corey: Now, to follow up on what I was saying 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. Great. 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 will give you a bunch of credits. We will introduce you to your first ten prospective customers.”

And effectively actually invest in a company 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,” or whatever 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 twelve—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.

Richard: Yeah. Hey, look, whoever who’ll 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.

Corey: Sorry, forgive me. I just 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 of someone who isn’t them as making money somewhere.

Richard: [laugh]. I mean, your idea there, it’ll be interesting to watch, kind of, the maker’s approach of are you enabling that next round of startups, the next round of people who want to take—I mean, 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, that more packaged version of AI. Same with healthcare, 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 love 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. 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.

Corey: Take it 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 boot camp 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 or 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, if—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.

Richard: 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 the 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.

Corey: 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—if you’re in AWS, you have 17 ways to run those—and you wind up—any of the serverless function story, and other things here and there, and managed 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.

Richard: Mm-hm. 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 backends of those better be consistent.

Meaning if I have a CI/CD tool in my portfolio and it only writes to two of them, shame on me. Then I should make sure that at least CI/CD, 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’s a 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 the same, it logs the exact same way, I can deploy CI/CD 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 the runtime.

It’s easy for us. Google Compute Engine for VMs, containers go in GKE, managed services that need some containers, there are some apps around them, are Cloud Functions and Cloud Run. Like, it’s fairly straightforward and it’s going to be an OR situation—or an AND situation not an OR, which is great. But we’re at least saying 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. And if you want to just really move some existing workload, 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.

Corey: I’m sure we’ll see them in the fullness of time.

Richard: [laugh].

Corey: 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, and is like, “Oh, it’s not for me. That’s why I don’t get it.” And I haven’t really looked back at it since. But it is something else now. It almost feels like a wrapper brand, in some respects. How’s it going? [unintelligible 00:29:26]?

Richard: Yeah. Consumption, we’ll talk more upcoming months on some of the adoption, but we’re finally getting the hockey stick, which always comes 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 the 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 the 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 didn’t 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 is 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 at 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. Be on-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.

Corey: 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 infrastructure so we’re going to teach the entire world how to write software the way that we do.” And then you end 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, on 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?”

Richard: [laugh].

Corey: “What do 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 loud-mouth 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 of it.

Richard: 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, but plenty of people are running containers, and you shouldn’t be running Kubernetes all over the place. That 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 is 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, where 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.

Corey: No, and I would argue it absolutely shouldn’t be.

Richard: [laugh]. Right. Agreed. Now again, for some companies, it’s a great replacement for this giant fleet of VMs that all runs at eight percent 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.

Corey: 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.

Richard: [laugh]. Right.

Corey: And 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.

Richard: 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.

Corey: 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 Forrest Brazeal and go work with you, where can they find you?

Richard: Yeah, we’re a fun place to work. So, 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.

Corey: 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, 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The 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.

Announcer: This has been a HumblePod production. Stay humble.