Screaming in the Cloud - Summer Replay - Building a User-Friendly Product with Aparna Sinha

Episode Date: August 20, 2024

On this Screaming in the Cloud Summer Replay, we revisit our conversation with Aparna Sinha, the Head of AI Product at Capital One. As a former Director of Product Management at Google Cloud, Aparan joins Corey to talk about GCP and how Corey was surprised to find that, in some ways, it was “its own universe.” She offers up why folks can expect a developer user-friendly experience when using GCP, and how it differentiates them from the litany of cloud providers out there. From focusing on developing, to a vast array of customers, GCP is bringing their best forward. Check out their conversation on how GCP is keeping its focus on the user!Show Highlights:(0:00) Intro(0:48) Duckbill Group sponsor read(1:21) Role of a Director of Outbound Product Management(2:43) Developer experiences on Google Cloud(8:47) The philosophy of courting developers(11:38) The shift to serverless(17:17) Cloud Run observations(22:59) Duckbill Group sponsor read(23:43) Customer involvement with Google Cloud(28:55) Cloud Build vs. Cloud Deploy(32:50) Google and cloud security(38:45) Where you can find AparnaAbout AparnaAparna Sinha is Senior Vice President and Head of Enterprise AI/ML products at Capital One. She is also a startup investor / advisor at PearVC. Aparna has a track record of successful P&L ownership, creating new revenue streams and building $B+ businesses through technical and go-to-market innovation. She was Sr. Director of Developer Products at Google Cloud leading a 100+ member PM, UX, and DevRel Engineering team responsible for >40 cloud services and open source tools. She was an early contributor to Kubernetes, built the team and grew Google Kubernetes Engine 100x into a Top 3 revenue generator for Cloud. Prior to Cloud Aparna worked on Android, ChromeOS and Play. Previously at McKinsey & Company she was a leader in the business technology office, working with CIOs on server virtualization strategy, pricing, and SaaS.Aparna holds a PhD in Electrical Engineering from Stanford, and a patent from Google. She served as Chair of the Governing Board of the Cloud Native Computing Foundation (CNCF).Links:DevOps Research Report: https://www.devops-research.com/research.htmlTwitter: https://x.com/aparnabsinhaOriginal Episode:https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/building-a-user-friendly-product-with-aparna-sinha/Sponsor:The Duckbill Group: https://www.duckbillgroup.com/

the developers that I work with and the developers that this platform serves are the inspiration for what we do. And in the last six or seven years that I've worked in Google Cloud, that has always been the case. Welcome to Screaming in the Cloud. I'm Corey Quinn. We have a bunch of conversations on this show covering a wide gamut of different topics, things that I find personally interesting, usually, and also things I'm noticing in the industry. Fresh on the heels of Google Next, we get to ideally have conversations about both of those things. Today, I'm speaking with the Director of Product Management at Google Cloud, Aparna Sinha. Aparna, thank you so much for joining me today. I appreciate it.

Thank you, Corey. It's a pleasure to be here. This episode is sponsored in part by my day job, the Duck Bill Group. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more, visit duckbillgroup.com. Remember, you can't duck the duck bill bill. And my CEO informs me that is absolutely not our slogan. So director of product management is one of those interesting titles. We've had a repeat guest here, director of outbound product management, Richard Sirota, which is great. I

assume, as I told him, outbound products are the ones that are about to be discontinued. He's been there a year and somehow has failed to discontinue a single thing. So, okay, I'm sure that's going to show up on his review. What do you do? The products aren't outbound, they're just products, and you're managing them, but that doesn't tell me much. Titles are always strange. Yeah, sure. Richard is one of my favorite people, by the way. I work closely with him. I am the director of product for developer platform. That's Google Cloud's developer platform. It includes many different products, actually 30 plus products. But the primary pieces are usually when a developer comes to Google Cloud, the pieces that they interact with, like our command line

interface, like our cloud shell, and all of the SDK pieces that go behind it. And then also our DevOps tooling. So as you're writing the application in the IDE, and as you're deploying it into production, that's all part of the developer platform. And then I also run our serverless platform, which is one of the most developer friendly capabilities from a compute perspective. It's also integrated into many different services within GCP. So behind the title, that's really what I work on. Okay, so you're, I guess, in part responsible for, well, I guess a disappointment of mine a few years ago. I have a habit on Twitter, because I'm a terrible person, of periodically spinning up a new account on various cloud providers and kicking the tires and then live tweeting the experience. And I was really set

to dunk on Google Cloud. I turned this into a whole blog post. And I came away impressed where the developer experience was pretty close to seamless for getting up and running. It was head and shoulders above of what I've seen from other cloud providers. And on the one hand, I want to congratulate you. And on the other, it doesn't seem like

that's that high of a bar, to be perfectly honest with you, because it seems that companies get sort of stuck in their own ways and presuppose that everyone using the product is the same as the people building the product. Google Cloud has been and remains a shining example of great developer experience across the board. If I were starting something net new and did not have deep experience with an existing cloud provider, which, let's face it, the most valuable thing about a cloud is knowing how it's going to break because everything breaks,

I would be hard-pressed to not pick GCP if not as the choice, at least a strong number two. So how did that come to be? I take a look at a lot of Google's consumer apps, and this is a great user experience, isn't really something I find myself saying all that often. Google Cloud is sort of its own universe. What happened? Well, thank you, first of all, for the praise. We are very humble about it, actually. I think that we're grateful if our developers find the experience to be seamless. It is something that we measure all the time. That may be one of the reasons why you found it to be better than other places. We are continuously trying to improve the time to value for developers, how long it takes them to perform certain actions. And so what you measure is what you improve,

right? If you don't measure it, you don't improve it. That's one of our SRE principles. I wish I've been measuring certain things for years and they don't seem to be improving at all. It's like, wow, my code is still terrible, but I'm counting the bugs and the number isn't getting smaller. It turns out there might be additional steps required. Yes. You know, we measure it. We look at it. We take active OKRs to improve these things, especially usability.

Usability is extremely important for certainly the developer platform. For my group, that's something that's extremely important. I would say stepping back, you back, you said it's not that common to find a good user experience in cloud. I think in general, and I've spent the majority of my career, if not all of my career, working on enterprise software. Enterprise software is not always designed in the most user-friendly way. It's not something that people always think about. Some of the enterprise software I've used has been really pretty bad. It's just a list of things.

Oh, yeah. And it seems like their entire philosophy, I did a bit of a dive into this, and I think it was Stripe's Patrick McKenzie who wound up pointing this out originally, though. But the internet is big, and people always share and reshare ideas. The actual customer for enterprise software is very often procurement or a business unit that is very organizationally distant from the person who's using it. And I think in a world of a cloud platform, that is no longer true. Yeah, there's a strategic decision of what cloud do we use, but let's be serious. That decision often comes into play long after there's already been a shadow IT slash groundswell uprising. The sales process

starts to look an awful lot less like pick our cloud and a lot more like you've already picked our cloud. How about we formalize the relationship? And developer experience with platforms is incredibly important. And I'm glad to see that this is a, well, it's bittersweet to me. I am glad to see that this is something that Google is focusing on, and I'm disappointed to admit that it's a differentiator. It is a differentiator. It is extremely important. At Google, there are a couple of reasons why this is part of our DNA, and it is actually related to the fact that we are also a consumer products company. We have a very strong user experience team,

a very strong measurements oriented. They measure everything and they design everything and they run focus groups. So we have an extraordinary usability team. And it's actually one of the groups that just like every other group is fungible. Like, you know, you can move between consumer and cloud. There's no sort of difference in terms of your training and skill set. And so I know you said that you're not super impressed with our consumer products, but I think that the practice behind treating the user as king, treating the user as the most important part of your development is something that we bring over into cloud. And it's just a part of how we do development. And I think that's part of the reason why our products are usable. Again, I shy away from taking any kind of really high credit on these things because I think I always have a very high bar. I want them to be delightful, super delightful, but we do have good usability scores on some of the pieces. I think our command line, I think is quite good. I think there's always improvements, by the way, Corey. But I think that there are certain things that are delightful.

And a lot of thought goes into it and a lot of multifunctional, meaning across product, user experience and engineering we have and developer relations. We have sort of this four-way communication with friction logs and with lots of trials and lots of discussion and measurements is how we improve the user experience. And I would love to see that in more enterprise software. I think that my experience in the industry is that the user is becoming more important generally, even in enterprise software, probably because of the migration to cloud. You can't ignore the user anymore. This shouldn't be all about procurement. Anybody can procure a cloud service. It's really about how easily and how quickly can they get to what they want to do as a user, which I think also the definition of what a developer is changing. And I think that's one of the most exciting things about our work is that the developer can be anybody. It can be my kids, and it can be anyone across the world. And our goal is to reach those people and

to make it easy for them. If I had to bet on a company not understanding that distinction, on some level, Google's reputation lends itself to that. Where, oh, great, I'm a little old to go back to school and join a fraternity and be hazed there. So the second option was, oh, I'll go and interview to be an SRE at Google, where, oh, great, you've done interesting things, but can you invert a binary tree on a whiteboard? No, I cannot. Let's save time and admit that. So the concern that I would have had, you just directly contradicted, was the idea that you see at some companies where there's the expectation that all developers are like their developers. Google, for better or worse, has a high technical bar for hiring. A number of companies do not have a similar bar along similar axes,

and they're looking for different skill sets to achieve different outcomes, and that's fine. To be clear, I am not saying that, oh, the engineers at Google are all excellent, and the engineers all at a bank are all crap. Far from it. That is not true in either direction. But there are differences as far as how they concern themselves with software development, how they frame a lot of these things.

And I am surprised that Google is not automatically assuming that developers are the type of developers that you have at Google. Where did that mindset shift come from? Oh, absolutely not. I think we would be in trouble if we did that, right? I studied electrical engineering in school. This would be like,

you know, assuming that the top of the class is kind of like the kind of people that we want to reach. And it's just absolutely not. Like I said, I want to reach total beginners. I want to reach people who are non-developers with our developer platform. That's our explicit goal. And so we view developers as individuals with a range of superpowers that they've gained throughout their lives, professionally and personally, and people who are always on a path to learn new things. And we want to make it easy for them. We don't treat them as bodies in a employment relationship with some organization or people with certain minimum bar

degrees or whatever it is. As far as interviewing goes, Corey, in product management, which is the practice that I'm part of, we actually look for in the interview that the candidate is not thinking about themselves and they're not imposing themselves on the user base. So can you think outside of yourself? Can you think of the user base? And are you inquisitive? Are you curious? Do you observe? And how well do you observe differences and diversity?

And how well are you able to grasp what might be needed by a particular segment? How well are you able to segment the user base? That's what we look for, certainly in product management, and I'm quite sure also in user experience. You're right, on engineering, of course, we're looking for technical skills and so on, but that's not how we design our products. That's not how we design the usability of our products. If you people were just a little bit smarter slash more like me, then this would work a lot

better is a common trope, which brings us, of course, to the current state of serverless. I tend to view serverless as largely a failed initiative so far. And to be clear, I'm viewing this from an AWS-centric lens that is the, we'll be charitable and call it pool in which I swim. And they announced Lambda in 2015. That's great. The only code you will ever write in the future is business logic. Yeah, I might have heard that one before about 15 other technologies dating back to the 60s, but okay.

And the expectation was that it was going to take off and set the world on fire. You just needed to learn the constraints of how this worked. And there were a bunch of them, and they were obnoxious, and it didn't have a learning curve so much as a learning cliff. And nowadays, we do see it everywhere, but it's also in small doses. It's mostly used as digital spackle to plaster over the gaps between various AWS services. What I'm not seeing across the board is a radical mindset shift in the way that developers are engaging with cloud platforms that would be heralded by widespread adoption of serverless principles.

That said, we are on the heels here of Google Cloud Next, and you had a bunch of serverless announcements. I'm going to go out on a limb and guess you might not agree with my dismal take on the whole serverless side of the world. Well, I think this is a great question because despite the fact that I like not to, you know, be wishy-washy about anything, I actually both agree and disagree with what you said. And that's funny. That's why we're talking about this here instead of on Twitter, where two contradictory things can't possibly both be true.

Wow, imagine that nuance. It doesn't fit. 280 characters. Please continue. So what I agree with is that I agree with you that the former definition of serverless and the constrained way that we are conditioned to thinking about serverless is not as expansive as originally hoped from an adoption perspective. And I think that at Google, serverless is just no longer about only event-driven programming or microservices. It's about running complex workloads at scale while still preserving the delightful developer

experience. And this is where the connection to the developer experience comes in. Because the developer experience is about, in my mind, it's about time to value. How quickly can I achieve the outcome that I need for my business? And what are the things that get in the way of that? Well, setting up infrastructure gets in the way of that. Having to scale infrastructure gets in the way of that. Having the scale infrastructure gets in the way of that. Having to debug pieces that aren't actually related to the outcome that you're trying to get to gets in the way of that. And the beauty of serverless, it's all in how you define serverless. What does this name actually mean? If serverless only means functions and event-driven applications,

then yes, actually it has a better developer experience, but it is not expansive and then it is limited and it's trapped in its skin the way that you mentioned it. And it doesn't lend itself very well to legacy applications. Legacy, of course, being condescending engineering speak for it makes money. But yeah, that's the stuff that powers the world. We're not going to be redoing all those things as serverless powered microservices anytime soon in most cases. At Google Cloud, we are redefining serverless. And so what we are taking from serverless is the delightful user experience and the fact that you don't have to manage the infrastructure. And what we're putting into serverless is essentially serverless containers. And this is the big revolution in serverless is that serverless, at least at Google Cloud,

with serverless containers and our Cloud Run offering is able to run much bigger varieties of applications. And we are seeing large enterprises running legacy applications, like you say, on Cloud Run, which is serverless from a developer experience perspective. There is no cluster, there is no server, there's no VM, there's nothing for you to setless from a developer experience perspective. There is no cluster. There is no server. There is no VM. There is nothing for you to set up from a scaling perspective. And it essentially scales infinitely. And it is very developer focused.

It's meant for the developer, not for the operator or the infrastructure admin. In reality, in enterprise, there is very much a segmentation of roles. And even in smaller companies, there's a segmentation of roles, even within the same person, like they may have to do some infrastructure work and they may do some development work. And what serverless, at least in the context of Google Cloud does, is it removes the infrastructure work and maximizes the development work so that you can focus on your application. You can get to that end result, that business value that you're trying to achieve. And with Cloud Run, what we've done is we've preserved that and I would say actually arguably improved that because we've done usability studies that show that we're 22 points above every other serverless offering from a usability perspective.

So it's super important to me that anybody can use this service. Anybody, maybe even not a developer, can use this service. And that's where our focus is. And then what we've done underneath is we've removed many of the restrictions that are traditionally associated with serverless. So it doesn't have to be event-driven. It is not only a particular set of languages or a particular set of runtimes. It is not only stateless applications. And it's not only request-based billing.

It's not only short-running jobs. These are the kind of things that we have removed. And I think we've just redefined serverless. It's fun. On some level, the idea of short-lived functions with a maximum cap feels like a lazy answer to one of the hard problems in computer science, the halting problem. For those not familiar, my understanding of it is, okay, you have a program that's running in a loop. How do you deterministically say that it is done executing? And the function answer to that is, oh, after 15 minutes, it's done. We're killing it, which I guess is an answer, but probably not one that's

going to get anyone a PhD. It becomes very prescriptive and it leads to really weird patterns trying to work around some of those limitations. And historically, yeah, by working within the constraints of the platform, it works super well. What interests me about Cloud Run is that it doesn't seem to have many of those constraints in quite the same way. It's, can you shove whatever monstrosity you've got into a container? You can't? Well, okay, there are ways to get there. Full disclosure, I was very anti-container. The industry has yet again proven to me that I cannot predict the future. Here we are. Great.

Can you shove a container in and hand it to some other place to run it where, spoiler, people will argue with me on this and they are wrong. Google engineers are better at running infrastructure to run containers than you are. Full stop. That is the truism of how this works. Economies of scale. I love the idea of being able to take something, throw it over a wall, and not have to think about the rest of it.

But everything that I'm thinking about in this context looks certain ways. And it's the type of application that I'm working on or that I'm looking at most recently. What are you seeing on Cloud Run as far as interesting customer use cases. What are people doing with it that you didn't expect them to? Yeah, I think this is a great time to ask that question because with the pandemic last year, I guess we're still in the pandemic, but with the pandemic, we had developers all over the world become much more important and much more empowered just because there wasn't really much of an operations team. There wasn't really as much coordination even possible. And so we saw a lot of customers, a lot of developers moving to cloud, and they were looking for the easiest thing that they could use to build their applications.

And as a result, serverless and Cloud Run in particular became extremely popular. I would say hockey stick in terms of usage. And we're seeing everything under the sun. Ecobee, this is a home automation company that makes smart thermostats. They're using Cloud Run to launch a new camera product with multi-factor authentication and security built in. And they had a very tight launch timeline. They were able to very quickly meet that need. Another company, and you talk about, you know, sort of brick and mortar, IKEA, which you and I all like to shop at, particularly during the... Oh, I love building something from 500 spare parts badly. It's like basically bringing

my AWS architecture experience into my living room. The Swedish puzzle manufacturer. Yes, they're a great company. And I think just in the downturn and the lockdown, it was actually a very dicey time, very tricky time, particularly for retailers. Of course, everybody was refurbishing their home or, you know, improving their home environment and their furniture. And IKEA started using serverless containers along with serverless analytics. So with BigQuery and Cloud Run and Cloud Functions. And one of the things they did is that they were able to cut their inventory refresh rate from more than three hours to less than three minutes. This meant that when you were going to drive up and do some curbside pickup, the order that you placed was actually in stock, which is fantastic for CSAT and everything.

But that's the kind of the technical piece that they were able to do. When I spoke with them, the other thing that they were able to do with Cloud Run and Cloud Functions is that they were able to improve the work-life balance of their engineers, which I thought was maybe the biggest accomplishment. Because the platform, they said, was so easy for them to use and so easy for them to accomplish what they needed to accomplish that they had a better life. And I think that that's very meaningful. Another company is MediaMarket Saturn. We've talked about them before. I don't know if I've spoken to you about them, but we've certainly talked about them publicly. They're a retailer

in EMEA. And because of their use of Cloud Run, they were able to combine the speed of serverless with the flexibility of containers. And their development team was able to go eight times faster while handling 145% increase in digital channel traffic. Again, there are a lot more digital channel traffic during COVID. And perhaps my favorite example is the COVID-19 exposure notifications work that we did with Apple. An unfortunate example, but a useful one. I think we all wish it wasn't necessary, but here's the world in which we live. Please tell me more. I have so many friends in engineering and mathematics and these technical fields, and

they're always looking at ways that technology can solve these problems. And I think especially something like the pandemic, which is so difficult to track, so difficult with the time that it takes for this virus to incubate and so on, so difficult to track these exposures using the smartphone, using Bluetooth to have a record of who has it and who they've been in contact with. I think really interesting engineering problem, really interesting human problem. So we were able to work on that. And of course, when you need a platform that's going to be easy to use, that's going to be something that you can put into production quickly, you're going to use Cloud Run. So they use Cloud Run and they also use Cloud Run for Anthos, which is the more hybrid version for the on-prem piece. And so both of those

were used in conjunction to back all of the services that were used in the notifications work. So those are some of the examples. I think net-net, it's that I think usability, especially in enterprise software, is extremely important. And I think that's the direction in which software development is going. Here at the Duckbill Group, one of the things we do with, you know, my day job is we help negotiate AWS contracts. We just recently crossed $5 billion of contract value negotiated. It solves for fun problems such as how do you know that your contract that you have with AWS is the best deal you can get? How do you know you're not leaving money on the table? How do you know that you're not doing what I do on this podcast and on Twitter constantly and sticking your foot in your mouth? To learn more,

come chat at duckbillgroup.com. Optionally, I will also do podcast voice when we talk about it. Again, that's duckbillgroup.com. It's easy for me to watch folks like you in keynotes at events like Cloud Next talk about things and say, this is how the world is building things, and this is what the future looks like, and I can sit there and pick that pieces all day, every day. It's basically what I do because of deep-seated personality problems with me. It's very different to say that about a customer who has then taken that thing and built it into something that is transformative and solves a very real problem that they have. I may not relate to that problem that they have, but I do not believe that customers are going to

have certain problems, find solutions like this that fix them, and be wrong in how they're approaching these things. No one sees the constraints that shape things. No one shows up in the morning hoping to do a crap job today unless, you know, you're the VP of integrity at Facebook or something. But there's a very real sense of companies have a bunch of different drivers, and having a tool or a service or a platform that solves it for them, you'd better be very sure before you step up and start saying, no, you're doing it wrong. In earlier years, I did not see a whole lot of customer involvement with Cloud Next. It was always a, well, a bunch of Googlers

are going to tell me how this stuff works, and they'll talk about theoretical things. That's not the case anymore. You have a whole bunch of highly respectable reference customers out there doing a whole lot of really interesting things. And more to the point, they're willing to go on record talking about this. And I'm not talking about fun startups that are great. It's Twitter only for pets. Great.

I'm talking banks, companies wherein mistakes are going to show and leave a mark. It's really hard to reconcile what I'm seeing with Google Cloud in 2021 than what I was seeing in, let's say, five or six years ago. What drove that change? Yes, Corey, I think you're definitely correct about that. There's no doubt about it, that we have a number of really tremendous customers, really tremendous enterprise

references, and so on. I run the Google Cloud Developer Platform. And for me, the developers that I work with and the developers that this platform serves are the inspiration for what we do. And in the last six or seven years that I've worked in Google Cloud, that has always been the case. So nothing has changed from my perspective in that regard. If anything, what has changed is that we have far more users, we have been growing exponentially, and we have many more large enterprise customers. But in terms of my journey, you know, I started with the Kubernetes open source project, I was one of the very early people on that. And I was working with a lot of developers in that case, in the open source community, a lot of them became GKE customers, and it just grew. And now we have so many customers

and so many developers and we have developed this platform with them. We have very much, it's been a matter of co-innovation, you know, especially on Kubernetes. It has been very much, okay, you tell us, and it's a need-based relationship, you know, something is not working. We are there and we fix it. You know, going back to 2017 or whenever it was that Pokemon Go was running on GKE, you know, that was a moment when we realized, oh, this platform needs to scale. Okay, let's get at it. And that's where, you know, Cori really helps to have great engineers. For all the pros and cons, I think that's where you want those super sharp, super driven, super intelligent

folks because they can make things like that happen. They can make it happen in less than a week so that they can make it happen over a Saturday so that Pokemon Go can go live in Japan and everybody can be playing that game. And that's what inspires me. And that's a game, but we have a lot of customers that are running health applications where we have a customer that's running ambulances on the platform. And so this is life threatening stuff. We have to take that very seriously. And we have to be listening to them and working with them. But I'm, I'm inspired. And I think that our roadmap and the products and the features that we build are inspired by what they're building on the platform. And they're combining all kinds of different things. They're taking our machine learning capabilities, they're taking our analytics capabilities,

they're taking our maps API, and they're combining it with Cloud Run, they're combining it with GKE. Often they're using both of those. And they're running new services. We've got a customer in Indonesia that's running a food delivery service. I've got customers that are analyzing the corn fields in the middle of the country to improve crop yield. So that's the kind of inspiring work. And each of those, Corey, each of those users are coming back to us and saying, oh, you know, I need a different type of, it's very detailed, like I need a different type of file system that gives me, you know, greater speed or better performance. We just had a gaming company that was running on GKE that we really

won out over a different cloud in terms of performance improvements that we were able to provide on the container startup times. It was just a significant performance improvement. We'll probably publish it in the coming few months. That's the kind of thing that drives it. And I'm very glad that I have a strong engineering team in Google Cloud. And I'm very glad that we have these amazing customers that are trying to do these amazing things and that they're directly engaging with us and telling us what they need from us, because that's what we're here for. To that end, one more area I want to go into before we call this a show. You've had Cloud Build for a little while, and that's great. Now at hot off the presses, you wound up effectively taking that one step further with cloud deploy. And I am still mostly as someone with terrible

build and release practices that people would be ashamed of, struggle to understand the differentiation between what I would do with cloud build and what I would do with cloud deploy. I understand they're both serverless. I understand that they are things that large companies care about. What is the story there? It's a journey. As you start to use containers, and these days, like you said, Corey, containers, a lot of people are using them. Then you start to have a lot of microservices. And one of the benefits of container usage is that it's really quick to release new versions, right? You can have different versions of your application. You can test them out. You can roll them out. And so these DevOps practices, they become much more attainable, much more reachable. And, you know, we just put out the, I think the seventh version of the DevOps

research report, the DORA report that shows that customers that follow best practices, you know, they achieve their results two times better in terms of business outcomes and so on. And there's many metrics that show that this kind of thing is important. But I think the most important thing I learned during the pandemic as we were coming out of the pandemic is a lot of, and you mentioned enterprises, large banks, large companies, CIOs and CEOs who basically were not prepared for the lockdown, not prepared for the fact that people aren't going to be going into branches, they came to Google Cloud and they said that, I wish that I had implemented DevOps practices. I wish that I had implemented the capability to roll out changes frequently because I need that now. I need to be able to experiment with a new banking application that's mobile only. I need to be able to experiment with

curbside delivery. And I'm much more dependent on the software than I used to be. And I wish that I had put those DevOps practices. And so at the beginning of 2021, all our conversations were with customers, especially those, you know, you said legacy. I don't think that's the right word, but the traditional companies that have been around for hundreds of years, all of them, they said software is much more important. Yes, if I'm not a software company, at least a large division of my group is now a software group. And I want to put the DevOps practices into play because I know that I need that.

And that's a better way of working. By the way, there's a security aspect to that that I'd like to come back to because it's really important, especially in banking, financial services and public sector, as you move to a more agile DevOps workflow to have security built into that. So let me come back to that. But with regard to cloud build and cloud deploy, cloud deploy is something I've been wanting to bring into market for a couple of years. We've been talking about it. We've been working on it actively for more than a year on my team. And I'm very, very excited about this service because what it does is it allows you to essentially put this practice, this DevOps practice into play where as your artifacts are built and stored in the artifact repository, they can then automatically be deployed into your

runtime, which is GKE Cloud Run in the future. You can deploy them and you can set how you want to deploy them. Do you want to deploy them to a particular environment that you want to designate the test environment, the environment to which your developers have access in a certain way? It's a test environment, so they can make a lot of changes. And then when do you want to graduate from test to staging? And when do you want to graduate to production and do that gradual rollout? Those are some of the things that Cloud Deploy does. And I think it's high time because how do you manage microservices at scale? How do you really take advantage of container-based development is through this type of tooling.

And that's what Cloud Deploy does. It's just the beginning of that, but it's a delightful product. I've been playing around with it. I love it. And we've seen just jobs that don't include the word security, but need to care about it. That's why I have a Thursday edition of my newsletter now talking specifically about that. What is the story around security these days from your perspective? And again, it's a huge overall topic. And let's be clear, I'm not asking, what does Google Cloud think about security?

That would fill an encyclopedia. What is your take on it? Where do you want to talk about this in the context of cloud deploy? Yeah, so I think about security from the perspective of the Google Cloud Developer Platform, and specifically from the perspective of the developer. And like you said, security is not often in the title of anybody in the developer organization. So how do we make it seamless? How do we make it such that security is something that is not going to catch you as you're doing your development? That's the critical piece. And at the same time, one of the things we saw during 2020 and 2021 is just the number of software supply chain attacks. These are attacks where some malicious hacker has come in and inserted some malicious code into your software. Your software, Corey, you know, you, the unsuspecting developer.

Well, it used to be my software. Now there's some debate about that. Right. That's true because most software is using open source dependencies and these open source dependencies, they have a pretty intricate web of dependencies that they are themselves using. So it's a transitive problem where you're using a language like Python or whatever language you're using. And there's a number of... Crappy bash by default, but yes. Well, it was actually a bash script vulnerability, I think, in the CodeCov breach that happened, I think it was earlier this year, where a malicious bash script was injected into the build system, in fact, of CodeCov. And there are all these new attack vectors that are specifically targeting developers. And, you know, whether it's nation states or whoever it is that's causing some of these attacks, it's a problem that is of national and international magnitude. And so I'm really excited

that we have the expertise in Google Cloud and beyond Google Cloud and Google, it's a very security conscious company. This company is a very security conscious company and we have built a lot of tooling internally to avoid those kinds of attacks. So what we've done with Cloud Build and what we're going to do with Cloud Deploy, we're building in the capability for code to be

signed, for artifacts to be signed with cryptographic keys, and for that signing, that attestation, we call it an attestation, that attestation to be checked at various points along the software supply chain. So as you're writing code, as you're submitting the code, as you're building the containers, as you're storing the containers, and then finally, as you're deploying them into whatever environment you're deploying them, we check these keys and we make sure that the software that is going through the system is actually what you intended and that there isn't this malicious code injection that's taking place. And also we scan the software, we scan the code, we scan the artifacts to check for vulnerabilities, known vulnerabilities, as well as unknown vulnerabilities,

known vulnerabilities from a Google perspective. So Google is always a little bit ahead, I would say, in terms of knowing what the vulnerabilities are out there, because we do work so much on software across operating systems and programming languages, just across the full gamut of software in the industry. We work on it and we are constantly securing software. So we check for those vulnerabilities. We alert you. We help to remediate those vulnerabilities. Those are the type of things that we're doing. And it's all in service of certainly keeping enterprise developers secure, but also just long tail and average everybody helping them to be secure so that they don't get hacked and their companies don't get hacked. It's nice to see people talking about this stuff

who is not directly a security vendor, by which I mean you're not using this as the fear, uncertainty, and doubt angle to sell a given service that we have to talk about this exploit because otherwise no one will ever buy this. Something like cloud deploy is very much aligned with a best practices approach to release engineering. It's not, strictly speaking, a security product, but being able to wrap things that are very security-centric around it is valuable. Now, sponsors are always going to do interesting things at various expo halls and, oh yeah, sell the same product warmed over. This is very much not that. And I don't interpret anything you're saying as trying to sell something via the fear, uncertainty, and doubt model. There are a lot of different areas that I will be skeptical

hearing about from different companies. I do take security words from Google extremely seriously because let's be clear, in the past 20, however many years it has been, you have established that is a clear track record for caring about these things. Yeah. And I'd go back to my initial mission statement, which is to help developers accelerate time to value. And one of the things that will certainly get in the way of accelerating time to value is security breaches by the nature of them. If you are not running a supply chain that is secure, then it is very difficult for you to empower your developers to do those releases frequently and to update the software frequently because what if the update has an issue? What if the update has a security vulnerability, right? That's why it's

really important to have a tool chain that prevents against that, that checks for those things, that logs those things so that there's an audit trail available and that has the capability for your security team to set policies to avoid those kinds of things. I think that's how you get speed. You get speed with security built in, and that's extremely important to developers and especially cloud developers. I want to thank you for taking the time to speak to me about all the things that you've been working on

and how you view this industry unfolding. If people want to learn more about what you're up to and how you think about these things, where can they find you? Well, Corey, I'm available on Twitter and that may be one of the best ways to reach me. I'm also available at various customer events that we are having.

Most of them are online now. And so I'll provide you more details on that and I can be reached that way. Excellent. We'll, of course, include links to that in the show notes. Thank you so much for being so generous with your time. I appreciate it. Thank you so much. I greatly enjoyed speaking with you.

Aperna Sinha, Director of Product Management at Google Cloud. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. And that sentence needed the word cloud about four more times in it. If you've enjoyed this episode, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a loud, angry comment telling me that I just don't understand serverless well enough.