Building a User-Friendly Product with Aparna Sinha

Aparna Sinha is Director of Product for Kubernetes and Anthos at Google Cloud. Her teams are focused on transforming the way we work through innovation in platforms. Before Anthos and Kubernetes, Aparna worked on the Android platform. She joined Google from NetApp where she was Director of Product for storage automation and private cloud. Prior to NetApp, Aparna was a leader in McKinsey and Company’s business transformation office working with CXOs on IT strategy, pricing, and M&A. Aparna holds a PhD in Electrical Engineering from Stanford and has authored several technical publications. She serves on the Governing Board of the Cloud Native Computing Foundation (CNCF).

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

Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you’re tired of managing open source Redis on your own, or you’re using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. Set up a meeting with a Redis expert during re:Invent, and you’ll not only learn how you can become a Redis hero, but also have a chance to win some fun and exciting prizes. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.  

Corey: You know how Git works right?

Announcer: Sorta, kinda, not really. Please ask someone else.

Corey: That's all of us. Git is how we build things, and Netlify is one of the best ways I’ve found to build those things quickly for the web. Netlify’s Git-based workflows mean you don’t have to play slap-and-tickle with integrating arcane nonsense and web hooks, which are themselves about as well understood as Git. Give them a try and see what folks ranging from my fake Twitter for Pets startup, to global Fortune 2000 companies are raving about. If you end up talking to them—because you don’t have to; they get why self-service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y dot com.

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

Aparna: Thank you, Corey. It’s a pleasure to be here.

Corey: So, Director of Product Management is one of those interesting titles. We’ve had a repeat guest here, Director of Outbound Product Management Richard Seroter, 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 the 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.

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

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

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

Corey: 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.” Turns out there might be additional steps required.

Aparna: 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 said it’s not that common to find a good user experience in the cloud, I think in general—you know, 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… pretty bad. Just a list of things.

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

Aparna: 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; you can move between consumer and cloud. There’s no 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 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 multi-functional—meaning across product—user experience and engineering. We have end-developer relations. We have, sort of this four-way communication about—you know, 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.

Corey: 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. It’s like, 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 get an 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?

Aparna: Oh, absolutely not. I think we would be in trouble if we did that. I studied electrical engineering in school. This would be like 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 an 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; 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.

Corey: “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 that 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 serverless side of the world?

Aparna: Well, I think this is a great question because despite the fact that I like not to be wishy-washy about anything, I actually both agree and disagree [laugh] with what you said. And that’s funny.

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

Aparna: 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 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, 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 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. [laugh].

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

Aparna: 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 in the serverless is essentially serverless containers. And this is the big revolution in serverless, is that serverless—at least a 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’s no cluster, there is no server, there’s no VM, there’s 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 and 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 kinds of things that we have removed and I think we’ve just redefined serverless.

Corey: [unintelligible 00:17:05], 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 layman’s 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 functional 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 in Cloud Run as far as interesting customer use cases? What are people doing with it that you didn’t expect them to?

Aparna: 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 [laugh] at, particularly doing the—

Corey: Oh, I love building something from 500 spare parts, badly. It’s like basically bringing my AWS architecture experience into my living room. It’s great. Please continue.

Aparna: Yeah, it’s like, yeah—

Corey: The Swedish puzzle manufacturer.

Aparna: Yes. They’re a great company, and I think it 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 [laugh], 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, you know the order that you placed was actually in stock, which was fantastic for CSAT and everything.

But that’s the technical piece that they were able to do. When I spoke with them, the other thing that they were able to do with the 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 [laugh] better life. And I think that’s very meaningful.

In other companies, MediaMarktSaturn, 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, and 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.

Corey: An unfortunate example, but a useful one. I—

Aparna: Yes.

Corey: —we all—I think we all wish it wasn’t necessary, but here’s the world in which we live. Please, tell me more.

Aparna: 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 used Cloud Run, and they also used 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.

Corey: Are you building cloud applications with a distributed team? Check out Teleport, an open source identity-aware access proxy for cloud resources. Teleport provides secure access to anything running somewhere behind NAT: SSH servers, Kubernetes clusters, internal web apps and databases. Teleport gives engineers superpowers!

Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility and ensuring compliance. And best of all, Teleport is open source and a pleasure to use.

Download Teleport at https://goteleport.com. That’s goteleport.com.

Corey: 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 to pieces all day, every day. It 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 and fix them, and the 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 where 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?

Aparna: 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, we 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, 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 [laugh] customers and so many developers, and we have developed this platform with them. We are very much—it’s been a matter of co-innovation, 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.

Going back to 2017 or whenever it was that Pokemon Go was running on GKE, that was a moment when we realized, “Oh, this platform needs to scale. Okay, let’s get at it.” And that’s where, Corey, it 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. 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 inspired, and I think that our roadmap, and the products, and the features that we build are inspired by what they are 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 in a food delivery service; I’ve got customers that are analyzing the cornfields in the middle of the country to improve crop yield. So, that’s the kind of inspiring work, and each of those core, 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 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.

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

Aparna: Yeah, 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. 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 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, 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 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 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 is something I’ve been wanting to bring into market for a couple of years. And 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 whereas 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? Like, 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 tremendous reception from our users.

Corey: I’m looking forward to kicking the tires on it myself. I want to circle back to talk about the security aspect of it. Increasingly, I’m spending more of my attention looking at cloud security because everyone else has, too, and some of us have 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 here, I’m not asking, “What does Google Cloud think about security?” That would fill an encyclopedia. What is your take on it? And where do you want to talk about this in the context of Cloud Deploy?

Aparna: 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 cyberattacks just went through the roof. I think there was a 400 to 600% increase in 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. [laugh]. Your software, Corey. You know, you the unsuspecting developer is—

Corey: Well, it used to be my software; now there’s some debate about that.

Aparna: 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—

Corey: Crappy bash by default. But yes.

Aparna: Well, it was actually a bash script vulnerability, I think, in the Codecov breach that happened, I think it was, in 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 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.

Google, it’s a very security-conscious company. This company is a very security-conscious company. [laugh]. 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’s 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 longtail an average, everybody, helping them to be secure so that they don’t get hacked and their companies don’t get hacked.

Corey: It’s nice to see people talking about this stuff, who is not directly a security vendor. But 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, saw the same product warmed over. This is very much not that, and I don’t interpret anything you’re saying is 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 a clear track record for caring about these things.

Aparna: Yeah. And I have to 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?

That’s why it’s really important to have a toolchain 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 with security built in, and that’s extremely important to developers and especially cloud developers.

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

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

Corey: Excellent. I will, of course, include links to that in the [show notes 00:38:43]. Thank you so much for being so generous with your time. I appreciate it.

Aparna: Thank you so much. I greatly enjoyed speaking with you.

Corey: Aparna 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. And if you’ve enjoyed this episode, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with a loud angry comment telling me that I just don’t understand serverless well enough.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.