The New Google Cloud with Richard Seroter

About Richard Seroter
Richard Seroter is Director of Outbound Product Management at Google Cloud, with a master’s degree in Engineering from the University of Colorado. He’s also an instructor at Pluralsight, the lead InfoQ.com editor for cloud computing, a frequent public speaker, the author of multiple books on software design and development, and a former 12-time Microsoft MVP for cloud. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.


Links Referenced

Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: You’ve got an incredibly complex architecture, which means monitoring it takes a dozen different tools. We all know the pain and New Relic wants to change that. They’ve designed everything you need in one platform, with pricing that’s simple and straightforward; no more counting hosts. You can get one user and 100 gigabytes per month, totally free. Check it out at newrelic.com. Observability made simple.

Corey: It’s—at least of this recording—morning on the west coast, which means there’s no better time than to inflict a homework assignment upon you in the form of a 42-page ebook from StackRox. Learn about the dancing flames of EKS cluster security, evade the toxic dumpster of the standard controls, and tame the wild beast of best practices for minimizing the risk around cluster workloads. Become renowned for your feats of daring as you learn the specific requirements for securing and EKS cluster and its associated infrastructure. To learn more, visit snark.cloud/stackrox. That’s snark dot cloud slash stack-R-O-X.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Richard Seroter, director of outbound product management at Google Cloud. Richard, welcome to the show.

Richard: Thank you for having me, Corey, this is going to be fun.

Corey: I hope so. So, outbound product management; is that the list of products that Google has deprecated and you're in the process of transitioning into a legacy state and writing the exciting blog post, or is it something more nuanced slash less insulting?

Richard: I wish that was it. Boy, that'd be fun. That would be great if they told me that. No, it's more or less, how do you act as the shim between the day-to-day product work, ship product, plan things, as well as some of the go-to-market, the messaging, the talking to analysts, the customer presentations, and then pulling that feedback back, and then helping overall with strategy for the given portfolio.

Corey: So, it sounds like an almost impossible job because if I take a look at GCP, you don't really have quite as many services as your largest competitor does. And to be fair, most of your products seem like things that—well, how do I put this politely—human beings might use from time to time rather than very weird corner cases, but there's still a lot. More than any one person can reasonably fit in their head. Do you have a subset of those products? Are you sort of the overarching view that winds up then delegating and fanning out? How does that work?

Richard: Yeah, that's a good question. So, there are outbound product management leads like myself for seven or eight areas, things like compute, and storage, and serverless. I covered GKE and Anthos, kind of the hybrid story. So, each one has, again, small teams, senior leaders, people meant to kind of translate the message out and also pull it back in.

Corey: It seems like on some level, it's very hard to find people who are both broad and deep across anything in the world of Cloud. There's just no way around that.

Richard: It is. That's the mysterious 10 years in Kubernetes experience you somehow see in job postings, but that’s—no—

Corey: Well, a good 10X engineer should be able to get at least that near.

Richard: You’d think. Yeah, so it is tough, and the Google hiring process is daunting in its own way. So, hiring people who are g—this is still a product management role. I'm in the product management family at Google. But people who also have great communication skills, people who have been in industry for a while, maybe even worked in the enterprise. So, it's a different skill set, but it is one that is tricky to find. But we've actually picked up a few good folks so far.

Corey: I went through the Google interview process a couple of times early in my career for SRE roles, and the correct answer that Google gave was, “Ha ha ha. No.” Fair enough. I've gotten a little better since then, but in all the wrong ways. Is the product management interview process similar to what you'd see in the engineering side of, “Oh great, you're here to wind up figuring out how to take this to market. Can you invert a binary tree on a whiteboard?”

Richard: Yeah. I mean, now you have to do it with sock puppets versus the whiteboard, but it's still close. But no, on the product management side, we're definitely looking more for how do you think about product? What do you like about it? Can you think about the market size? 

So, I might ask you something, Corey, like, “Hey, tell me an application on your phone.” You like, “Terrific.” You tell me what that is. Then I might ask you, “That's great. What would you like to see improved in that?” “Cool. How come they didn't do that?” “Okay, now you run the company. How would you get them to do it?” “Okay, now tell me when you have done it before.” And so we daisy-chain questions, so I think for interview people that we're not always used to that, you're used to being asked about your worst boss, or your favorite job or something, but we actually do tr—

Corey: “If you could be any fruit, what kind would it be?”

Richard: Right. Yeah, “How many oranges fit in the state of Utah?” Questions like that. And, I guess you can get those, but for a lot of time, especially for product management, we're trying to think about how do you decide to get to an endpoint? I don't care about your answer as much as how you got there.

Corey: Yeah. And that tends to be a great way of exposing people's strengths and weaknesses both. I think that there's an overemphasis—at least in engineering—of find the thing that people are worst at, and then beat the crap out of them on that. Maybe I'm weird in that I like to find instead, let's find the thing you're best at because honestly, that's the thing I'm going to have you focusing on in most cases, whereas, “Oh, you're really bad at—I don't know, some sort of deep embedded programming. I guess I'm going to put you on a project where you've got to do a lot of that.” It’s, what are you doing? Why is that important?

Richard: So, are you a ‘spend more time on your strengths than bolstering your weaknesses’ person?

Corey: In my case, I'm a little weird, I tend to have a sort of weird skillset where I can go from knowing nothing about something to, maybe, 50th percentile super quickly. I'm not usually very interested in going from even 50 to 51 at that point. It’s, I know enough to be dangerous and to wield it, and that's great. I’m sort of a generalist in that sense, there are a few areas where I take exception to that, but mostly I tend to focus on those sorts of things. 

And then I can find subject matter experts to dive into things and hand it off to folks who are great at it. The nice thing about running my own company is that inherently everyone I hire is better at the thing I'm hiring them for than I am. So, it’s, “Great. Welcome aboard. It's your problem, now. Tell me what I'm doing wrong.” “Oh, I'm sure you're doing fine. Oh, my God, what have you done?” “Yeah, that's sort of what I expected.”

Richard: No, that's a certain confidence that comes with age, I think. As most of us coming out professionally, well you're threatened by someone who's better at your job than you are until you realize that really, you're not promotable until you're replaceable—

Corey: Absolutely.

Richard: —so the whole point should be to find people better than you.

Corey: That's the hard part, I've always found is then trying to replace myself on any of the media stuff that I do because I have a very distinctive personality. I can't very well tag someone else in to write a sarcastic newsletter, for example, and expect them to write it sarcastically and have it come out the same way.

Richard: Yeah, not yet. We're working on that with AI, though. So, we'll try to get the Corey Quinn filter.

Corey: Oh, excellent. Yes, yes, yes. AI is going to solve everything, I'm sure of it. So, at the time that we're recording this episode, you're relatively new to Google. What were you doing before? And how did Google tempt you to come aboard?

Richard: Yeah, three months or so in as we record this, but overall, yeah, relatively new here. I was at VMware prior to this. I was actually acquired through the Pivotal acquisition, so, kind of, at those two companies for about four years. Was at CenturyLink doing cloud stuff, running product management for cloud there for a number of years. Startups, enterprise for five years, which is probably the most important part of my experience because I actually got real empathy for normal humans, not vendors, and then consulting and Microsoft, and things like that for 10 years prior. 

So, when Google came calling and said, “Hey, it's an interesting executive kind of position, and we're doing something brand new. We've never done this before, you'll be the first outbound product management person we've ever hired. What do you think?” It’s like, “That seems somewhat terrifying and new, and who knows if I'll succeed? Yes, that sounds like a great job.” So, a few months later, and no regrets.

Corey: I absolutely have to ask this question. I'm sorry. But I wound up going to an AWS Summit once and identifying myself as being with the Last Week in AWS newsletter, which is what most people at the time knew me for. And so whoever is at the front desk, saw Last Week in AWS, shrugged and said, “Cool,” gave me an employee lanyard like I was the director of, “take this job and shove it, but I'm serving out my notice.” When you say that you are the outbound product management director, do people think that you've given your notice, or has that not happened to you yet?

Richard: [laugh]. That has not happened yet. Most people ask me if I'm just marketing in disguise or a number of other things. But so far, they have not looked at as, “Wow, you're actually outbound and leaving the company.” That'll be a good one. I'm looking forward to that.

Corey: I have to assume that you are marketing, but only in disguise insofar as people don't understand marketing. I'd argue that marketing is very much a two-way street: you have conversations with the people using your product, figuring out what they're doing, how they're doing it, and proceeding from there. It's not just a bullhorn, it's also listening keenly.

Richard: Yeah, I mean, besides the enterprise experience, probably the most begrudgingly valuable experience I got was running product marketing stuff at Pivotal and VMware for those years because I've kind of learned everybody is in marketing, whether you admit it or not. You're either selling value—you might not be as explicitly creating an ad but you're trying to demonstrate value so someone gets in your open source project, your product, your whatever. So, I think understanding yeah, market is not actually a bad word if you do it, right. It's about actually trying to translate complex stuff to simple things to drive behavior. That's something we're arguably all trying to do.

Corey: Something that interests me about Google—specifically, Google Cloud—has been, their engineering historically has been awesome. A lot of customers believe—and I endorse this of you—that in some respects, they’re three to five years ahead of AWS. But the marketing has always seemed off pitch, the messaging has been disjointed and strange, and it just hasn't resonated with folks in the same way. In previous years, Google Cloud Next had a whole bunch of people getting on stage and talking about things, but there wasn't a lot of focus on customer stories. There wasn't a lot of getting up and talking about how GCP is transforming what the company is doing. 

Now, I'm not going to get into specifics because NDAs are real things, but you invited me to an analyst event with GCP, a couple of weeks before this recording, and one of the things that really struck me was that you had not just a customer telling a story, but then opening it up to Q&A. And yeah, there were warts on the customer story, and it was very clear that it was not a perfect idealized situation, city-on-a-hill style. And that had an authenticity that resonated stupendously. It was incredibly relatable, and even for someone who makes fun of clouds for a living, I found that it's very difficult to mock a customer moving forward and saying things like, “Wow, it's helping us advance our business.” It's a very authentic, very relatable story. I had to triple check, this is a Google event? Did I sign up for something else? So, something is clearly changing, just from that perspective, at GCP. Are you able to tell me what's driving that? Am I just imagining this? Has it been like this for a while, and I'm only now seeing it?

Richard: I don't think you're imagining it. I mean, I think Thomas Kurian coming aboard has driven, not just certain business discipline that we're focused on, is making sure that, look, as much as we're an amazing research and engineering organization, we also want to make sure that we're expressing that in the form of purchasable products, and customer value, and things like that. So, I think that's been a great experience so far, but it is this newer push of saying, look, this isn't just about the technology. So, my dumb mental heuristic to me is Google creates the technology, Microsoft creates markets, Amazon creates products. How do you look at that and say, Microsoft always does a great job kind of figuring out how to create markets out of things. 

And Amazon productizes anything anybody else creates, and some of their own stuff, too, which is great. Google sometimes is the source of this, but sometimes you also have to connect this back to the actual value of that tech for the customer, not just putting it out into the ecosystem and saying, “Celebrate everyone,” but back to who got benefit? What was the point of that? And so there was more of a push internally to say, “Hey, it's not just about bursting technology into the universe and celebrating that, but actually making sure people are getting real use from it, there's benefits there.” And that is a bit of a shift versus just build the tech and they will come. No, let’s actually partner with folks that make sure they're getting value and then telling their story.

Corey: It seems like Google takes a very different approach to product management than a lot of other companies. I mean, my running comment has been that your peer at AWS is a post-it note that says, “Hey.” It’s, they're going to build anything, and they clearly have a model down to a science that works. Whereas one of my concerns about Google has been where it feels like GCP came from. And I understand that you're new, but none of this is something that is A) your fault—if I'm right—or it's not something that is even necessarily true. 

But my perception—and I'm thrilled to be challenged on this is that Google saw that they were terrific at running large-scale world-spanning infrastructure and that this was something other companies could benefit from. And it feels like they ran into trouble in the early days was they forgot the part that the reason they're so good at this is because everyone writing Google software at Google is a Google employee, and you can enforce certain coding standards, how workloads work in a variety of different ways without having to cajole people. It's one of those, “Great if you want other people to support this, it's going to be in one of these three languages, it's going to have the following supportability characteristics, or it's all your own problem.” Customers don't work that way. And I'm wondering how much of that is accurate, misperception, an origin myth that people filled in from details? Do you have a take on that?

Richard: How do you contrast that with another cloud? So, I think your origin story from the beginning is, look, a lot of the technology that's come out in the form of Google Cloud is things that originated as part of what it takes to run, you know, nine services with a billion users, so there is a certain scale and breadth from underlying messaging systems to storage, to networking, load balancing, that absolutely have now matter manifested themselves as do-it-yourself, kind of self-service cloud services. But do you see an extra opinionation, or an extra kind of YOLO just, hey, figure out our cloud with Google Cloud versus the other ones?

Corey: Historically, in the early days, I would have said, yes. Now, I would say that again—this is possibly an overly cynical take, but my impression of Kubernetes and its rise to prominence really came out of Google, on some level, trying to make the way that the rest of the world built and deployed software a lot more Google-y. Like, this is sort of the ultimate expression of ‘ship your culture.’

Richard: [laugh]. Yeah, I mean, look, Kubernetes, TensorFlow, a number of things that we can look at—heck, Angular, there's a lot of opinionated and foundational systems that have come out of Google open source, frankly, most of the ones that seem to be getting copied, whether it's a Spanner sort of database model, or BigQuery, and other things. So, there are a lot of, sort of, opinions that come out of Google that either go into customers or go to other vendors who also productize them. I'm not sure if I've seen that change over time, or maybe I've observed what you've observed. But I think the focus now is we take it back to kind of today's world, I think we are thinking much more versus just here's a service… kind of, good luck with this, but we think a lot about usability. Frankly, as someone who was also an MVP for Azure for a decade, as well as uses Amazon, and all these other things, I do think our portal experience is really good. I think that our usability of our CLI is really good.

Corey: I'm not going to argue with that. I did a Twitter thread a while back, hoping to dunk on you because I was in a foul mood of, “I’m going to spin up a Linux VM and show you how crappy this is.” And it was distressingly good. There was remarkably little for me to pick on as I went through that process. And it was almost in spite of myself. It was, “Huh. Yeah, I guess this is actually good.” 

And I was, again, I mostly exaggerate when I say that this is a bad thing. My ultimate goal—everyone accuses me of being a shill from time to time, although who I'm being a shill for constantly changes, so that tells me something interesting. But my goal is I want to see customers have a choice. I want infrastructure to be better now than it was 10 years ago—and it is—but I want it to be better 10 years from now. 

And I don't want it to be, for example, an Amazonian monoculture where you're either running on AWS or you're doing something dumb. I don't want it to be the de facto answer. I want picking a cloud provider to have to be a serious challenge that I put thought and work into. And I guess I'm concerned, on some level, that as I look across the ecosystem of what companies are doing, whenever I see people that are, I guess from my point of view, messing it up, I see that future in jeopardy.

Richard: Interesting.

Corey: That is my bias. I want everything to be better than it is. I don't want to wind up seeing a monoculture. And again, I can make fun of absolutely anything, so there's a lot of good stuff coming out of all of the major cloud providers—

Richard: Absolutely.

Corey: —and rarely, IBM, but there's a definite progression here, where I'm starting to see things work differently than they used to. There's a more serious tone being taken by a lot of the providers. And I'm not sure where it's going.

Richard: Yeah. I mean, look, as you say, we want people making these choices. And there are serious criteria going in. I mean, again, I'm fascinated as to your take, as well as I talk to a number of customers every week, and I'm part of watching their cloud journey and making cloud choices, and we can talk about multi-cloud and those sort of considerations, but I wonder sometimes even is there a ton of crazy thoughtfulness going into it, or is it more organic where, this is we're going to start putting a workload? And then you just kind of back up and go, “Okay. Now we have to stop and actually make thoughtful choices about Cloud.” Do you get an impression, though, that it's much more upfront thoughtfulness from a customer perspective?

Corey: I think there has to be. I’m seeing a few signs from GCP that I'm not asking you to confirm or deny, but it's definitely striking me as the right tone. I know, it's easy to say that, oh, Google, turning things off is only a concern for customer products; real enterprise buyers don't actually have that particular perspective. But I've been in the room when customers are having these discussions, and it has been brought up every single time. But Google going out and saying, “Yeah, that's not a thing anymore and no one believes that,” is patently untrue and transparent. 

What I'm seeing instead, as an example of that, is it was announced that with—I want to say Deutsche Bank—there was a ten-year deal with GCP that had been inked. And it was not touted by GCP as, “See?” Which is fine. I think it's great. It speaks for itself. When a bank is saying that we're signing a ten-year contract, you're not going to be able to turn that off anytime soon, regardless of the rest of the business concerns because you would get so horribly dragged in court over something like that, that it would be unthinkable. So, stories like that give me hope and optimism that Google really is in this for the long haul. You can understand why people might question that.

Richard: Yeah. I think that's fair, but at the same time, as you mentioned, I think you’re seeing positive signs. Look, I mean, part of the things that outbound product management teams need to do is both craft and share multi-year roadmaps, which in the Cloud, that's not always something that's pushed forward. It's almost quarter-to-quarter agile planning based on feedback. But if you're going to talk to an enterprise buyer, I can't say, “Hey, this is what we're thinking about doing next month after that—” shoulder shrug. Like that doesn't work in large enterprises.

Corey: They want roadmaps. They want plans on these things. One thing that I will give AWS credit for, even to its own detriment at times, I would argue on some level, they don't deprecate enough, which means that when they launch something terrible, with bad pricing and a dumb name, we're stuck with it. It's not going to go away anytime soon. Which is I know, it sounds like a weird thing to complain about, but it's strange. 

I will say credit where due, GCPs deprecations have been relatively minimal and understandable as far as service goes, there was a whole Steve Yegge post about question around the API's and the rest, and how that is communicated. I haven't used it deeply enough to have an informed opinion on that yet.

Richard: Yeah. And to be honest with you, that feedback doesn't go unnoticed. I send out an internal newsletter every Friday, just kind of, “This week in the product” and—

Corey: Oh, I have some thoughts about a weekly newsletter.

Richard: I know you do. So, I referenced that post; we talked about it. So, I mean, we are a listening organization. I think maybe potentially this sort of idea of ivory tower Google stuff is really not the case anymore. It's a definitely more—it’s a smart bunch. 

It's one of the—probably the preeminent research-oriented technology companies on the planet. But at the same time, a lot of people recognize what they don't know and that their impressions of what is perfect isn't what the customer thinks. And so I just got done—before we jumped on this podcast—another product review, and how many times in that call it was, we got to meet the customer, this is what they're—we think they need. We've talked to these ten customers before we crafted what we think we want to do. I think that's a new Google, I think that's pretty good.

Corey: This episode is sponsored in part by our friends at Linode. You might be familiar with Linode; I mean, they've been around for almost 20 years. They offer Cloud in a way that makes sense rather than a way that is actively ridiculous by trying to throw everything at a wall and see what sticks. Their pricing winds up being a lot more transparent—not to mention lower—their performance kicks the crap out of most other things in this space, and—my personal favorite—whenever you call them for support, you'll get a human who's empowered to fix whatever it is that's giving you trouble. Visit linode.com/screaminginthecloud to learn more, and get $100 in credit to kick the tires. That's linode.com/screaminginthecloud.

Corey: There's a strong value story here around what this is becoming. It's clear that this is undergoing some maturity. The olden days of software development at Google—and most other places—was, to be direct, typical of many Bay Area companies where if you're not running something that is plugged into the server itself, and you're on the latest model MacBook Pro on the absolute bleeding edge version of Chrome, then you should maybe upgrade your computer. It's much more enterprise-oriented in some respects, and that is just a fascinating shift to watch. I can only imagine the cultural debate happening internally.

Richard: Yeah some of that’s, obviously, positively received. People like seeing the stories you talked about, though, where you saw, during our analyst event where it's a German company that creates air compressors. That is not Snapchat; that's not these Bay Area companies that tell these cool stories all the time that are awesome. It's not just LinkedIn on stage, and Pinterest, and whomever else, and Etsy. This is talking about, okay, let's talk about companies that are doing some things that kind of run the world quietly, behind the scenes. And so I think our people like hearing those.

Corey: Well, I wouldn't call air compressors quiet, but I hear what you're saying there.

Richard: [laugh]. Very true.

Corey: It’s, yeah, these are changes to their IT posture take years, at a minimum, to wind up percolating out, so this is not a short term bet on their part.

Richard: No, no. And it's not short term bets, and there's retraining involved, there's big bets they're making, and to your point, they're locking in for a long period of time because that's what's going to make sense for them. They're not going to switch clouds every week; they're not going to try new services every week. There's a long tail, I'm sure, in all the clouds of which services people actually pay for and which ones they talk about. I think, for the most part, the ones most people still pay for are—what—VMs and storage?

Corey: Oh my god, yes. The majority of AWS global spend is EC2 regardless of all the stories they talk about. It gets five minutes in their keynotes.

Richard: Absolutely.

Corey: Running VMs effectively and well is not exciting, but it's what runs the world.

Richard: No, it's the bread and butter. And so if you can show you can solve that—I think increasingly, we're also seeing more focus on the migration story. It's not just net-new workloads because that's a small fraction of the budget. It’s, how am I getting new value out of the existing stuff? How am I migrating that lower in cost, maybe, or at least getting new agility stuff? The usual cloud value prop. 

Then there's definitely that push for, again, I don't just want an arm's length vendor, I am kind of looking for a partner, which is the other move we've been making as well, which is probably new for Google, helping people actually get better at software. So, I like that we're not just a post-deploy platform. We're not just sitting here waiting for the workloads. Can we actually go help people get the right things there and create the right things?

Corey: So, one area I want to, I guess, have a debate with you on is this idea of multi-cloud.

Richard: Yes.

Corey: And I have made loud opinionated perspectives on this, and you have a spouse at times, the exact opposite perspective, I think. Let's figure that out. Where do you stand on it?

Richard: Yes, good. So, first, let's step back. So, what are we defining as multi-cloud? I would argue this is not franken-apps made up of a database in one cloud, a network tier in another, and in VMs in another. I don't think anyone really proposes seriously, that's a good idea. So, let's ignore the franken-app. 

Yeah, I think we talk about, okay, is multi-cloud putting the same app in different clouds, for DR purposes, for even load balancing, whatever? Kind of. I think, for the most part, most people think of multi-cloud as an organization is using different clouds, and they're putting different apps in different clouds. So, my approach to this, and reason that I've kind of pushed on this as well is, I think that's 100 percent reality if you're in a decent-sized company. And let's even ignore the public clouds only, although every survey I've seen, every customer I talked to, is not saying literally all our workloads are going to go to the one cloud. I've just—I don't see it. But let’s, even, ignore that. 

I think we all know you're going to use more tech than one IaaS cloud. Whether I'm using Twilio, or Salesforce, or Workday, or [00:26:24 Versel], or SnapLogic. Like, there's other clouds, if you will, that will make up my portfolio. So to me, multi-cloud is, I'm not going to single-source, my compute, my data, all those sorts of things. Multi-cloud is about probably using different sort of services for different reasons, but still coupling things close together for performance and manageability. I don't think one ops team, again, is striping things across every cloud, ideally. It's about fit for purpose, and I don't see that stopping. So, instead of arguing that it's a bad idea, let's try to do it the right way.

Corey: One of the biggest concerns and considerations that I see around multi-cloud, it always comes down to definition of terms, where I agree that multi-cloud is a reality and not going anywhere is the idea of using G-Suite for my email system—which now counts as part of GCP, so you can't even argue that one—maybe AWS, my infrastructure, GitHub for my Git stuff. And having different workloads in different spaces. We can take that a step further and call out to specific GCP calls for a machine learning or artificial intelligence API that you've implemented super well, where I need to get data returned from that. And that's fine. I'm not arguing against anything like that. 

Where I tend to say this is dumb, is where people are building a greenfield service today that they want to be able to press a button and deploy it, to GCP, to AWS, to DigitalOcean, to Oracle Cloud, to Azure, to my basement Raspberry Pi cluster, et cetera, et cetera. And it feels like that is the wrong direction to go in no matter how you slice it. Am I wrong?

Richard: I think you are right on the whole. Though I think there's something philosophically that separates, sometimes, people think about multi-cloud. Are you thinking about the Cloud is going to kind of adapt to you? Are you going to adapt to the Cloud? And based on how you answer that question, if you say, “I’m going to adapt to the Cloud,” then I'm going to use Dynamo, I'm going to use Spanner, I'm going to use whatever I can, I'm going to use Lambda, the messaging services, the networking tools, IAM, all those fun things. 

And that is going to be how I build my app. If it's, “The Cloud is going to adapt to me,” which is I think, frankly, most of the enterprise play, it's, “No, I'm actually going to bring my Redis installation. I'm going to bring Confluent because I like Kafka more. I'm using New Relic for monitoring. I don't want to use what you're using.” And all of my logic is, frankly, in my code. 

It's not going to be in your Cloud, it's in my application code. So, I can build—and look, at Pivotal, we had great demos on stage of Dick's Sporting Goods doing an actual live cutover between clouds because they were running Cloud Foundry. Again, I don't think that's the common use case, but I think if you're thinking of, “The Cloud is going to work for us,” versus, “I'm kind of going to work for the Cloud,” your answers are different. And if you think that I'm going to leverage the Cloud versus be wrapped up by it, I'm probably bringing my code, plus some of my other software, not just first-party cloud-native services. And if I do that, then that sort of portability story is possible. 

Doesn't mean it's a good idea, in every case. I don't think you should be click button, moving workloads around. That's pretend, sort of, vendor fighting against each other, let me get a cheaper bill, sort of silliness. But I think there is an idea that how much of my app is actually comprised of totally cloud-native services, I think there's a whole industry based on, whether it's HashiCorp, or Elastic, or Cockroach, or F5, that are depending on the fact that you will bring best-of-breed things to your cloud of choice, and I think that's okay. So, I think it's going to depend on how deep you go into a cloud, versus how much you see the Cloud as simply a tool in your tool belt.

Corey: One of the previous episodes of this show was a conversation with HashiCorp’s Mitchell Hashimoto, where his argument was that Terraform was not built for multi-cloud workload portability, it was built for workflow portability, which makes a big difference. And I like that take quite a bit. Where I think it gets lost and becomes sort of strange is that, on some level, people start twisting this in a bunch of different ways. And even at the baseline level, where I only use the common primitives that exist between all providers, that breaks down way earlier than people think.

Richard: Very true.

Corey: I had a customer once spend four months of not cheap engineering time, trying to get Terraform to [00:30:27 pier] up a GCP and AWS pair of VPCs. Well, with all those acronyms and C's in there, it's going to be, okay, how do I say this without making that confusing, but that's neither here nor there. And at the end of it, there was still no great answer because the ways that these things behave is radically different; at an implementation level, things start to break down. What I've seen in almost every case for companies that have tried that is that there's always a primary cloud and a secondary cloud use for something else, maybe for backups or for a particular workload, and invariably—even if they don't intend for it to be that way—the company that becomes their primary cloud provider is the one where their data lives because data gravity tends to be the determining factor on these things. Does that align with your understanding?

Richard: Your primary secondary point seems true. That's what I've seen as well. I think the data gravity point is also clearly fair. Shout out to Dave McCrory coining that years ago. I think that—

Corey: Is that where it came from?

Richard: Yeah, yeah. So, but if you think about the consideration for that, so when I think about even Google's interesting place in the industry is I think—and please tell me, I'm making stuff up—Google Cloud’s the only cloud provider where the enterprise buyer, the person who might care about it, might actually care about the business relationship with Google because their business depends on ads, map, Play Store, apps, whatever else. And so they might say, “Look, we're generating tons of ad data, I want to use BigQuery.” There's a gravity there versus who looks at even any of the other clouds for the most part and says, yes, my business depends on my relationship with that cloud provider. I don't know, is that really the case? So, I think there's a gravity that's going to also happen—

Corey: Only the smart ones, if I'm being perfectly honest with you. It’s, at some point, when a cloud provider is running all of your production infrastructure, they're not your vendor anymore, they're your partner. So, watching companies periodically try to beat the crap out of the cloud provider in, frankly, unfortunate ways during contract negotiation. It's, you're not buying a car here, you have to have a conversation and relationship with these people after the negotiation’s done, and insulting people's intelligence is not really the best way to get there.

Richard: No, you're right.

Corey: That's a frustrating point.

Richard: No, that's a bonkers point. I just think that sort of the business of Google, and therefore, Google Cloud has a different relationship with a lot of large businesses and small businesses because of the nature of what Google provides. And Amazon may be the case as well, you're selling things through them, or whatever have you. But there's an interesting data gravity of things generated by Google proper that you can leverage with Google Cloud. 

And I say that because look, my data is also going to sit in Salesforce; my data is going to sit in other systems, as you mentioned, so maybe that gravity will continue to pull into a Redshift data warehouse or data lake in S3; totally possible. I'm just seeing, especially as you do more edge stuff, as you do some things at the retail edge, telco stuff, that that data is going to sit in a lot of places, and the compute is going to follow that. So, as you look at platforms, compute services—that's where Anthos is an interesting play—when you move the compute to the data versus necessarily thinking you can keep consolidating all the data to a single gravity point, I’m not sure if that's what the future is going to play out.

Corey: I'm curious to know how you see it with Anthos and, I guess, it’s current strategy. When Anthos was first announced, it was extremely unclear to me a number of different aspects of it. Who is the product for? What actually is it? The price point, I think, started off at a minimum $120,000 a year, so for my ridiculous serverless nonsense, it was clear the target market was not me. And that's okay, I'm not suggesting it should be. But it does become interesting.

Richard: It does. So, it is not, also, a floor wax, dessert topping, kind of, anything you want it to be. There's a specific thing—

Corey: And the breakfast cereal, honestly, needs some improvement.

Richard: Yeah. No, I know, too much sugar. But if you look at what it is, in reality; look, it's an application platform. It’s Kubernetes, it's Knative, it's Istio, it's a number of components, but it's also kind of a service platform which says, “How do I put new and existing services onto a single platform, that yes, can run on different sorts of infrastructure as a single control plane?” To me, this starts to separate something you and I were kind of spitballing around, but sort of the first generation multi-cloud stuff, and second generation. 

And so, first-generation multi-cloud; what was this? So, this was VMs, this was RightScale, this was vRealize, this was, if you remember that period, where all these crazy acquisitions were happening, like Clicker, ElasticBox, all these companies, couple hundred million dollar acquisitions because everyone thought that the secret was going to be, “Hey, we're going to help companies build VMs on different clouds.” I don't know if that really landed. 

The second-generation stuff I'm seeing is about apps. It's not about the VM. So, you have more—it's more about control planes of logical compute pools, not just, I have compute sitting in AWS and in my vSphere environment in GCP. It's, I've kind of built a general mesh, which I deployed to. It has an operational sort of setup cost. 

And then once I have it, yes, I have a consistent infrastructure layer, and connectivity, and security story—which I think is interesting—that hosts both new and existing serverless-y stuff, thanks to Knative and Cloud Run, or maybe a stateful database, or a Kafka instance. So, I think there's something about these more open control plane application platforms that you're seeing that say, don't lowest common denominator things. I get that that's not a fun part of multi-cloud. Instead, can I normalize at least the lowest level of, hey, here's my container runtime; here's some of the network connectivity; now go use an IoT framework. Go ahead and use this great database. Go ahead and use this messaging layer. 

Absolutely, you're not locked out of that, if anything, you're simplifying the original stuff so you can actually use the other stuff. So, I think there's these second-generation platforms are more about orchestrating things for the app versus just standalone VMs. And Anthos is trying to do some interesting stuff here. We'll see where it all goes, but I like this push forward to say, again, how do I do things more open and recognize that compute probably won't consolidate, I am going to be doing more edge, I am going to be using different clouds, I don't want on-premises to suck because even someone who says I'm all in on X cloud is probably on a ten-year journey and their choice is either public cloud is awesome, and on-prem is terrible until that happens, or you start to at least create some sort of behavior and cloud-native patterns and tech to get you some sort of speed on both.

Corey: I think that that's probably a fair way to frame that. I think we get lost in nuance. Where I tend to take objection to this is when companies are just starting out on their cloud journey, and the advice that they are given from a number of places, “Oh, you've got to build with multi-cloud in mind.” Which in turn, means that it's forcing them away from choosing higher-level managed service offerings that are differentiated, or they're not talking about the things that they otherwise would be focusing on the things that add value to their business. Instead, they're trying to figure out how to get a relatively toy web app running inside of Kubernetes, which is a pretty heavy lift in many cases. So, it comes down to when people don't know what to do, and they're asking for advice. I don't love the pattern of, “Well, here's some crap advice we've built out for you.” I like to see an outcome of better storytelling. And the multi-cloud stuff in my perspective tends to detract from that.

Richard: You're not wrong. I think it's a later optimization. And frankly, look, a lot of this is polluted by, obviously vendor intent, and this and that, and look, heck, I'm part of it; I work for a vendor. But I've also—why I do like to believe that being the enterprise buyer, being the service provider, being the consultant, being the developer, at least tries to help me think about this the right way that no, you shouldn't be doing multi-cloud on day one, that's probably a bad idea. You should be using a particular cloud getting value from it, and then optimizing over time, especially as more people use it, and figure out what you want to do. So, there's absolutely a progression.

Corey: Yeah. I am talking best practices, too, to be very clear here. People are like, “Ah, but what if I want to potentially sell to retail, then, and I don't want to have to wind up moving my stuff later? So, I should build with cloud agnosticism in mind.” “No. I suggest you go all in. I would also suggest whatever cloud you pick is not AWS, upon which to go all in. GCP: perfectly valid option. Have you talked to those folks?” 

And I don't have a preference for what provider to pick. And I assume by default, whenever I talk to a company has done something in a direction toward a provider or toward a multi-cloud strategy, that they've done the analysis and that my best practices thoughts are no longer directly germane because they have context that I don't as general guidance. So, please don't ever interpret what I'm saying in the general sense to apply to specifically calling one company out for doing terrible things.

Richard: Sure. No, that's fair. I mean, the interesting question is that we've been in all-in, can you still put an eye towards what's the smart thing to do? My old colleague, Josh [00:39:03 McEntee]—smart fellow—used to say, “Look, when you're innovat—”

Corey: Oh yes.

Richard: “—when you're innovating and learning, that's when you definitely should be using whatever proprietary crazy thing you can use in a given cloud.” Look, you should be—you know, if I'm in Google Cloud, I should be using Functions and I should be using Spanner, and BigQuery, and Bigtable, and whatever, right? Because you're just trying to prove something. Who cares if you're trying to genericize this to a relational database, or whatever else. Just frickin’ prove your point. 

Now, over the lifecycle of that app, you might over time go, “Well, maybe I didn't really need Mongo in this case. I'm going to just go back to MySQL.” Or maybe it shouldn't be a bunch of Lambda functions. Let's actually just make this into a smaller containerized app. The apps have a journey. And so when you're starting and you're experimenting, you're probably going to be more proprietary as it goes on its lifespan; you're purposely looking for more commodity things. I think that's fine, too. I think that's an interesting way to look at these things, that all of these choices probably go on a spectrum and a spectrum over time. I think as most people stop thinking about software as static, we'll be better off.

Corey: Richard, thanks for taking the time to speak with me today. If people want to learn more about what you're up to, and/or buy your company's products, services, or breakfast cereal, where can they find you?

Richard: Yeah, you can always find me on Twitter—along with Corey—at @rseroter and seroter.com is where I try to blog a couple times a month on my idiot explorations of technology that some people like to follow along with.

Corey: Excellent. We will, of course, code links to that in the [00:40:21 show notes]. Thank you so much for taking the time to speak with me today. I really appreciate it. It's nice to get folks from GCP to talk to me from time to time about something other than what they perceive—maybe rightly, if accidentally—as personal attacks. So, thank you for this.

Richard: My pleasure. Appreciate you having me.

Corey: Richard Seroter, outbound product management at Google Cloud. 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 Apple Podcasts, whereas if you hated this podcast, please leave a five-star review on Apple Podcasts and tell me why this podcast should be deprecated.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.