Screaming in the Cloud - Five Characteristics That Define the Cloud with Nicole Forsgren, PhD

Episode Date: October 2, 2019

About Nicole Forsgren, PhDDr. Nicole Forsgren does research and strategy at Google Cloud following the acquisition of her startup DevOps Research and Assessment (DORA) by Google. She is co-author of the Shingo Publication Award winning book Accelerate: The Science of Lean Software and DevOps, and is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been an entrepreneur, professor, sysadmin, and performance engineer. Nicole’s work has been published in several peer-reviewed journals. Nicole earned her PhD in Management Information Systems from the University of Arizona, and is a Research Affiliate at Clemson University and Florida International University.Links ReferencedTwitter Username: @nicolefvLinkedIn URL: https://www.linkedin.com/in/nicolefv/Personal site: nicolefv.comCompany site: cloud.google.com/devopsManifold: https://www.manifold.co/ 

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. This episode of Screaming in the Cloud has been sponsored by Manifold. Manifold powers marketplace infrastructure that connects millions of developers to the best APIs, tools, and services in the fastest growing communities, and also Kubernetes.

They offer a complete toolkit that allows you to deliver your API-first product to millions of developers. Check them out at manifold.co. Again, that's manifold.co. Hello, and welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Dr. Nicole Forsgren, who's a VP of Research and Strategy at Google Cloud.

One of these days, that title's going to stick. I insist it always will stick. You may argue with me that you're not a VP there, and I will well actually you into saying, yes, you are. I like it. Thank you. You're also the co-author of the Shingo Publication Award-winning book, Accelerate, The Science of Lean Software and DevOps. And you're also best known, the reason we're having this conversation, again,

is that you're known as the lead investigator on the largest DevOps studies to date. You've been a successful entrepreneur with an exit to Google, a professor, a performance engineer, and for your sins, a sysadmin. Your work has been published in multiple peer-reviewed journals, whereas my work has been published on Twitter. Nicole, welcome to the show. Thank you. Thank you.

So when last we spoke, we did a podcast recording about the Accelerate State of DevOps report, and it was glorious because people really engaged with that episode. They listened. They were excited. And right when we got to the cloud part, and we'll pick this up next time. Well, when is next time? We didn't tell anyone.

They were angry. Oh, the natives were very restless. But now, when is this going to happen next? That's right. Now. We are here. We have arrived. We are. So if you don't know what the state of DevOps report is, you might be forgiven for that.

Go ahead and listen to the first episode with Nicole a few weeks back, and then come back to this one. Because we're not going to cover the same ground. We're exploring new ground. And we begin with cloud. What did the State of DevOps report have to say about cloud? Well, I mean, I would be polite, except this is your podcast, so I'm going to dive right in. I mean, we discover a few things. So last time we talked about how the elite performers are developing, delivering software with speed and stability, and they're optimizing on all dimensions. We also found that low performers are on the struggle bus.

Now, so often people are like, well, how do I get better? Like, well, there are several things you can do. I want to say, you know, the professor in me is going to say, do your homework. You can read the report. You can read six years of the report. You can read the book. It basically falls into a few categories, right? There's continuous delivery, things like technology and automation. There are process-based things like working in small batches, having good visible systems and viewable systems, right? That also falls into metrics and monitoring. There's also having a good culture. There's also the cloud, right? At that point, executives like

scrunch up their face at me and they're like, well, we went to the cloud and we didn't see performance improvements. And I'm like, wait, so did you go to the cloud or did you like write the check for the cloud? Because I mean mean like i got myself a gym membership but if i didn't do the work i'm not going to get any better but that's not what the cloud sales people told me i know because they want your money so like that's that's really ends up being the big difference and the big problem is that so many people keep redefining cloud in a million ways. Now, you know, the very smart, astute listeners of this program are going to say, well, then Nicole, how are you going to be able to tell me that using the cloud is a statistically significant predictor of performance if no one knows what they're talking about.

Astute listeners, I love you. So here's what we do. What we do is we come to a clear definition. And y'all, I did not make this up. I look to NIST, National Institute of Standards and Technology. They have a NIST framework. And using this framework, there are five essential characteristics. And what we find is that for people who are using the cloud and executing on these five characteristics, elite performers are 24 times more likely to have met all of these essential characteristics. So that's what it means when I say, if you're in the cloud and if you're doing it right and if you're not cheating, right? Like I bought the gym membership and I actually went, we see performance gains. So, and, however, right?

Yes, and. Of the people who say they're using cloud, only 29% are actually using cloud infrastructure and executing on all five capabilities. So I think this also helps explain this huge disconnect that we see all over the place in industry when people are like, well, I'm in the cloud, or but I'm in the cloud, and I'm in hybrid cloud and multi-cloud and on-prem and so many different definitions of cloud is that we're all talking past each other.

We don't always have the same definition, right? We don't have a shared language that's so important. I mean, I don't know if you've seen this. I see it constantly, especially when people try to participate in that least productive of all activities, which is ranking the cloud providers. The cloudwars.co run by Baghdad Bob Evans insists the number one cloud vendor is Microsoft, number two is Amazon, and number three is Salesforce, which is a little on the nutty side because until you dig into this and realize,

oh, if you're including things like SaaS and whatnot and a bunch of other stuff, SAP is beating Oracle, is beating Google. Okay, but at some point, that just means software that runs on someone else's computer and it becomes a list without distinction i would argue it doesn't even matter beyond that as well is let's look at number two for those of us who live here in the infrastructure world of number two is azure almost certainly and then

potentially google but wait what if that's backwards what if the other two what if it goes the other way around and the answer, who cares? If that is your decision framework for picking a provider, who's the biggest? Or where exactly does it fall in the ranking? Is it number six or is it number seven? Then I'm afraid I just don't care anymore. I don't see how that factors into anything meaningful. Honestly, I love that you brought this up, right? It fundamentally matters how you define cloud. And so we have defined it according to NIST. And these NIST five, I'm going to get to in just a hot second, because I want to take a half step back. It matters according to how you define it, and how you define it in terms of what is important to your organization, right?

So many people just say, oh, it's just the cloud, right? Okay, does that mean it's a SaaS? Does that mean it's highly available? Does that mean it's highly reliable? Also, how does your organization define and depend on highly available, highly reliable. Because right now, so many organizations and so many executives who might not be super technical are trading cloud, cloud, the cloud, like it's a commodity. And it might not necessarily be a fungible commodity.

They aren't necessarily the top two, top three, top seven clouds for whatever definition they are, are not necessarily completely tradable, right? They're not necessarily the same thing. And unless you understand what your decision criteria is, unless you know what your definition of what's important to you is, you can't just say, I'm going to trade out this cloud provider for this cloud provider for this cloud provider because they actually have different characteristics depending on what you're looking for. And so many organizations and decision makers in organizations don't fully grok that just yet. Oh, yes. I mean, at this point, I'm running a five-person company and we are, depending on who you ask, multi-cloud across the board because all of our infrastructure is on AWS but we use G Suite

for our email internally and yes, oh that's right, we are paying GitHub customers or Jithub depending on your preferred pronunciation, the second one's correct, and of course, we have Office 365 floating around. So yes, we are full cloud customers. And we're just not talking about apples to rutabagas here. Right? Okay, so I promised I would talk about these five essential characteristics. These are the five. The first one is on-demand self-service, right?

You have to be able to automatically provision your compute resources without human interaction. You can't be putting it behind a ServiceNow ticket where you wait for someone to approve it. That doesn't count because it introduces delay, it introduces error, it's got to be fully automated. And honestly, like that's the biggest mistake and the biggest problem we ever see. The second is broad network access. So can you access it from multiple devices? The third is resource pooling. So basically are the provider resources pooled

in a multi-tenant model where resources are kind of like dynamically assigned on demand. The third is rapid elasticity. Most do okay with this, right? So bursting like magic. Can you handle like a Black Friday situation? And then the fifth is measured service. So systems can automatically control and optimize and report resource use.

And that's all you're paying for. So those are the five. Now, something that I think is interesting and important to note here is that these are also architectural outcomes. They're design outcomes. They're automation outcomes. Whether you're on a public cloud or a private cloud or even let's say you're not on a cloud. Let's say you're in a mainframe environment, you can improve your software delivery performance by architecting your infrastructure

with these outcomes in mind. That's all you have to do. I mean, I say it like it's easy, right? You still have to put in the work. Implementation is left as an exercise for the listener. Yes. So, I mean, it's interesting you point that out. Some people get real mad at me because I do this research and I do it with capabilities and practices in mind. It's an evaluative criteria or it's an implementation criteria. I love that you say it that way.

I don't do it with tools, which means that I haven't told you which tool to buy. Instead, I tell you which things to implement. So now you've got to go figure out what tool that is or you've got to figure out which practice that is or you've got to figure out which bash scripts to build, right? But now that means that you can select any tool you want. You can select any cloud you want. You can select any bash script to build, right? But now that means that you can select any tool you want. You can select any cloud you want. You can select any bash script to build. But now you know what things are going to be successful. So that if, you know, some tool comes out with a new release,

like that's fine, just figure it out. Which makes an awful lot of sense. Did you do any analysis in the report on multi-cloud, hybrid cloud, anything that involves smashing two clouds or more together? I think that's called a thunderstorm. So we ask what types of trends people are seeing, but it's because people are talking past each other so much, we don't do analysis there. Because I can't run real analysis until I know I have consistency in measurement, consistency in language, consistency in terminology. And so all we do is basic trends there. We do see an increase in people who are reporting using more multi-cloud and hybrid cloud.

So I do think that's really interesting. And anecdotally, and by anecdotally, I mean, like, I work with dozens of companies and I go to like way too many conferences. And we are seeing lots and lots of people who are saying that they're using more multi and hybrid cloud solutions for lots of different reasons, right? Sometimes it's for flexibility. Sometimes they say it's because of regulatory concerns. Sometimes they say it's because of risk, right? Like they don't want to be locked into one cloud. They want to be able to have it for like failover reasons, like resiliency reasons. So we are seeing more or like more are being reported.

It's interesting to see that people are going with multiple providers from two different angles. And one of which I agree with, which is the idea of picking best of breed individual services and putting a workload that makes sense into there. That works really well. The second is, oh, we want to have resiliency, so we're going to put the same thing on two different providers. Yeah, then you find that you have more outages caused by heartbeat failures or split brain or some other weird interconnection problem than you'll ever have running on a single

provider in a decent HA setup. or some other weird interconnection problem than you'll ever have running on a single provider in a decent HA setup. Yeah, I mean, it's really interesting to see the types of performance applications that you have when you're split versus single, right? Although I will say that oftentimes, oftentimes slash most times, we do see stronger and better performance when you're in the cloud versus on-prem, particularly for SMBs and corporate clients, because you can rely on people who are already experts in the space. Unless you are very, very, very large, it can be difficult to have to maintain several nines of availability and all of the regulatory requirements that surround most of your businesses, right?

Like the availability, the uptime, the servers, the physical access, the power requirements, right? Power, space, and cooling around that. So in general, and I think most of, I mean, I almost feel bad repeating this until I actually run into someone who is still trying to argue that cloud is not as secure. But honestly, for the most part, cloud is more secure. It absolutely is from a perspective

of a variety of things that people have forgotten about, of having to check the ID of people walking into the data center, of having the low-level baseline stuff handled by someone who does nothing but this at all times. The availability improves because when you have an array fail, instead of waking a couple of people in your team up, they're swinging 200 of the best in the industry into place to fix this thing at scale. Well, there's also some cover. When you're down and everyone else is down, why people aren't going to be yelling at you in the headlines, it's the provider that gets thrown under the bus, if that's the analogy we're going with this week.

Yep. Well, and even, so you just said checking the ID of the person who enters the data center. Many times people don't even think about checking the ID of the person that has access to the power lines, right? Once you're operating at a high enough scale, you suddenly need to be worried about access to power. Or what happens if you want to build out a larger data center? I have worked at large companies that want to upgrade their data center, and suddenly they're told that they paying for the machines, you're paying for the cooling of the machines. There are so many implications here. There's something to be said for making as many of these problems someone else's, as long as they're not aligned with the core competency of what your company does. It seems to be the right answer.

Exactly, exactly. To a point of scale, right? I mean, there are cases where once you're very, very, very large, having on-prem for certain types of workloads can make sense. But for the vast majority of organizations, cloud is kind of the smartest move. The only thing that's better than paying someone else to solve your problems is tricking chumps

into solving them for you for free, which brings us to open source. Yes, yes, yes. One of the findings that I found interesting in the report was that the lowest performers use the most proprietary stuff. Is that an oversimplification? It's actually not. So I mean, a tiny bit, but also not really. So when we take a look at the data across tool usage and open source, what we see is that the lowest performers are using the most, what we would kind of term as like fully proprietary software, right? So it's primarily

developed in-house, it's proprietary to the organization. And what that ends up doing and what that ends up meaning to the organization is you have the fully burdened cost completely dependent on you. You have to build it. You have to maintain it. You have to document it. You are also incredibly limited in terms of recruiting. You have very, very high risk in terms of turnover. It's really difficult, right? And then when you look at the contrast, when we look at open source, open source ends up having lower costs. Now, I'm going to put an asterisk there, right? Because open source, the joke is like, open source is like a puppy, right? Like it's free, but you have to pay to maintain it.

But those costs end up being, many of those costs end up being very distributed. If you have a question, you can source that question internal to the company if there's a proprietary piece of the question that's related. But you also have a large community from which you can draw solutions. You have a large community that is actively developing and testing that solution. You have an open community from which you can draw for recruiting and even excitement, right? So excitement in terms of like training, they're actively developing a workforce. You don't have as many concerns about aging out a workforce, whereas fully proprietary solutions, you alone are responsible for training up and remaining current and understanding what the state of the art is. No one else knows what the state of the art is. The entire community for open source knows what the state of the art

is. They're currently discovering bugs and side cases and what happens if you develop something in this weird, bizarre, complex distributed system, right? Like you and your company, in contrast, when you're looking at, you know, in-house developed proprietary tools, your organization is the only one doing that. So it's really hard to discover what those types of things look like. The challenge that I'm trying to wrap my head around is you talk a bit about the report about COTS or commercial off-the-shelf software. That feels like it is the antithesis of open source software. Everyone's open source trying to be smashed into a business model, notwithstanding. And it seems to me that there is definitely a correlation,

but what drives it? I understand that you're doing the research and showing the data and correlation does not indicate causation, but do you have an operating theory as to why the crappiest of teams often tends to use the commercialist of software? Yeah. So it's interesting you bring this up because when we take a look at the COTS solutions, they actually look relatively even, right? So we're seeing 14%. We see the lowest use of COTs, like just like almost no COTs or like the lowest use of standalone COTs in low performers. But we see COTs heavily customized in low performers, like 17% there. And then we see pretty consistent use of COTs at medium, high and elite performers, 21%, 18%, 20% respectively. Now, if I look at COTS heavily

customized at medium, high, and low, we see 8%, 7%, 10%. So that's not really used. So people come to me and they're like, what's this COTS thing, right? Like why? I thought COTS wasn't good, right? Like commercial off the shelf software, like big, big installations, like ERP systems, right? Enterprise Resource Planning Systems. It even sounds sleepy. Right? It sounds like enterprise-y, like Salesforce or like SAP or whatever. They're like, but I thought we were supposed to be doing the software development delivery. I thought software was eating the world. So this is a case where if you only look at the data and you don't dig in,

it can be, I'm not going to say misleading, it can be misleading or it can be confusing or you cannot know what's happening. But if you take another look, if you take a step down, here's what we see. Martin Fowler has this great article and we link to it in the report on utility versus strategy. The elite performers are incredibly strong and disciplined at this. The low performers, God bless them, they usually kind of suck at this. Here's the difference. Utility. Think about utilities, commodities.

You turn the lights on, right? I turned my lights on. I got electricity. I'm not going to make my own electricity. I'm going to buy it. I need to spend minimal resources to acquire things that are the same thing for everyone. I will spend my resources on my time on strategic things that deliver value that no one else can get. So the things that make me money, that differentiate me, that make me special, that's where I spend my resources and my do not spend my time on. So let's start with low performers. Low performers are doing some cots, but they're also heavily customizing it. Low performers are not as good at differentiating between things that are strategic

and things that are not. They also love the idea of solving hard problems and deriving everything from first principles. And so they might go ahead and roll their own HR system and roll their own accounting system and heavily customize everything because they are a special, special snowflake and they have amazing processes that make them unique. No, no, you are not. That's what you get when you hire off of Hacker News. Y'all, it doesn't matter. You are not that special, especially if you are a smaller company. Now, if you have, if you're the People's Republic of China, and you have like 20 million employees, okay, then it might be worth customizing. But keep in mind, every time you customize a COTS system, and you have to upgrade that COTS system, you have to un-customize COTS in order to upgrade, and then you have to

recustomize. That is epic amounts of resource that you are spending. Okay. Now in contrast, look at the elite performers. They are disciplined. They are rigorous. They are ruthless. They will say, is this something that delivers core value and competency to the company? Let's say, okay, let's make up a company, Corey. What are we building and delivering? Twitter for pets. Okay. We are Twitter for pets. Okay, we are Twitter for pets. Okay, we are making- It's like regular Twitter, only 80 times less racist.

Yes, and full of cute, cute puppers and adorable kittens. I like this. Okay, so as part of our core value, that is absolutely what we build. We build Twitter for pets. We optimize algorithms to bring the cute puppers and the great GIFs and the animated GIFs and the cute animations.

And it will make sure that the volume is not too loud because my ears don't like it late at night. And if the volume is low enough, it will also get past my boss when my boss walks by. I like this. Okay. We will not roll our own HR systems. We will not roll our own accounting systems. We will not roll our own talent acquisition systems. We will buy those. That is what we will buy. and we will be ruthless about it. That is the difference. So that is why our COTS numbers will look similarly high, because yes,

we will buy systems, even though software is eating the world, and then we will spend all of our resources building the perfect Twitter for bets. That's where some of those numbers may look similar. Gotcha. Yeah. So take it one step further for me, please. If I'm reading the report and looking around and what you've just said resonates in really uncomfortable ways. And I look around and realize that my organization is, in fact, crap, or low-performing is the polite term for it. What can I do about it? Do I start polishing my resume? Do I take it personally in that, oh my God, maybe I'm the problem

and no one ever told me this before? What is the next step? I generally imagine that the next step is not to sit there and feel sorry for oneself, but what is? I mean, I've been there. I usually do that for about a day and then I drink Diet Coke and I eat ice cream. That always makes me feel better. Okay. And then there's a plan of action, right? And we can think about what our next steps will be. And it kind of depends on where we are in the organization, right? So if we want to improve our performance, like our speed and stability, there are, like I said, there are categories of things that we can do to get better.

There are things like technology and automation. There are things like process, like working in small batches, improving our change approval process, there are things like improving culture. Now, where we sit in the organization changes the types of things that we can influence. So if I'm an IC, I'm an individual contributor or practitioner, some things that I have great influence over and a lot of amazing power to change are things like implementing test automation, helping with deployment automation, right? Those are things that have shown to have like great predictive ability over improving software development and delivery. Those are great things I can do. If I am at an executive level, right, some things that only I can change or things that I have oversized influence over are things like improving the change approval process.

Because there's some bureaucracy tied up in there, right? So taking a look at our process, removing some heavyweight change approvals. By the way, check out the report. We've got a great section on how the CAB can move to being a more strategic body. But even just taking a look at the change approval process to make sure it's more clear. It doesn't even have to be automated yet. But if it's clear for everyone to know how to get from start, submitted, to end and approved. Now, some ICs can do that too in part by documenting it and understanding what those steps are, the variability in those steps, so that you can highlight it and pass it to the top. Now, some things you kind of want coordination,

right? Like the CI process. That is an IC process, but it may take coordination among groups because that CI process can span several teams. So understanding where you are and where your impact is going to be the strongest can be a huge win and a huge benefit to organizations. And by the way, we do outline this in the book as well. Oh, sorry, in the report. Some of our listeners may not have done the homework. I know. It's okay, though. That's why we're talking about it. Because like, let's be real, it's kind of long. I'm sorry. I got so excited. But we will include a link to the report. And the part where I just outlined that there are some things that happen at the organizational level, some things that happen at the team level, and some things

that happen at both the team and the organization level, that's on page 39. So now you can just like skip straight to that section. Excellent. But if you decide not to read any of these things, and instead only pick one page, I highly, highly, highly recommend that you pick, I believe it's page 78, the acknowledgements page, because I'm listed there. Okay. So if you want to check out the, that's actually page 79. I'm awful. I'm going to correct you. Okay. But you know what? The part that Corey, well, Corey helped with a bunch of stuff, but the part that he helped with a lot, the part that's probably my favorite is the snark. Do we have time to sneak this in,

Corey? It's not snark. We do indeed. It's real. I think we should. And it's a nice throwback to what we were talking about earlier with cloud. So cloud helps us with availability. Cloud helps us with reliability. Cloud also helps us understand how to align incentives so that we can reduce costs and have better transparency. Now, the thing I loved about this is I invited Corey to be an early technical reader. And I did this for a couple of reasons. First, because Corey knows

what he's talking about. Secondly, because you make poor decisions. I make poor decisions. Third, because Corey, like, what's a polite way to say this? You have a reputation. You were brutal. A good kind or the bad kind? I mean, you were brutal. You gave me some solid feedback that, like, I think I had one sentence in there that was like, oh, yeah, also, by the way, like, cloud can help you with cost savings, because we had some really great data around that. And then Corey, I think you included a comment that was by a comment, I mean, like four paragraphs long, where you pointed out, yes, cloud can help you with cost savings, but how do you explain this to the CFO? And so we include what this incentive structure looks like and how the shift to the cloud gives you amazing, amazing opportunity

to align incentives and to drastically reduce costs because of greater information transparency. But organizations have to align incentives better in order to do this. Otherwise, it won't happen. And so like, this is totally sincere, Corey. Thank you so much for like helping me understand

that I had to get that out of my head because it was in my head. I used to be an accounting professor. I used to do cost of managerial accounting. So I knew it, but I had not fully articulated it until you called me on my BS. And so now this is much more clearly articulated in this amazing sidebar on page 37. So thank you. Of course.

Thank you for appreciating it and asking me. To be clear, none of this is intuitively obvious. I spent three years going through environments where I look at AWS bills and the spend and how that's driving change organizationally, and I don't really find a lot of cost savings. That's not the big driver for successful cloud stories. It's capability enhancements. Yeah. Well, it's interesting, though, because the two can go hand in hand. So I know that the Barad Institute does research. They happen to do research on Google Cloud, but they took an iterative approach, right? So they initially moved to the cloud. And then by understanding that and having this greater transparency, then they were able to change how they were architecting their work and then like gradually reduce their footprint right so you're right like initially it comes down to increasing your capabilities but it is possible you just have to make sure that the transparency is there for

your systems engineers and then have those mechanisms available because if it just remains completely invisible to everyone it just comes down to like a change in how you're building out your cloud so it's super interesting it's something that i don't think is well understood even among companies that have gone through it because they take a look and they see that things are attributed much more granularly you pay for what you use etc etc and it feels like you're spending less or accounting isn't bothering you anymore because they are so overwhelmed by the fact that you have a massive amazon bill and they just assume you're buying way too many books and they don't tend to think of it any more closely than that. But whatever the reason, it feels more removed. And if you start looking at some of the higher-level strategy pieces,

that isn't always borne out. Now, does that mean that going to cloud is a dumb, expensive move? Maybe, maybe not. That depends on the specifics. But understand what you're going to get out of it. If we're going to recoup our expenses in year one, are you really? One wonders. I mean, I do think it ends long-term, even sometimes short-term. It ends up being a really smart decision as long as everyone understands what the architectural outcomes

should be and everyone's aligned, right? It just, shocker, just requires communication, right? We just have to be aligned. Which is harder than you'd think. If there were an API for fixing people, it would need some serious rate limits. I know, I know. If people want to hear more of your wise thoughts, where can they find you? Well, I am on Twitter at Nicole FV. And my website is Nicole FV.com. Excellent.

Nicole, thank you so much for taking the time to speak with me again. Absolutely. Oh, can I throw out one more quick note? Please do. Dora's research is all online now at cloud.google.com slash DevOps. And I have gone up one side and down the other. It is not partisanly slanted towards Google. It's all of our research. I will say it is slightly biased on the first page because they include Google's logo, but not other cloud competitors' logos because apparently those other companies

did not have the, I guess, foresight to sponsor. Frankly, that shows clear thinking on Google's part. I mean, some people are smart. Exactly. Thank you once again for your time, patience, and continued tolerance of me. Thanks for having me. This is Screaming in the me. Thanks for having me.

This is Screaming in the Cloud. I'm Corey Quinn, and this was Dr. Nicole Forsgren, VP of Research and Strategy at Google Cloud. Thanks for listening, and I'll talk to you next week. 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 humble pod production stay humble