Five Characteristics That Define the Cloud with Nicole Forsgren, PhD

About Nicole Forsgren, PhD
Dr. 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 Referenced

Transcript
Speaker 1: 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 this state of the technical world and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

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

Nicole: One of these days that title is going to stick.

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

Nicole: I like it.

Corey: Thank you. You're also the coauthor of the Shingo Publication award winning book, Accelerate: The Science of Lean Software and Dev Ops, 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 dev ops studies to date. You've been a successful entrepreneur with an exit to Google, a professor, a performance engineer, and for your sins assist admin. Your work has been published in multiple peer reviewed journals, whereas my work has been published on Twitter. Nicole, welcome to the show.

Nicole: Thank you. Thank you.

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

Nicole: They were angry.

Corey: Oh, the natives were very restless. But now, when is this going to happen next? That's right. Now.

Nicole: We're here. We have arrived.

Corey: We are. We are. So if you don't know what the State of DevOps report is and 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 Dev Ops report have to say about Cloud?

Nicole: Well I mean, I would be polite except this is your podcast. So I'm going to dive right in. I mean we discovered a few things.

So last time we talked about how the elite performers are developing, delivering software with speed 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? I'm like, well, there are several, so there are several things you can do. I want to say, 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 and things like technology and automation. There are process-based things like working in small batches. Having good visible systems, 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, 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 like I got myself a gym membership, but if I didn't do the work, I'm not going to get any better. Right?

Corey: But that's not what the Cloud sales people told me.

Nicole: I know because they want your money. So like that's really ends up being the big difference in the big problem is that so many people keep redefining Cloud in a million ways. Now, 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, right? 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 percent 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, in 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 if you've seen this?

Corey: I see it constantly when you, 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 SAS 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 of, well is this, 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 is 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.

Nicole: 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 SAS? 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 treating 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.

Corey: 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 GitHub depending on your preferred pronunciation. The second one is correct. Oh, 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.

Nicole: Right. Okay. So I promised I would talk about these five essential characteristics. These are the five. The first one is on demand self surface, right? You have to be able to automatically provision your compute resources without human interaction. You can't be putting it behind a service now ticket where you wait for someone to approve it, that doesn't count because it introduces delay, it introduces air. 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 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 private Cloud or even let's say you're not on a Cloud. Let's say you're in a main frame 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.

Corey: Implementation is left as an exercise for the listener.

Nicole: Yes. So I mean, well 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 got to go figure out what tool that is or you got to figure out which practice that is or you 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. But now you know what things are going to be successful so that if some tool comes out with a new release, like that's fine, just figure it out.

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

Nicole: 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 and 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 that they want to be able to have it for like fail over reasons, like resiliency reasons, so we are seeing more or like more are being reported.

Corey: It's interesting to see that people are going with multiple providers for, 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 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 then you'll ever have running on a single provider in a decent HAA setup.

Nicole: Okay. Set up. Yeah. I mean it's really interesting to see that the types of performance applications that you have when you're split versus single, right. Although I will say that that 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 this space. Right. And by that I mean 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 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 like Cloud is not as secure but honestly for the most part, Cloud is more secure.

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

Nicole: Yeah. 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? Like 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 worked, I have worked at large companies that want to upgrade their data center and suddenly they're told that they need to also install a new power center or power grid for the entire city because they have now maxed out power. And that had not even occurred to them because power space and cooling, you're not just paying for the machines, you're paying for the cooling of the machines. Like there's so many implications here.

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

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

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

Nicole: Yes, yes, yes.

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

Nicole: 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 and that 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 are 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, 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.

Corey: The challenge that I'm trying to wrap my head around is you talk a bit about the report about COTSS 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? What, 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 commercial-est of software?

Nicole: Yeah. So it's interesting you bring this up because when we take a look at the COTSS solutions, they actually look relatively even, right? So we're seeing who 14 percent, we see the lowest use of COTSS, like just like almost no COTSS or like the lowest use of standalone COTSS in low performers. But we see COTSS heavily customize their low performers like 17 percent there. And then we see pretty consistent use of COTSS at medium, high, and elite performers, 21 percent, 18 percent, 20 percent respectively. Now if I look at COTSS heavily customize at medium, high, or low, we see eight percent, seven percent, 10 percent, so it's not really used. So people come to me and they're like, what's this COTSS thing? Right? Like why? I thought COTSS wasn't good, right? Like commercial off the shelf software, like big, big installations, like ERP systems, right? Enterprise resource planning systems.

Corey: It even sounds sleepy.

Nicole: Right? It sounds like enterprisey like Salesforce or like SAP or whatever. And 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 am 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 time and my developer's time. That is where software eats the world. Anything else I buy cheaply and I do not spend my my time on.

So let's start with low performers. Low performers are doing some COTSS, but they're also heavily customizing it. Low performers are not as good at differentiating between things. They're 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 yet no, no, you are not.

Corey: That's what you get when you hire off of Hacker News.

Nicole: Ah, y'all, it doesn't matter. You are not that special. Especially if you're 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 COTSS system and you have to upgrade that COTSS system, you have to un-customize COTSS in order to upgrade. And then you have to re-customize. 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?

Corey: Twitter for pets.

Nicole: Okay. We are Twitter for pets. Okay. We are making-

Corey: It's like regular Twitter only 80 times less racist.

Nicole: 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 COTSS 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 pets. That's where some of those numbers may look similar.

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

Nicole: 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, if 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 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 a 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.

Corey: Excellent.

Nicole: Oh sorry. In the report.

Corey: Some of our listeners may not have done the homework.

Nicole: 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 happened at the organizational level, some things that happened 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.

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

Nicole: 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 like a lot, the part that's probably my favorite is the snark. Do we have time to sneak this in Corey? It's got snark.

Corey: We do indeed.

Nicole: 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. Second thing is-

Corey: Secondly because you make poor decisions.

Nicole: I make poor decisions. Third, because like, oh, what's up? What's the polite way to say this? You have a reputation, you were brutal.

Corey: The good kind or the bad kind?

Nicole: 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 custom 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.

Corey: Of course. Thank you for appreciating it and asking me. It's, to be clear, none of this is intuitively obvious. It's the you only, 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 costs savings. That's not the big driver for successful Cloud stories. It's capability enhancements.

Nicole: Yeah. Well it's interesting though because the two can go hand in hand. So I know that the Broad 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 reduced 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.

Corey: 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, et cetera, et cetera. 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 born out. Now, does that mean that going into 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.

Nicole: I mean I do think it is long term, even sometime 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.

Corey: Which is harder than you'd think. If there were an API for fixing people, it would need some serious rate limits.

Nicole: I know, I know.

Corey: Ah, if people want to hear more of your wise thoughts, where can they find you?

Nicole: Well, I am on twitter @nicolefv and my website is nicolefv.com.

Corey: Excellent. Nicole, thank you so much for taking the time to speak with me again.

Nicole: Absolutely. Oh, can I throw out one more quick note? Dora's research is all online now at Cloud.google.com/devops

Corey: And I have gone up one side and down the other. It is not partisanly slanted towards Google.

Nicole: It's all of our research.

Corey: 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 foresight to sponsor. Frankly, that shows clear thinking on Google's part.

Nicole: I mean some people are smart.

Corey: Exactly. Thank you once again for your time, patience, and continued tolerance of me.

Nicole: Thanks for having me.

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

Speaker 1: 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.

Speaker 1: This has been a HumblePod production. Stay humble.