Screaming in the Cloud - Cloud Security and Cost with Anton Chuvakin

Episode Date: August 2, 2022

About AntonDr. Anton Chuvakin is now involved with security solution strategy at Google Cloud, where he arrived via Chronicle Security (an Alphabet company) acquisition in July 2019.Anton was, until recently, a Research Vice President and Distinguished Analyst at Gartner for Technical Professionals (GTP) Security and Risk Management Strategies team. (see chuvakin.org for more)Links Referenced:Google Cloud: https://cloud.google.com/Cloud Security Podcast: https://cloud.withgoogle.com/cloudsecurity/podcast/Twitter: https://twitter.com/anton_chuvakinMedium blog: https://medium.com/@anton.chuvakin

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with Postgresquil for 15 years.

And now, EnterpriseDB has you covered wherever you deploy PostgreSQL, on-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud. To learn more, try Big Animal for free.

Go to biganimal.com slash snark and tell them Corey sent you. Let's face it. On-call firefighting at 2 a.m. is stressful. So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that Incident.io makes incidents less stressful and a lot more valuable. Incident.io is a Slack-native incident management platform. It allows you to automate incident processes, focus on fixing the issues, and learn from incident insights to improve site reliability and fix your vulnerabilities. Try Incident.io to recover faster and sleep more.

Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Anton Shuvakin, who is a security strategy something at Google Cloud. And I absolutely love the title of given how, honestly, how anti-corporate it is in so many different ways. Anton, first, thank you for joining me. Sure, thanks for inviting me. So, you wound up working somewhere else, according to LinkedIn, for two months, which in LinkedIn time is about 20 minutes because their date math is always weird. And then you wound up going, and according to LinkedIn, of course, leaving and going to Google. Now, that was an acquisition, if I'm not mistaken, correct?

That's correct. Yes. And it kind of explains the timing and a little bit of a title story, because my original title was Head of Security Solutions Strategy. And it was for a startup called Chronicle. And within actually three weeks, if I recall correctly, I was acquired into Google. So title really made little sense at Google. So I kind of go with like random titles that include the word security and occasionally strategy if I feel generous. It's pretty clear the fastest way to get hired at Google,

given their famous interview process, is to just get acquired. Like, I'm going to start a company and raise it to like a little bit of prominence and then do an acqui-hire, because that'll be faster than going through the loop. And ideally, there will be less algorithm solving on whiteboards.

But I have to ask, did you have to solve algorithms on whiteboards for your role? Actually, no, but it did come close to that for some other people who were seen as non-technical and had to join technical roles. I think they were forced to solve coding questions and stuff, but I was somehow grandfathered into a technical role. I don't know exactly how it happened. Yeah, how you wound up in a technical role.

Let's be clear. You are Dr. Anton Shuvakin. You have written multiple books. You were a research VP at Gartner for many years. And once upon a time, that was sort of a punchline in the circles I hung out with. And then I figured out what Gart lot of respect for the folks who are actually analysts and the laborious amount of work that they do that remarkably few people understand. That's correct. And I don't want to boost my ego too much. It's kind of big enough already, obviously, but I actually made it all the way to distinguished analyst, which is the next rank after VP. Ah, my apologies. I did not realize it. This challenge with internal structure is like, oh, I went from senior to staff or staff to senior because I'm external. I don't know the

direction these things go in. It almost feels like a half step away from, oh, I went from SDE3 to SDE4. It's like, what do those things mean? Nobody knows. Great. And what's the top? Is it 17 or is it 113? Exactly. It's like, oh, okay. So a research VP or various kinds of VPs. The real question is how many people have to die before you're the president? And it turns out that that's not how companies think. Who knew? That's correct. And I think Gartner was a lot of hard work. And it's the type of work that a lot of people actually don't understand. Some people understand it wrong, and some people understand it wrong kind of for corrupt reasons. So for example, a lot of Gartner machinery involves soaking insight from the outside world, organizing it, packaging it, writing it, and then giving it as advice to other people. So there's nothing offensive about that

because there is a lot of insight in the outside world and somebody needs to be a sponge slash filter slash enrichment facility for that insight. And that, to me, is a good analyst firm like Gartner. Yeah, it's a very interesting world. But you historically have been doing a lot of, well, I don't even know how to properly describe it because Gartner's clientele historically has not been startups because, let's face it, Gartner is relatively expensive. And let's be clear, you're at Google Cloud now, which is a different kind of expensive, but in a way that works for startups. So good for you, gold star. But what was interesting there is that the majority

of the Gartner clientele that I've spoken to tend to be big E enterprise, which runs legacy businesses, which is a condescending engineering term for it makes money. And they had the temerity to start their company before 15 years ago. So they built data centers and did things in a data center environment. And now they're moving in a cloudy direction. Your emphasis has always been on security. So my question for you to start with all this is, where do you see security vendors fitting in? Because when I walk the RSI Expo Hall and find myself growing increasingly depressed, it seems like an awful lot of what vendors are selling looks

very little removed from, we took a box, now we shoved it in a virtual machine, and here you go, it's in your cloud environment, please pay us money, the end. And it feels, if I'm looking at this from a pure cloud native, how I would build things in the cloud from scratch perspective, to be the wrong design. Where do you stand on it? So this has been one of the agonizing questions. So I'm going to kind of ignore some of the context. Of course, I'll come back to it later, I love ignoring context. My favorite thing is it makes me a decent engineer some days. So the frame was this. One of the more agonizing questions for me as an analyst was a client calls me and says, we want to do X.

Deep in my heart, I know that X is absolutely wrong. However, given their circumstances and how they got to decide to do X, X is perhaps the only thing they can logically do. So do you tell them, don't do X, X is bad? Or you tell them, here is how you do X in a manner that aligns with your goals, that's possible, that's whatever. So cloud comes up a lot in this case. Somebody comes and says, I want to put my on-premise security information management tool or SIM in the cloud.

And I say, deep in my heart, I say, no, get cloud native tool. But I tell them, okay, actually, here's how you do it in a less painful manner. So this is always hard. Do you tell them they're on their own path? Or you help them tread their own path with least pain? So as an analyst, I agonized over that. This was almost like a moral decision. What do I tell them?

It makes sense. It's a microcosm of the architect's dilemma on some level. Because you ask a typical Google-style interview whiteboard question. One of my favorites in years past was build a URL shortener. Great. And you can scale it out and turn it into different things and design things on the whiteboard. And that's great.

Most mid-level people can wind up building a passable design for most things in a cloud sense when you're starting from scratch. That's not hard. The problem is, is that the real world is messy. It doesn't fit on a whiteboard. And when you're talking about taking a thing that exists in a certain state, for whatever reason, that's the state that it's in, and migrating it to a new environment or a new way of operating, there are so many assumptions that have to break. And in most cases, you don't get the luxury of just taking the thing down for 18 months so you can rework environment. And that's

okay. We don't all need to be the absolute vanguard of how everything should be built and pushing the bleeding edge. You're an insurance company, for God's sake. Maybe that's not where you want to spend your innovation energies. Yeah, and that's why I tend to lean towards helping them get out of this situation or maybe build a five-step roadmap of how to become a little bit more cloud-native rather than tell them, you're wrong. You should just rewrite the app in a cloud-native way. That advice almost never actually works in the real world. So I see it a lot in security.

People move their security stacks to the cloud. And if I see this, I deepen my heart and say, holy cow, what do you mean you want to IDS every packet between cloud instances? You want to capture every packet between cloud instances? Why? It's all encrypted anyway. But I don't say that. I say, okay, I see how this is a first step for you. Let's describe the next seven steps. The problem I keep smacking into is that very often folks who are pushing a lot of these solutions are yes they're they're meeting customers where they are and that makes an awful lot of sense i'm not saying that there's anything inherently wrong about that the challenge is it also feels on the high end when those customers start to evolve and transform that those vendors act as a drag because

if you wind up going in a full-on cloud native approach in the fullness of time, there's an entire swath of security vendors that do not have anything left to sell you. Yes, that is correct. And I think that I had a fight with an EDR vendor, endpoint detection response vendor, one day when they said, oh, we're going to be XDR and we'll do cloud. And I told them, you do realize that in a true cloud native environment, there's no E. There is no endpoint the way you understand it. There is no OS. There is no server. And 99% of your IP is in working on the clients and servers. How are you going to secure cloud again? And I guess I'm going to ramble an answer from them. But the point is that you're right. I do see a lot of vendors that meet clients where they are during their first step in the cloud,

and then they may become a drag, or the customer has to switch to a cloud-native vendor or to both sometimes and pay into two mouths, or shove money into two pockets. Well, first, I just want to interject for a second here, because when I was walking the RSI Expo floor, there were something like 15 different vendors that were trying to sell me XDR. Not a single one of them bothered to expand the acronym. Just 15? You missed half of them. Well, yeah. As far as I know, it's an XDR cable. It's an audio thing, right? I already have a bunch of those for a microphone. What's the deal here? Like, I believe that's XLR. It's like, I believe you should expand your acronyms. What is XDR?

So this is where I'm going to be very self-serving and point to a blog that I've written that says, we don't know what's XDR. But rather than a spiritual meaning, what does the acronym stand for? I don't actually know the answer to that. Extended detection and response. Extended detection and response. But the word extended is extended by everybody in different directions. There are multiple camps of opinion. Gartner argues with Forrester, if they ever had a pillow fight, it would look really ugly because they just don't agree on what XDR is. Many vendors don't agree with many other vendors. So at this point, if you corner me and say, Anton, commit to a definition of XDR, I would not. I would

just say TBD, wait two years. We don't have a consensus definition of XDR at this point. And RSA, no understanding, 30 booths with XDRs on their big signs. Still, sorry, I don't have it. The problem that I keep running into again and again and again has been pretty consistently that there are vendors willing to help customers in a very certain position. And for those customers, those vendors are spot on the right thing to do. But then they try to expand. And instead of realizing that the market has moved on and their market that they're serving is inherently limited and long term is going to be in decline. They instead start trying to fight the tide and saying, oh, no, no, no, no. Those new cloud things can't trust them.

And they start out with the FUD, the fear, uncertainty and and doubt marketing model, where you can't trust those newfangled cloud things. You should have everything on-prem, ignoring entirely the fact that in their existing data centers, half the time the security team forgets to lock the door. Yeah, yeah. It just feels like there is so much conflict of interest about in the space. And that's the reason I started my Thursday, last week in AWS newsletter that does security roundups, just because everything else I found

was largely either community-driven, where it understood that it was an InfoSec community thing, and InfoSec community is generally toxic, or it was vendor-captured. And I wanted a roundup of things that I had to care about running an infrastructure,

but security's not in my job title, even if the word something is or is not there. I have a job to do that isn't security full time. What do I need to know? And that felt like an underserved market. And I feel like there's an equivalent of that in the world of the emerging cloud security space. Yes, I think so. But it has a high chance of being also kind of captured by legacy vendors.

So when I was at Gartner, there was a lot of acronyms being made that started with a C, cloud. There was CSPM, there was CWBP. And after I left, they coined CNAP with double P at the end, Cloud Native Application Protection Platform. And, you know, in my time at Gartner, five-letter acronyms were definitely not very popular. Like, you shouldn't have done a five-letter acronym if you can help yourself. So my point is that a lot

of these vendors are more from legacy vendors. They're not born in the cloud. They're born in the 1990s. Some are born in the cloud, but it's a mix. So, the same acronym may apply to a vendor that's 2019 or, wait for it, 1989. That is... well, I'd say on the one hand it's terrifying, but on the other, it's not that far removed from the founding of Google. True, true. Well, 89, it's another 10 years. I think that if you're from the 90s, maybe you're okay. But if you're from the 80s, you really need to have superpowers of adaptation. Again, it's possible. Funny aside, at Gartner, I met somebody who was

an analyst for 32 years. So he was, I think, at Gartner for 32 years. And how do you keep your knowledge current if you are always in an ivory tower? The point is that this person did do that because he had a unique ability to absorb knowledge from the outside world. You can adapt. It's just hard. It always is.

I'm going to pivot a bit and put you in a little bit of the hot seat here. Not intentionally so, but it is something that I've been really kicking around for a while. And I'm going to basically focus on Google because that's where you work. I want you to go and mouth off about other cloud companies. That's going to go super well and no one will have a problem with that. No, it's, we'll pick on

Google for a minute because Google Cloud offers a whole bunch of services. I think it's directionally the right number of services because there are areas that you folks do not view as a core competency and you actually, imagine that, partner with third parties to wind up delivering something great rather than building the shitty knockoff version that no one actually wants. I might be subtweeting someone here with this on the out loud. The thing that resonates with me, though, is that you do charge for a variety of security services. My perspective, by and large, is that the cloud vendors should not be viewing security as a profit center, but rather as something that comes baked into the platform, that winds up being amortized into the cost of everything else, just because otherwise you wind up with such a perverse set of incentives.

Does that sound ridiculous? Or is that something that aligns with your way of thinking? I'm willing to take criticism that I'm wrong on this too. It's not that. I almost start to see some kind of a magic quadrant in my mind that kind of categorizes... Careful, that's trademarked. Okay. So some kind of... It's a mystical quadrilateral. Some kind of visual depiction, perhaps including four parts, not quadrants, my view, that is focused on things that should be paid and aren't, things that should be paid and are paid, and whatever else. So the point is that if you're charging for encryption, like basic encryption,

you're probably making a mistake. And we don't, and other people, I think, don't as well. If you're charging for login, then it's probably also wrong, because charging for log retention, keeping logs, perhaps is okay, because ultimately you're spending resources on it. Charging for logging, to me, is kind of in the vile territory. But how about charging for a tool that helps you secure your on-premise environment? Right. If it's something you're taking to another provider, I think that that's absolutely fair. But the idea, and again, I'm okay with the reality of, okay, here's our object storage

cost for things. And by the way, when you wind up logging things, yeah, we'll charge you directionally what it costs for the store that an object store. That's great. But I don't have the Google Cloud priceless shoved into my head, but I know over in AWS land that CloudWatch logs charge 50 cents per gigabyte for ingress. And this fan says, well, that's a lot less expensive than most other logging vendors out there. It's, yeah, but it's still horrifying. And at scale,

it makes me want to do some terrifying things like I used to, which is build out a cluster of R-Syslog boxes and wind up having everything logged to those because I don't have an unbounded growth problem. This gets worse with audit logs because there's no alternative available for this. And when companies start charging for that, either on a data plane or a management plane level, that starts to get really, really murky because you can get visibility into what happened

and reconstruct things after the fact, but only if you pay. And that bugs me. That would bug me as well. And I think these are things that I would very clearly push into the box of, this is security that you should not charge for. But authentication is free, but like deeper analysis of authentication patterns, perhaps costs money. This to me is in the fair game territory because you may have logs,

you may have reports, but what if you want some kind of fancy ML that analyzes the logs and gives you some insights? I don't think that's offensive to charge for that. I come bearing ill tidings. Developers are responsible for more than ever these days.

Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud.

And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDs, repos, and pipelines. Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and more, as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk.

Learn more at Snyk.co slash scream. That's S-N-Y-K dot C-O slash scream. I think it comes down to what you're doing with the baseline primitives, the things that no one else is going to be in a position to do. Because honestly, if I can get logging and audit data out of your control plane, you have a different kind of security problem. And that is a giant screaming fire in the building, as it should be. The other side of it, though, is that if we take a look at how much all of this stuff can cost,

and if you start charging for things that are competitive to other log analytics tools, great, because at that point, we're talking about options. I mean, I'd like to see, in an ideal world, that you don't charge massive amounts of money for egress, but ingress is free. I'd like to see that normalized a bit, but yeah, okay, great. Here's the data. Now I can run whatever analytics tools I want on it. Then you're effectively competing on a level playing field as opposed to like, okay, this

other analytics tool is better, but it'll cost me over 10 times as much to migrate to it. So is it 10 times better? Probably not. Few things are. So I guess I'm sticking with the stuff that you're offering. It feels like the cloud provider security tools never quite hit the same sweet spot that third-party vendors tend to, as far as usability, being able to display things in a way that aligns with various stakeholders at those companies. But it still feels like a cash grab. And I have to imagine, without having insight into internal costing structures, that the security services themselves are not a significant revenue driver for any of the cloud companies. And the rare times

where they are is almost certainly some horrifying misconfiguration that should be fixed. That's fair. But so to me, it still fits into the bucket of some things you shouldn't charge for, and most people don't. There is a bucket of things that you should not charge for, but some people do. And there's a bucket of things where it's absolutely fair to charge for. I don't know the amount. I'm not a pricing person. But I also seen things that are very clearly have cost to a provider, have value to a client, have margin. So it's very clear it's a product. It's not just a feature of the cloud to be more secure. But you're right. If somebody positions this, I got cloud. Hey, give me secure cloud. It costs double. I'd be really offended. Because like, what is your first cloud is like broken and insecure.

Yeah. Replace insecure with broken. Why are you saying broken to me? Right. You're trying to spin up a service in Google Cloud. It's like, great, do you want the secure version or the shitty one? I guess it's one of those costs more. It's, yeah, in the fullness of time, of course the shitty one costs more because you find out about security breaches

on the front page of the New York Times and no one's happy, except maybe the Times. But the problem that you hit is that I don't know how to fix that. I really, I think there's an opportunity there for some provider, any provider, please, to be a trendsetter. And yeah, we don't know how to fix that. I think there's an opportunity there for some provider, any provider, please, to be a trendsetter. And yeah, we don't charge for security services on our own stuff just because we believe that should be something that is baked in. That becomes the narrative of the secure cloud. What about tiers? What about some kind of a good, better, best,

or bronze, gold, platinum, where you have reasonable security, but if you want superior security, you pay money? How do you feel? What's your gut feel on this approach? Like, I can't think of an example. Log analysis. You're going to get some analytics and you're going to get fancy ML. Fancy ML costs money. Yay, nay? You're bringing up an actually really interesting point because I think I'm conflating too many personas at once. Right now, just pulling up last month's bill on Google Cloud, it fits in the free tier, but my cloud run bill was 13 cents for the month because that's what runs my snark.cloud URL shortener. And it's great. And I wound up with, I think my virtual machine cost a dozen times that much. I don't care. Over in AWS land, I was building out a serverless nonsense thing,

my last tweet in AWS client. And that costs a few pennies a month, all told, plus a whopping 50 cents for a DNS zone, whatever. But because I was deploying it to all regions and the way the config rule evaluations work, my config bill for that was 16 bucks. Now, I don't actually care about the dollar figures on this. I assure you, you could put zeros on the end of that for days

and it doesn't really move the needle on my business until you get to a very certain number there and then suddenly I care a lot. And large enterprises, this is expected because even the sheer cost of people's time to go through these things is valuable. What I'm thinking of is almost the hobby level side project instead, where I'm a student and I'm learning this in a dorm room or in a bootcamp or in my off hours, or I'm a career switcher and I'm doing this on my own dime out of hours. And I wind up getting smacked with the bill for security services that for a company

don't even slightly matter. But for me, they matter. So I'm not going to enable them. And when I transition into the workforce and go somewhere, I'm going to continue to work the same way that I did when I was an independent learner. Like having a wildly generous free tier for small scale accounts,

like even taking a perspective until you wind up costing, I don't know, five, 10, whatever it is, $1,000 a month, wildly generous free tier for small scale accounts, like even taking a perspective until you wind up costing, I don't know, five, 10, whatever it is, thousand dollars a month, none of the security stuff is going to be billable for you because it's, it is not aimed at you. And we want you comfortable with and using these things. This is a whole deep dive into the weeds of economics and price-driven behavior and all kinds of other nonsense. But every time I wind up seeing that like in my actual production account over at AWS land for the Nuckbell Group,

all things wrapped up is something like 1,100 bucks a month. And over a third of it is monitoring, audit, and observability services, and a few security things as well. And on the one hand, I'm sitting here going, I don't see that kind of value coming from it. Now, the day that there's an incident and I have to look into this,

yeah, it's absolutely gonna be worth having, but it's insurance. But it feels like a disproportionate percentage of it. And maybe I'm just sitting here whining and grousing and I sound like a freeloader who doesn't want to pay for things. But it's one of those areas where I would gladly pay more for just having this be part of the cost and not complain at all about it. Well, if somebody sells me a thing that costs a dollar and then they say, want to make it secure? I say, yes, but I'm already suspicious. And they say,

then it's going to be 16 bucks. I'd really freak out because there are certain percentages, certain ratios of the actual thing plus security or secure version of it. 16x is not the answer I expect. 30% probably still not the answer I expect, frankly. I don't know. This is like our ROI questions. Let's also be clear. My usage pattern is really weird. You take a look at most large companies

at significant scale. Their cloud environments, from a billing perspective, look an awful lot like a crap ton of instances or possibly containers running and a smattering of other things. Yeah, you also have database and storage being the other two tiers,

and because of reasons, data transfer loves to show up too. But by and large, everything else is more or less a rounding error. I have remarkably few of those things, just given the weird way that I use services inappropriately, but that is the nature of me.

So don't necessarily take that as being gospel. Oh, you'll spend a third of your bill. Like I've talked to analyst types previously, not you, of course, who will hear a story like this. And that suddenly winds up as a headline in some report somewhere. And it's, yeah, if your entire compute is based on Lambda functions and you get no traffic, yeah, you're going to see some weird distortions in your bill. Welcome to the conversation. But it's a problem that I think is going to have to be addressed at some point, especially we talked about earlier, those vendors who are catering to customers who are not born in the cloud

and they start to see their business erode as the cloud native way of doing things continues to accelerate. I feel like we're in for a time where they're going to be coming at the cloud providers and smacking them for this way harder than I am with my, as a customer, wouldn't it be nice to have this? They're going to turn this into something monstrous. And if that's what it takes,

that's what it takes. But yeah. It would take more time than we think, I think, because again, back in my garden days, I love to make predictions. And sometimes I've learned that predictions end up coming true if you're good, but much later. I'm learning that myself. I'm about two years away from the end of it, because three years ago I said, five years from now, nobody will care about Kubernetes. And I didn't mean that it was going to go away, but I meant that it would slip below the surface level of awareness to the point where most people didn't have to think about it in the same way. And I know it's going to happen, because it's too complex now,

and it's going to be something that just gets handled in the same way that Linux kernels do today. But I think I was aggressive on the timeline. To be clear, I've been misquoted as, oh, I don't think Kubernetes is going to be relevant. It is. It's just going to not be something that you need to spend a quarter million bucks an engineer on to run in production safely. Yeah, yeah. So we'll see.

I'm curious. One other question I had for you while I've got you here is you run a podcast of your own, the Cloud Security Podcast, if I'm not mistaken, which... Sadly, you are not. Yeah, interesting name on that one. Yeah, it's like what, a cloud podcast was taken? Essentially, we had a really cool name, Weather and Security, but the naming team here said, you must be descriptive as everybody else at Google. And we ended up with the name Cloud Security Podcast. Very, very original.

Naming is challenging. I still maintain that the company's renamed Alphabet just so it could appear before Amazon and the yellow pages. But I don't know how accurate that one actually is. Yeah, to be clear, I'm not dunking on your personal fun podcast, for those without context. This is a corporate Google Cloud podcast. And if you want to make the argument that I'm punching down by making fun of Google, please, I welcome that debate. I can't acquire companies as a shortcut to hire people yet. I'm sure it'll happen someday, but I aspire to that level of budgetary control. So what are you up to these days? You spent seven years at Gartner

and now you're doing a lot of cloud security. I'll call it storytelling. And I want to be clear that I mean that as a compliment, not the, oh, you just tell stories rather than build things. Yeah, it turns out that you have to give people a reason to care about what you've built or you don't have your job for very long.

What are you talking about these days? What narratives are you looking at going forward? So one of the things that I've been obsessed with lately is a lot of people from more traditional companies coming in the cloud with their traditional on-premise knowledge, and they're trying to do cloud the on-premise way. On our podcast, we do dedicate quite some airtime to people who do cloud as if it were a rented data center. And sometimes we say the opposite is called, we don't say cloud native, I think. We say, you're doing the cloud the cloudy way.

So if you do cloud the cloudy way, you're probably doing it right. But if you're doing the cloud as rented data center, when you copy your security stack, you lift and shift your IDS and your network capture devices and your firewalls and your SIM, you maybe are okay as a first step. People here used to be a little bit more enraged about it, but to me, we meet customers where they are, but we need to journey with them because if all you do is copy your stack,

security stack from a data center to the cloud, you are losing effectiveness, you're spending money, and you're making other mistakes. I sometimes joke that you copy mistakes, not just practices. Why copy on-prem mistakes to the cloud? So that's been bugging me quite a bit. And I'm trying to tell stories to guide people out of the situation. Not away, but out. A lot of people don't go for the idea of the lift and shift migration. And they say that it's a terrible pattern, and it causes all kinds of problems. And they're right.

The counterpoint is that it's basically the second worst approach, and everything else seems to tie itself in first place. I don't mean to sound like I'm trying to pick a fight on these things, but we're going to rebuild an application while we move it. Great. Then it doesn't work or worse, works intermittently, and you have no idea whether it's the rewrite, the cloud provider, or something else you haven't considered. It just sounds like a recipe for disaster. For sure. And so if you imagine that you're moving the app, you're doing cut and paste to the cloud of the application,

and then you cut and paste security, and then you end up with sizable storage costs, possibly egress costs, possibly mistakes you used to make behind five firewalls. Now you make this mistake straight on the edge. Well, not on the edge, but on the edge of the public internet. So some of the mistakes become worse when you copy them from the data center to the cloud. So we do need to kind of help people to get out of the situation, but not by telling them, don't do it, because they will do it. We need to tell them what's step B, what's step 1.5 out of this. And cost doesn't drive it and security doesn't drive it. Those are trailing functions. It has to be a capability story. It has to be about improving feature velocity or it does not get done. I have learned this the painful way. What about 10x cost? If you do something in a data center-ish way in the cloud and you're 10 times more expensive, cost would drive it? To an extent,

yes. However, the problem is that companies are looking at this from a perspective of, okay, we can cut our costs by 90% if we make these changes. Okay, great. It cuts the cloud infrastructure cost that way. What is the engineering time? What is the opportunity cost that gets baked into that? And what are the other strategic priorities that team has been tasked with this year? It has to go along for the ride with a redesign that unlocks additional capability, because a pure cost savings play is something I have almost never found to be an argument that carries the day. There are always exceptions, to be clear, but the general case I found is that when companies get really focused on cost-cutting

rather than expanding into new markets, on some level it feels like they're not in the best of health, corporately speaking. I mean, there's a reason I talk about cost optimization for what I do and not cost-cutting. It's not about lower the bill to zero at all costs. Cool, turn everything off. Your bill drops to zero. Oh, you don't have a company anymore. Okay, so there's a constraint. Let's talk more about that. Companies are optimized to increase revenue as opposed to reduce costs.

And engineers are always more expensive than the cloud provider resources they're using unless you've done something horrifying. And some people did by replicating their mistakes for their inefficient data center straight into the cloud. Occasionally, yeah. But you're right.

Yeah, it costs, we have the same pattern with Gartner. It's like, it's not about too cheap or in the cloud. I really want to thank you for spending so much time talking to me.

If people want to learn more about what you're up to, how you view the world, what you're up to next, where's the best place for them to find you? At this point, it's probably easiest

to find me on Twitter. I was about to say podcast. I was about to say my Medium blog. But frankly, all of it kind of goes into Twitter at some point. And so I think I am twitter.com Anton underscore Chuvakin, if I recall correctly. Sorry, I haven't really... You are indeed. It's always great. It's one of those, like, you have a sizable audience and you're like, what is my Twitter handle again? That's a good question. I don't know it. It's your name. Right, cool. So you want me to spell that for you, too,

while you're at it. We will, of course, put a link to that in the show notes. I really want to thank you for being so generous with your time. I appreciate it. Perfect. Thank you. It was fun. Anton Shrivakin. Security Strategy Something 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 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 because people are doing it wrong. But also tell me which legacy vendor you work for. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point.

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