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 right.
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.
Uh, 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 team, 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, 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 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.
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 know, you said it's not that
common to find a good user experience in 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.
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 Stripes Patrick
McKenzie who wound up pointing this out originally though, but
the internet is big and people always share and re share 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 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, uh, 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 excellent team.
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 skillset.
And so I know you said that you're not super impressed with our
consumer products, but I And 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.
Yeah, again, like 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 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.
You know, 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 easier.
For them.
If I had to bet on a company not understanding that distinction
on some level, like Google's reputation lends itself to that.
Where, oh, great, if 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 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've 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 in 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, you know, 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 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, 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.
Well, so we're talking about this here instead of on Twitter, where two
contradictory things can't possibly both be true with, 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 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, you know,
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 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 the 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, you know.
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 containers.
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 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, they may do some development work.
And what serverless is, At least in the context of Google Cloud
does is it removes the infrastructure work and maximizes the
development work so that you could 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 improve 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.
Thanks.
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 blogman's understanding
of it is, okay, you have a, 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, those, 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 that 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, you know, 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, better life.
And I think that that's very meaningful.
Another company is MediaMarketSaturn.
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.
And 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 a 145 percent 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.
We all 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.
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 five billion dollars 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, very easy.
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 then 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, you know,
they can make it happen over a Saturday so that Pokémon 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.
I think that our road map 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.
You know, we've got a customer in Indonesia
that's running, you know, 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, you know, greater speed or better performance.
We just had a gaming company that was running on GKE that we really won
out over, 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, but 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, uh, 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 three.
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 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, you know, 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 that 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.
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 is 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 cloud security?
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?
And 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.
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 cyber attacks.
It just went through the roof.
I think there was a 400 to 600 percent 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, your
software, Corey, you know, you, the unsuspecting developer,
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
Copy 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, you know, 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 To avoid those kinds of attacks.
So what we've done with cloud build and what we're doing with 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 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.
Sponsors are always going to do interesting things at various
expo halls and, oh yeah, sell the same product, uh, warmed over.
This is very much not that, and I, 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 it as 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.
Aparna
Sinha, Director of Product Management at Google Cloud.
I'm Cloud Economist Corey Quinn, and this is 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 5
star review on your podcast platform of choice.
Whereas if you hated this podcast, please leave a 5 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.