Google Cloud Run is a few years old now, and in this RedMonk Conversation, James Governor sits down with one of its founders, Steren Giannini, to talk through its origins and future. Back in 2017, most people assumed serverless meant functions. Steren’s team disagreed. They figured the real value of serverless was simplicity, scale, and paying only for what you actually use, and that the thing you deploy should be a container, not a function. That call ended up shaping the whole product. James and Steren get into the decisions that gave Cloud Run its longevity: staying opinionated about simplicity without boxing developers in, a Kubernetes-compatible API designed so you can walk away whenever you want, and an open debt to Heroku’s git-push experience. Steren is also honest about the messier parts, from fighting feature creep, to building the enterprise networking and security that big customers needed, to handling the traffic that AI agents are now generating. Looking ahead, Steren argues that the next generation of developers might be anyone who can describe an app in a prompt and hit publish.

Google is a RedMonk client, but this is an independent piece of content.

Links

• LinkedIn: Steren Giannini

Transcript

James Governor (00:04)
Hey, this is James Governor from RedMonk. I’m here with Steren Giannini from Google Cloud. And the topic of conversation today is Google Cloud Run. I think it’s a really interesting platform. You know, I actually remember when it was introduced and I thought to myself, you know what, I would really like a podcast which functions as a bit of a deep dive on the original design thinking and the engineering decisions behind.

Cloud Run. And obviously we’re a few years in now. So what have we learned? And I think one of the things that we do see at the moment in technology is of course tech that may not have been built with AI in mind may in fact prove to be rather useful as we deploy AI agent and LLM workloads. So, Steren, who are you?

Who are you to tell us the story of Cloud Run?

Steren Giannini (01:08)
Hi, James. Thanks for having me. So I’m a Director of Product Management at Google. But more importantly for that conversation, I’m one of the founders of Google Cloud Run. One of the few people at the beginning who started to ask, hey, what if we brought serverless and containers together? Let’s reimagine something from first principles. So yeah, I’ve been on this since 2017.

and leading the product, seeing it grow from a prototype to something that Google Cloud really stood behind, to something that is very popular today.

James Governor (01:46)
Mm-hmm. And tell me a bit about that sort of, those original design decisions, like what were some of the reasons, I guess, what do you think some of the reasons, some of the choices you made, why have they led to longevity? Why have they led to being a product that sort of hit the mark and has shown consistent value over time?

Steren Giannini (02:12)
So first, that’s an excellent question. we have been, I would say, walking that fine line of opinionation. Like, you want to be opinionated so that you make developers more productive. You offer a simple product. But you don’t want to be too opinionated, because otherwise you end up having opinions which might not fit the market. So Cloud Run has been…

You know, as an example, at the time when we designed Cloud Run, it was all about serverless equal functions. We questioned that. We said, well, you know, what is the essence of serverless? It’s simplicity, scalability, cost efficiency, but it doesn’t have to be functions. And at the time, it was dominated by products like AWS Lambda and Google Cloud Functions. And we were, okay, let’s turn back. At the same time, there was this thing called Kubernetes.

and containers happening, and we like, what if we actually discarded the notion of serverless equal function and said, you know, let’s accept any workload, any containerized workload, which is how Cloud Run was originally born. It was let’s reinvent serverless taking containers as the deployment primitive. So in a sense, we were not too opinionated regarding what you could deploy.

But we were opinionated regarding how simple it has to be, it had to be, and the overall product experience. It was one command to deploy your container to Google Cloud, while previously you had to think about clusters and pods and things like that, because there was only Kubernetes. So we were opinionated to make that simpler, both in terms of experience and in terms of runtime. It’s a hyperscalable runtime. At launch, we

the demo where we went from 0 to 10,000 containers in 10 seconds. So that was an opinionated way to scale containers at a scale that we had rarely seen before for a container runtime. But at the same time, being flexible.

So on the design principles that we can still look up on my original document, you can see things like simplicity, but also openness. And at the time, we really wanted to address a big criticism of serverless, which was the lock-in. We had been operating Google App Engine for quite a while since 2008. Yeah.

James Governor (04:52)
I was going to ask about that because I do think that’s one of the questions, is, is that, you know, there was some, there was some prior art and, you know, questions about how to get people to adopt a platform of this kind, which takes so much of the manageability away. Then where do you express that opinion that, that, that, that, that allows the openness? think that’s really critical because we saw with with App Engine or Elastic Beanstalk at AWS, it’s actually really difficult to get people on board with this sort of approach. So yeah, now I’m really untrusted in that question.

Steren Giannini (05:34)
So it was open. We wanted to be open and portable, because that’s to address the big criticism we had heard on Google App Engine and later on Google Cloud Functions. Those two products required you to write your code in a certain way.

And when you adopted those products, you adopted proprietary bespoke packaging format as well as APIs. So with Cloud Run we took that from the beginning. are one. will be like the industry seems to have converged towards the container image as the universal packaging format for software. Let’s take that as the core deployment artifact.

And on top of that, we actually did two things which in retrospect were maybe nice to have, but we are very glad we have them. One is that the Cloud Run API actually is compatible with Kubernetes API, even though it is absolutely not implemented on top of Kubernetes. When you look at it, when you look at the Cloud Run YAML and you know Kubernetes, it looks a lot like Kubernetes. You have the same attributes, the same API structure, the same way of being declarative and

and having a spec. So we did that also to enable portability so that if you don’t stay on Cloud Run because you are locked in.

You stay because you can leave at any time, but you love it, and that’s why you stay. So I think we delivered on that promise. We also had an open source strategy at the beginning, which really helped at launch create a very strong narrative of openness.

James Governor (07:19)
Tell me more about the open source strategy.

Steren Giannini (07:23)
Yeah, we based on the success of products like Kubernetes and Istio in order to address the lock-in concern that we had heard of offering a serverless product, we actually originally invested into something called Knative, which was an open source product that implemented the exact same.

API as Cloud Run, except that you could run it on your own cluster. So at launch, we had Cloud Run implemented on Borg. It was fully managed. Actually, it takes some technology from what we had developed from Google App Engine, Google Cloud Functions. And we had this version.

James Governor (07:51)
Mm-hmm.

Steren Giannini (08:10)
And then we had an open source version called Knative. At launch, they implemented the exact same feature sets that you could deploy on Google Kubernetes Engine, but also as we’ve demoed on other clouds, on your own clusters. So that kind of alleviated the lock-in concern from the start. First containers, which, honestly, the fact that we took containers probably gave us like 80 % of the portability.

Because the control plane, the API is not the hard thing to translate. Especially now you can just ask an AI to translate your Cloud Run to Terraform config, for example. at the time, the container already gave us 80 % of the portability. And then you add the additional, I would say, 15 % thanks to the API portability as well as the open source project.

But to be very clear, Google Cloud Run is not running this open source product, Knative. Google Cloud Run is not running on a managed Kubernetes cluster. It is actually running on a highly efficient multi-tenant serverless infrastructure which takes its roots from App Engine, which was evolved in order to create Google Cloud Functions. And the story is interesting because…

When I joined the team, we just had launched Google Cloud Functions. And I realized, hold on, because to achieve that launch, we actually built a technology that allowed us to run unmodified runtimes in our serverless infrastructure. Because back in the day of App Engine,

James Governor (09:47)
Okay.

Steren Giannini (09:49)
we had to, for every Python version we wanted to release, we had to modify it so that it was securely isolating customers’ applications. We went into a fundamental investment to be able to run any runtime. So that’s why Cloud Functions, when it launched, had Node, but quickly later added Java, Ruby, Python. And that technology actually is the technology that was developed.

to run any container, but we were only using it to run functions in a set of languages. So when I joined the team and when we saw that, we were, what if we actually leveraged that technology to fundamentally offer a container product, container-first product? So that was the foundation. At the time, Cloud Run was very simple.

You could only deploy container, you probably couldn’t even pick the number of CPU and RAM. At launch, we launched in one region, while today we are in 50 and you have many, many other options. But this simplicity allowed us to focus on delivering a well-crafted product. Because that’s something else we can probably talk about. Yes, we had principles like openness and…

simplicity but like it’s really like there are a lot more design principles that went into Cloud Run. You we wanted it to be well crafted, we wanted it to be consistent across its surfaces so if you use YAML, CLI, UI you can access the same features and a lot of product design went into how do we keep common use cases extremely simple.

And for the least common use cases, the ones that are more advanced, potentially the more enterprisey ones, how do we allow ourselves to have more clicks, more commands? But definitely the 80 % of the use cases had to be very simple. So that’s why it was one command to deploy your container at launch.

James Governor (11:49)
Yeah.

Were there any other, from that design perspective, there any sort of touchstones around perhaps other products that you thought had done it well? Or maybe not even in tech, maybe it was, or at least not in enterprise or cloud technology. There might be, yeah, I’m untrusted, were there any sort of like, wouldn’t it be great if it could offer this kind of experience?

Steren Giannini (12:22)
Yeah, I I think in terms of design principle, that goes beyond tech. Like one principle I like to use is progressive complexity, where when you learn about something, the cognitive load should be as low as possible, and it should be as familiar as possible so that you can start onboarding onto it. So that’s a nice and interesting story for employees.

or in the early days of Cloud Run and Knative, we did not have this obvious Cloud Run service object. It was actually a much more complex resource model. And then we realized, no, we need to simplify. We need people to think about one box instead of having to think about three boxes. There was many, many complex boxes. Like when you adopt Kubernetes, you have to learn about what is a deployment, what is a pod, what is a node.

James Governor (13:00)
Okay.

Yeah, absolutely. The first thing you

have to do is learn a lot.

Steren Giannini (13:20)
Exactly. So for us, we wanted to address that progressive complexity where you don’t have to learn anything. The only thing you have to learn, you are ideally already familiar with it and you just give it one thing, which was one container, and then you’re good to go.

So that was one example of a design principle that is not even coming from tech. You can apply progressive complexity to every kind of product design. But I think from tech, want to give shout outs to products like Heroku. Obviously, we are still…

James Governor (13:52)
Absolutely.

Steren Giannini (13:54)
We are still in admiration about how good Heroku was. It’s probably more than 10 years now, but it really nailed this radical, simple developer experience that was really… That’s another key principle that we used across the design process, was idiomatic. So what does idiomatic mean? It means we preferred to embrace developer standards than to invent or impose our own.

James Governor (14:14)
Mm-hmm.

Mm-hmm.

Steren Giannini (14:23)
So we prefer to embrace containers rather than to ask people to use our own packaging format. We prefer to embrace, like if you deploy Node.js, we are not going to be asking you to use our own config file. We are just going to be asking you to give us a package.json. So we try to apply this across the board. For every thing we want to introduce, like recently, much later, we introduced .env support. Because of course, if you want to declare your environment variables,

that should be .env. There’s no question about that. But at launch, we did not have this and we quickly added it later because it’s clearly one of those idiomatic developer standards. So there is being idiomatic. And here, think Heroku was extremely idiomatic with their support of git push. This is so nice. By the way, I never said that to anyone, but this is something only for you, I wanted the Cloud Run.

developer experience to be Docker push cloud dot run slash my project slash my service. It would have been so nice, right? To not even have a CLI, but to use the Docker CLI. The same way Heroku used the Git CLI to deploy. We ended up…

James Governor (15:26)
Yeah.

Well, it was so revolutionary.

Certainly from the Heroku’s standpoint, mean, you know, to the extent that as I’ve said this to people, the first time I saw Heroku, I didn’t understand when, well, I was working with the team that was building Doppler at the time, I think.

And I honestly didn’t understand that a deployment had happened. because in my mind I was still waiting for the next step and it had already been done with the push. And I think that was just really profound.

Steren Giannini (16:21)
and we were feeling the same.

Yes, it was such a nice design that, the same way you push your code to a branch, you would use the same, to just store your code in a repository, you would use the same action to deploy. That was kind of this beautiful moment. Of course, Heroku ended up implementing a deployment API later, as well as a command line. But I think fundamentally taking this idiomatic principle to the extreme with git push to deploy, which we added

very quickly after to Cloud Run 2. At launch, we were again focusing on a minimal viable product in order to deliver a well-crafted product and no bug. But we later introduced this connecting a Git repository so that when you push to a given branch, it deploys. By the way, if you are curious about this, how did we focus?

We really, I remember originally, we had a big, plans for what Cloud Run should be at launch. Because the idea was it was supposed to be what Cloud Functions did.

plus containers. That meant we had to support the entire scope of Cloud Functions, which had events and which had support for languages, not only with no Dockerfiles, so that you don’t even have to think about containers. But we quickly realized, okay, that was a big, big scope. In order for us to really deliver something that people would love at launch, we had to cut the scope. We really cut a lot. I think that was the right move, because

When you focus, you can actually spend more time on the quality. we spent, like probably when we launched publicly in April 2019, we had been already working with internal, with external testers for almost a year who helped us shape the product.

identify issue. You said you were following Cloud Run since the launch. I’m sad I did not invite you to that trusted tester list because we have people from that time who are still following and even in cloud run today. they are one of our every cloud next I’m very happy to meet the people who helped us shape Cloud Run when it was still in private preview.

James Governor (18:49)
Yeah.

Yeah, no, that’s,

That’s certainly an amazing feeling and I’m sure a lot, I mean, they’re still on the platform, right?

Steren Giannini (19:01)
Yes, most of them

really love it and even brought them into their companies, changed companies, so brought them into their other companies. it’s, you know, when Cloud Run is at the top of Google Cloud Satisfaction numbers, this is something we’ve been communicating already about for years now.

James Governor (19:17)
Well, shout about that a little bit because, you know, I was

at a Google event recently and obviously in a company, you know, I was at Cloud Next and with so many things to talk about in the agent world, I was like, come on, I want some Cloud Run, you know, I could do with some Cloud Run cheerleading. So maybe talk a bit about, yeah, I’d love you to go into that a little bit.

Steren Giannini (19:44)
So when you use the Cloud Console, the Google Cloud Console, you have those small pop-ups that pop up asking you how would you recommend this product to a friend and how satisfied are you. So these are the satisfaction survey that we run across the entire console. They also show up in the docs and everywhere. So every month, we look at where Cloud understands.

James Governor (19:52)
Mm-hmm. Yeah, yeah, sure.

Steren Giannini (20:04)
So satisfaction scores, NPS, and for years now we’ve been very, very high scores and usually around… around the top of GCP services sorted by satisfaction. And when you browse developer forums or Reddit, Cloudland is one of those products that is often called out as why people love Google Cloud. Of course, BigQuery is another one. BigQuery is amazing. And by the way, I was using the internal version of BigQuery way before it was launched. And I was very glad that it came to the world.

because this is such a… a delightful product too. So those products are often called out as why people come to Google Cloud, why they love Google Cloud. And both of those products have a bit the same characteristics. Like BigQuery is this amazing serverless data analysis product. You can process terabytes of data without even blinking an eye, like why in the past this would have been a nightmare to do. And in the same way, Cloud Run is this on-demand runtime. to scale applications or agents. They both have a very simple main value proposition but such a powerful value proposition.

James Governor (21:32)
Okay, okay. Having said, the agents got all the love at cloud next. Now you’ve, you said the word and I think I said a bit about this at the beginning of the podcast. Tell me a bit about that. You know, what was your reaction as, and we’ll do this and then we will talk a bit. What we haven’t done is really talk about the success of the platform. We’ll table that one a bit, but tell me about.

As, as agents began to take off, at what point did you sort of internalize that some of the, I guess the primitives that you chose and we’re going to be so relevant and why cloud run was going to be an applicable platform. And then when did you actually begin to see that in market adoption?

Steren Giannini (22:26)
So, I would say two years ago, I was on stage with the LangChain founder, Harrison Chase, because we had realized that he had built an amazing… At the time, we didn’t use the term agent. So the market has evolved regarding its definition and perception of agents. But two years ago already, at Cloud Next 20…

James Governor (22:48)
Mm-hmm.

Steren Giannini (22:55)
14, I say. I was with Harrison Chase, founder of LangChain, telling the world how easy it was to deploy your LangChain app to Cloud Run. And he was the one telling the world Cloud Run is the easiest place to deploy your LangChain app. At the time, we weren’t saying LangChain app because we did not qualify this as agents, because those things at the time were mostly chat interfaces with very synchronous agents, not that much thinking.

We were starting to see rag like retrieval augmented generation where you use a database to inject more context into your prompt, but that was it. At the time, Cloud Run was an obvious choice to deploy LangChain because LangChain looked a lot like a web server and Cloud Run has been shining in deploying on demand web APIs, web servers. That’s when we found an extremely good fit already two years ago.

A year later, I came back on stage with Harrison, but this time the landscape had evolved a little bit. It was not LangChain anymore, it was LangGraph, because now those agents became more complex and they were using tools. They were doing a little bit more thinking, they were storing memories. Again, LangGraph was a good fit to deploy to Cloud Run and we were seeing people coming to Cloud Run, so we started to document the use.

James Governor (24:07)
Mm-hmm.

Steren Giannini (24:26)
case and we were on the look for what do need to change.

James Governor (24:30)
I’m asking a question, just a little pin in there, because at this point, wasn’t there a bit more of a need for that complexity? Because once people are making decisions about memory or there’s less, does the opinion need to change? Or yeah, how do you offer the out of the box experience in that environment where it’s a slightly different set of constraints and designs from the user’s perspective?

Steren Giannini (24:50)
Yum.

So this is where I can tie back to what I said earlier about we are walking a fine line in opinionation. Because you want to have some opinions, but not too strong opinions, especially in the market and in a landscape that changes so quickly like agentic workloads. Because the opinions that we would have had a year ago about what an agent product should be would actually be very different from what an agent product should be today.

And so fast forward to today, what you need to give your agent is a computing environment where it can run command lines and it can manipulate files. Like a year ago, that was not on our radar. But we started to see the need for sandboxes. And so we started to the story that Cloud Unlock has been sandboxing your workloads from the beginning. And consequently, you could start to execute.

untrusted code, especially if you were to use Cloud Run jobs and we had customers running long-running untrusted environment in Cloud Run jobs. But my point to your question is we were on the look for how should Cloud Run evolve, but we were not willing to go all in on being too opinionated about how to do agents because those opinions quickly become obsolete. And…

James Governor (26:15)
Yes.

Steren Giannini (26:16)
I must say, Cloud Next 2015 and 2016 was all about agent platform. This year was all about agent platform. Google Cloud was also introducing its agent platform. Already a year ago, was called Vertex Agent Engine. In a sense, Google Cloud was already offering a very opinionated agent runtime. So Cloud Run being less opinionated, Cloud Run being more of

compute runtime where you can run a lot of workloads like websites, web APIs, agents became another type of workloads for us. While for products like Vertex Agent Engine, later renamed Agent Platform Runtime, for that product, it was specifically designed for agent workloads. So they could have stronger opinions for what the product should be. And internally, those two things share…

Some technology, yes.

James Governor (27:17)
OK. they’re, they’re, yes. OK. So, and do you, I mean, that’s an interesting one. In that case, I mean, well, might all the agents move over to the, I mean, I think that’s a bit of an emphasis, but might you see less agent deployments to Cloud Run because you’ve got an agent specific platform also available from Google Cloud, or do you not see the world in that way?

Steren Giannini (27:44)
At the end of the day, it’s Google Cloud, which is all that matters to me. And the two teams collaborate a lot. As I said, technically, there’s a lot of infrastructure shared. So I would say, as a Google Cloud platform, we don’t want to offer a single option.

James Governor (27:50)
Mm-hmm.

Steren Giannini (28:09)
The same way, if you wanted to run your container, could use Kubernetes Engine, could use Cloud Run. And the two platforms have been very successful in their own ways. And it’s all about some customers will find it perfect to use Gemini Enterprise Agent Platform.

Some others, maybe the ones who coming from a more developer angle, they want something that is more designed for developers, being idiomatic to developers, more than agent builders. So they will know what a container is. They will be thinking in terms of CPU and RAM or…

Maybe they will even want to have GPUs for several AI inference next to their AI agent. So for maybe the more developer centric audience, they will gravitate, they tend to gravitate towards Cloud. Because it speaks their language.

James Governor (29:12)
Well, I mean, if you build something

that’s idiomatic, then people that know the idiom are more likely to want to adopt it right. So that, I guess, makes perfect sense.

Steren Giannini (29:18)
Yes, yes, yes. But

we are still on the look for how to evolve Cloud Run. And this year, we’ve been investing into quite some evolutions because I think there has been this jump into what agents are.

over the last year. For example, we are launching Cloud Run Sandboxes. If your agent needs to execute in under 500 milliseconds untrusted code, can do so very idiomatically now from the code.

We are, you there’s, you have heard of OpenClaw, right? So everybody buying Mac minis or VMs or local computers to run a long running always on background agent. So that kind of workload was not a good fit for Cloud Run, for the Cloud Run of 2019.

And actually, we’ve now evolved Cloud Run to support that kind of workload. We have introduced the Cloud Run instance. It’s an always-on, cheaper resource where you can deploy OpenClaw in one command.

James Governor (30:23)
Okay.

Steren Giannini (30:23)
And it is designed for this kind long running background agents that need a sandbox and a file system to perform their work. But you know, who knows what agents will be or what they will need in the upcoming years. So that’s why we are always on the look for how Cloud Run should evolve.

What primitive do we need to add to that developer friendly container runtime so that the agent builders can deploy agents?

James Governor (30:54)
Yes. Tell me a bit, this is a slight change of gear. We can maybe get to the future of agents, we can come back to that as well. like you mentioned LangChain. I mean, have you got any other, any other AI companies that you could talk about that are using Cloud Run?

Steren Giannini (31:19)
Yes, so there are some I cannot talk about, but there are some I can talk about, and notably two of them I should call out. One is, maybe you might have heard of them, called Anthropic. Anthropic has been leveraging Cloud Run for its high scalability. So basically, every prompt you send to Claude,

is somehow going to Cloud Run. And as you might imagine, the traffic is, one, enormous, and two, highly viable. Depending on the time of the day, they will see traffic that really changes. So that’s why they really value Cloud Run scalability on demand. I don’t think Anthropic scales to zero, right? A developer would care about scale to zero, but Anthropic cares about the fast scaling and the on-demand compute.

that Cloud Run offers, as well as the pay-per-use nature of Cloud Run, because during the night when the traffic goes down, they have way less usage than when it’s peak, and in that case the build becomes lower.

So Anthropeak was with us on stage this year to call out how Cloud Run has a lot of benefits for them, very low maintenance. It’s really like they optimize for speed and Cloud Run allows them to go fast. They have less things to worry about, less infrastructure to manage. in this environment, what matters is velocity. And as a consequence, they are ready to…

to delegate a lot of the operations to Google when they use Cloud Run. I would say another company which has an AI agent is Replit. Replit, in case you don’t know, I’m sure you do, but maybe the others don’t know, has been extremely successful among developers and even students to create applications. The Replit agent is helping them create applications, this area of Vibe coding, if you want.

are that when you deploy your app from Replit, under the hood, it deploys to Cloud Run. And so this has been quite successful. A year ago… the Replit founder tweeted a chart which was really showing an exponential curve. And it was, I think a year ago, was like 150K. Oh no, he had hidden the Y axis, but the number was publicly disclosed at Cloud Next. A year ago, was 150K applications. This year, Scott, VP of Engineering, shared the same chart.

James Governor (33:47)
Thank

Steren Giannini (34:03)
meaning the exponential was still an exponential at a very different scale because now the number of applications was a million. So who knows where we will be in a year, right? But definitely from the Cloud Run side, maybe that leads into the success of the platform. We’ve been seeing a drastic increase in the number of deployments.

and the number of accounts using Cloud Run. A metric that we have shared is that we’ve doubled our number of active accounts and our number of deployed applications over the last year. So considering the product was already quite for some time in the market, doubling your numbers…

is quite something and it’s not stopping. The curves are all looking exponential. And so for us, it has led us to really double down on making sure we can scale some parts of our system. You don’t see that as a customer or developer, of course, but Cloud Run systems had to evolve to handle the success of Cloud Run. And it’s currently ongoing.

James Governor (35:16)
So.

Tell me a bit about that because I think that as an industry at the moment, we’re kind of creaking at the seams a little bit. We were not built for the that agents are creating. As GitHub has publicly attested, traffic patterns are making things a bit of a struggle. But across the board, I mean, we’ve got…

sort of 10x, 100x, possibly 1000x scale requirements coming in because of the amount of software, well, partly that agents are building, but certainly the number of events that they’re generating. And also, I think one of the other things is, of course, some of these are long running. A lot of them are ephemeral workloads, but the…

The sheer scale, I think as an industry, it reminds me of maybe even the olden days, actually, sort of the early days of sort of e-business when the internet came along and initially it’s a catalog. But once it started driving transactions and self-service transactions to those back ends of banks, retailers, the web companies,

the sheer scale was not something we built for. So what are you doing to accommodate for that? what sort of, as you say, you know, we’re like, wow, Cloud Run seems to be doing a good job of this, but I’m assuming it’s certainly at times it’s got to be all hands on deck in order to do that. Are there any significant architectural changes you’re going to have to make to deal with the scale that agents are putting on the network?

Steren Giannini (37:19)
The good news is that we were designed for this. We’ve been waiting for that moment for years. And we are riding the wave. We are fueling the fire, actually. We’ve partnered with Google AI Studio, an amazing Vibe coding platform. And you know what? Right now, if you try it and you want to deploy to Cloud Run,

You don’t even need to put your credit card anymore. Click deploy, boom, you have your URL deployed to Cloud. That’s going to be announced tomorrow at Google IO, but it’s already rolled out right now if you give it a try. so we are looking for troubles, Instead of blocking access, we are actually lowering the barrier to entry because yes, Vibe coders, they don’t want to create…

a Google Cloud project, they don’t want to think about enabling APIs. They don’t want to think about containers, of course not. So that’s why Cloud has also evolved to be even more simpler for them. But we are really doubling down on that because fundamentally, we were designed for it. So our infrastructure is not VM based. When an application scales to zero, we have no cost on the Google side.

What that means is that we have been designed for this massive scale of very low usage or long tail applications. Of course, over the lifespan of Cloud Run, we launched and we spent years to become enterprise ready. So don’t want to dismiss the fact that a lot of enterprises are on Cloud Run. Another customer is like Ford. Ford has been ramping up on Cloud Run, migrating thousands of services.

extremely happy now and we’ve designed for them a lot of enterprise features. We worked on being able to support more legacy Java frameworks, for example, that we are taking some time to start. We’ve checked the enterprise box, I would say. Just at the right time, we saw the rise of Vibe coders and AI agents, AI agents also deploying to Cloud Run. We decided to

to double down on that and empower bytecodeers, empower AI agents to deploy. And yes, we had to make basically capacity, of course. had like, Cronin has grown so much that now we have to do capacity planning at the scale of the data center. It starts to become so big that we plan alongside or Compute Engine or Kubernetes Engine colleagues.

but also some parts of the systems that maybe we are not assuming. that scale of number of deployments per minute or more importantly number of resource in a given region. So those are the systems that we had to evolve but know it’s software engineering. We know when those systems will find their limits so we invest early on to lift those limits and so far so good. Of course as we allow people to deploy without a credit card we had along the way the

to prevent abuse. So there was a time. Yeah. But we were ready for it because as you know…

James Governor (40:40)
I was gonna say, that just sounds like an absolute nightmare to me, right there.

Steren Giannini (40:47)
If you allow people, like Cloud Run has always had a free tier. So you could always deploy your side project to Cloud Run and not pay anything. And of course, when you do that, people will try to abuse it. And so we’ve been investing years ago into abuse prevention mechanisms. We can detect Bitcoin mining, which are against Google Cloud’s terms of services. And we can more importantly protect customers from each other. And we’ve added limits into the product that we are not here at the beginning.

And those limits are also very useful for developers. When we launched Cloud9, we… we had a cap of like a thousand containers maximum per service. And it turns out that can be quite costly if suddenly your app goes viral and it scales to a very large amount of containers. So what we did was we actually lowered those default values, but also we’ve put quotas in place so that by default you might not want to scale to like 10,000 containers. And if you want to, can just in one click get more quota.

And what was really resonating with the crowd this year was that we are going one step further by introducing spend caps. So finally, developers will be able to tell us, I don’t want to spend more than x dollars on Cloud Run. And very soon later, I don’t want to spend more than x dollars on GCP, on Google Cloud Platform.

And when you reach that limit, your cloud and resource get posed. So it’s your choice. Either you decide to bump the limit and you can resume serving your traffic, or you prefer to cap your bill and therefore your containers and workloads are posed. So that was very well received. It’s launching later this summer. Because we’ve all heard those stories of

No serverless where the function recursively calls itself. just by the time your billing alert comes in, you already have a large bill. So hopefully we did not have that many of these in Cloud Run because as I said, there was nothing like infinite capacity, infinite limit. We made it clear from the beginning that there was a limit and this limit, we actually lowered it over time because we realized most people did not need to scale to very high scale by default. And we preferred them to opt

into it rather than to discover it with a bad surprise. But hopefully with Spend Caps, it goes one step further where you can just say, cap my bill. So yeah, a lot of… I must say over the past probably two years, we’ve really concluded that we had delivered the most enterprise features that were blocking top enterprises customers and the business was doing extremely well. And we were like a little bit refocusing towards the developer audience.

James Governor (43:51)
By the way, so before we go on to that, what, mean, I think we all know what enterprisey features are, but what were some of the enterprise features that you’ve removed blockers that have been valuable that you found the likes of Ford or others are getting the most value out of? What have you had to add?

Steren Giannini (44:09)
I mean… When we launched Cloud Run, we did not have two things that in retrospect were big, big gaps. One was VPC connectivity. Those enterprise customers, have workloads, virtual machines existing, they even have on-prem resources that they want to connect to. The way to do that is to connect to a VPC, Virtual Private Cloud. We really delivered that whole networking. Most of those enterprise features are on security, on networking.

or compliance. like security, you we have things like threat detection, you can bring your own encryption keys, like there are things like access and transparency where when Google Cloud support or engineer want to help you and diagnose an issue, like you can, that leaves a trace of course, but you can even approve and there are so many things like that that we had to deliver.

also integrate as part of the horizontal Google Cloud Platform. Organization policies, customers can now define custom policies for what they allow to be deployed on Cloud Run. So for example, if a customer does not want their developers to create public applications, they can block that, right? So which was not the case at the beginning. So they can say, you know, every Cloud Run service must be protected by an IAM check. It cannot be public on the internet.

So those kind of things were a long, long list of features we had to build. I think I mentioned that two big things. One was VPC connectivity, but another one was all of the integration with the Google Cloud application load balancers, the internal load balancers, external load balancers. Because most enterprises are not just publishing one website under one domain. They have a very complex routing mechanism for their or even internal

routing and load balancing mechanisms, so we had to integrate with all that. A lot of things, a lot of things that we delivered and then at this point I’m not aware of big enterprise blockers.

James Governor (46:28)
So, I mean, that’s a whole conversation you mentioned Ford. I’m sure there are a load of other interesting use cases, but you wanted to talk there a bit about your sort of refocusing on developer. So where are you on that journey? How do you make sure that you’re meeting the latest idioms? What are you doing from a developer perspective?

Steren Giannini (46:53)
I think it’s also that it’s not only developers anymore who deploy to Cloud Run. It’s also AI agents. by that, mean the…

James Governor (47:03)
Yes.

Steren Giannini (47:06)
not only the coding agents, which once they have helped you code your application, they can also help you deploy. So for that, example, we’ve invested, like a year ago, I launched the Cloud Run unofficial MCP server, which I wrote myself because I was reading the MCP specs. So MCP is model context protocol, which has at the time was emerging as a a standard for how

agents can use tools. And so we were probably one of the first Google Cloud service to have an MCP server and we demonstrated how you can connect it to Gemini CLI, Cloud, Cloud Code. But then we actually, this was an open source project that you had to install on your local machine. Then we invested into a fundamental platform.

layer to offer fully managed, secure, and remote MCP servers for many Google Cloud services. And Cloud Run was in the first wave of services which launched a fully managed remote MCP server. So that’s one example of something that we had to deliver to empower not developers, but through agents to deploy to Cloud Run.

James Governor (48:27)
Yeah, it’s agent experience as opposed to developer experience. Yep.

Steren Giannini (48:30)
And of course, it’s developers too because IDEs support MCPs, the MCP standard. then you can, from VS Code, you could deploy it to Cloud Run just by connecting the MCP, which was fully managed and remote. But I mean…

I think our focus to developers has always been here, but at one point we had to invest into being enterprise features, and now that we believe we have most of them, it was a good time to refocus on making an even simpler product. And because another example of investment is being compatible with more package managers. So, in other words, the Python ecosystem. So, yes, of course, you can deploy a container.

and you could do that from day one. Then we added support for deploying from source code with no Dockerfile. In that case, what we do is we use a technology called Buildpacks to detect what language is your application using. We know we have builders for each of those languages and we have runtime. Once we’ve built the app, have runtime that includes the Python runtime. Those runtimes, by the way, are automatically updated for you

with no deployment required on your end, which is something that also enterprises value a lot because it automatically patches the security issues from the runtime. But if we take the example of the Python runtime, it was only supporting requirement.txt. So, you know, maybe five years ago that was fine.

But two years ago or one year ago, it wasn’t. The Python ecosystem had evolved. It was now converging towards PyProject.tuml. And so other ways to declare your dependencies, other ways to declare your apps. So that was one concrete example of things we observed. And we decided to add support for it in our Python build packs. And I must say, right now, an interesting…

challenge has been, Cloud Run delivered those enterprise features, as Cloud Run delivered features in general, we have to constantly fight entropy. Because what started as an extremely simple product with literally one input field, which was container image, has now grown into something that supports volume mounts and side cars and GPUs and tons of networking and security options. And so I must say as a product leader for that organization, now my role is to…

make sure we, one, we have a cohesion in terms of experience because now we have a lot of people working on different aspects of Cloud Run so they all need to deliver something that is consistent, but two, to constantly think about simplifying. If we don’t pay attention to that, what could become more and more complex over time? So an example was when you wanted to mount a…

James Governor (51:30)
Yeah.

By the way, do you just,

do you like sit there with the original design docs and occasionally say to the team, don’t make me tap the sign? Is that…

Steren Giannini (51:50)
Yes,

literally, I often refer back to it. I literally have it open now and it says, common use cases should be easy and facilitated. More rare use cases can require more UI or CLI manipulation. And so like this is something that I always tell the team, when you design something, think about what most of your users will want to do with it.

and make that simple. And now the most advanced user, the more advanced use case, it’s OK if you need more flags to the command line. It’s OK if you need to go down into a config file to achieve the use case. A great example was Cloud Storage Volumes. So you can simply mount Cloud Storage into your Cloud Run Resource, and they appear as a file system. So amazing, because Cloud Storage is such a strong storage product from Google Cloud. But when we launched this,

James Governor (52:15)
Mm-hmm.

Steren Giannini (52:43)
we defined it as a volume and then you had to mount the volume in a different place because well yeah because now Cloud Run supported sidecar containers so maybe you wanted to define one volume that you wanted to mount in two different places in two different containers but

Again, most of the time, users only have one container and they just want to mount that bucket at a certain place. So we ended up, even if we launched with a quite complex UI and CLI, we ended up simplifying all that. So that in command line is dash dash volume type equal cloud storage, bucket equal my bucket. And that’s it. That’s all you need. While, you know… the original design was way more complex. So that’s one example of simplifying an existing product.

James Governor (53:33)
Yeah, that’s great. mean, and actually that’s sort of puts me in mind of it’s not exactly the same use case, but I was talking to Andi Gutmans, obviously one of the senior leaders at Google Cloud who runs the data and storage businesses, which is a lot. But one of the points that he…

Steren Giannini (53:54)
Did Andi tell you he’s also taking care of the deprecations at Google Cloud?

James Governor (53:59)
He’s taking care of deprecations.

Steren Giannini (54:01)
Yeah, this is a side note, but Andi created something called the deprecation console that I belong to. Senior leaders belong to that console to make sure that we respect our customers. we are pushing back on, like when teams want to deprecate something, we are sometimes pushing back on.

James Governor (54:12)
Mm-hmm.

Steren Giannini (54:23)
the deprecation itself, but if we agree, we guide them to make it as good experience as possible, as respectful to our customers. And I’m calling that out because Andi has been the founder of this effort. So he’s not only doing database, he’s also, maybe this is internal only, so be it, he’s also taking care of deprecations and I’m now part of the team too.

James Governor (54:50)
So what is super interesting to me about that is one of the conversations that I had with him at Cloud Next, or about the conversation I had with him, the thing that really struck me, and I came away with this, was that, you know, we’re now in an environment where…

Because you do need to jettison your priors, because the use cases change so dramatically, because new capabilities emerge, if you think about the, well, Gemini now as opposed to where it was and how much we can rely on it. Certainly we’ve seen that, I think with all of the frontier models, there’s been a huge amount of development. So things that you thought you couldn’t do.

with agents, it turns out now you can, or things you couldn’t do with models. The point he was making was that the, and he’s making product plans and then less than a year later realizing that they need to change and that something is going to need to be rebuilt. And it may have some slightly different design principles and there is going to be more change. And of course,

I think what’s really interesting in what you’ve just raised is, is historically at least, look, I mean, it’s a meme, you know, killed by Google. That is a thing that, people, you know, can I rely on this service because it might, it might, you know, it might go away. Very interesting that Andi, who had made this point that actually now Google is having to say, hang on a minute. You may need to start again, less than a year, less than a year into the product.

in order to ensure that it’s engineered for the right use cases, that actually he’s running that council, I think, very useful. And yeah, that’s a really interesting…

Steren Giannini (56:50)
But what you said, APIs are forever. CLIs are forever. So that’s one of the design principles of Cloud Run. As soon as we go public preview, we know that the thing will be forever. So that’s why we have this tendency of spending a lot of time in private preview, because when your customers are under an allow list, and when you have their emails, and when they have signed up for things to have early access, they are OK if you introduce a breaking change. Once you go public, you can’t.

V1 API has full backward compatibility, the Cloud and Command line full backward compatibility. And yes, there are some things, there are some designs that we regret. If we had to do it again, we would do it differently. But we just don’t. Because we want to respect the countless of CI-CD pipelines that depend on that API or depend on that command line. And we must retain backward compatibility.

James Governor (57:50)
Yeah, I think that.

Steren Giannini (57:50)
And so we will pay a lot of attention to that across Google Cloud, not only Cloud to be clear.

James Governor (57:55)
Yeah, that need for consistency is super important. As you say, you can’t break everyone’s pipelines. Okay, so that’s honestly, that’s yet another thing for me to sit here thinking about stuff that Andi’s doing, the deprecation council, I think that’s good and important. You need a representative of the customer that constantly thinking about, well, things are gonna change, but how do we manage that process?

Can I ask you just a sort of a general question? mean, Google is pretty good at security. We know that. You mentioned being able to run on trusted environments before. mean, I’m untrusted in, there, have we crossed a sort of a Rubicon now from an agent security perspective? And are there new challenges that you really think you’ve got to nail down for? We’ve talked about the requirements of scale.

I sort of feel like security, just feel like we’re at the of the gray goo period of security. There don’t seem to be many things we can rely on. So what are you doing to ensure that Cloud Run doesn’t become… a vector for attacks that are successful.

Steren Giannini (59:16)
Mm-hmm.

So I think this is the same way we were designed for that kind of large long tail scale. We were also designed for those untrusted workloads. Because from the start, originally we were using… So when we launched, your containers were sandboxed in a sandbox technology called GVita. There is two layers of sandboxing. This is the first one, the second one is another layer.

We’ve since then introduced another sandbox. It’s a micro VM sandbox. Again, two layers of sandboxing. But that’s just one thing to know is that, well, on other runtimes, your containers are not sandboxed between each other. So while on Cloud Run, they always have been. So that’s one way to, okay, if one of them gets compromised, it cannot escape.

within your other workloads and of course not within other customers workloads. So that’s something that we’ve been like from the start having.

as a core feature of Cloud Unleashed. I must say, now with agents which need to run untrusted code, we are actually going to be leveraging that technology to offer this sandbox feature. For us, it’s there in the system. What we need is to expose it in a different way so that your agent can ask for a sandbox the same way your container gets wrapped around the sandbox when you deploy it. I think the security landscape is constantly…

James Governor (1:00:30)
100%.

Steren Giannini (1:00:50)
evolving. We’ve seen some pretty big ones and unfortunately that are notably in the dependencies, in the language dependencies. And this is where the contract with these customers that we have

James Governor (1:00:59)
always.

Steren Giannini (1:01:04)
is that, okay, we will secure your container. If you use one of our managed runtime, we will secure the runtime. So the Node.js version, we automatically, like if there is a CVE in Node.js, if it’s a severe one, in 24 hours, it gets deployed to the Cloud Run fleet. What we don’t…

provide is a way to know what’s within, what’s above that layer. So your application code might have a vulnerability, potentially because it uses a dependency that has a vulnerability. And this is the customer’s responsibility. So just under exceptional circumstances, we’ve blocked the deployment of certain dependencies. Like one of them was the…

React slash Next.js vulnerability we had not that long ago. And so for that one, we actually blocked you if you wanted to deploy a vulnerable version of React or Next.js. And also, under those exceptional circumstances, Google is sometimes looking at putting firewall rules to block the attacks once they are known, when their patterns are known. But this is where security is also a shared responsibility. Security of your application.

is always going to be requiring you, the customer, to pay attention to, notably, the top layer, like your application code, your dependencies.

James Governor (1:02:28)
Absolutely.

And you should be using, I mean, at this point, I mean, you really should be using trusted images. You know, we’ve got an ecosystem, you know, whether you’re, you know, working with Docker or Chainguard, hardened images is absolutely best practice and you should be doing that.

Steren Giannini (1:02:36)
Yeah.

Absolutely. It is essential.

We’ve also added things to Cloud Run like container threat detection, which basically is a… some kind of an agent that runs next to your container and watches for any suspicious activity. So you can enable that in one checkbox in Cloud Run. Actually, no, it’s even centralized. It’s in the Google Cloud Security Command Center. You can enable Cloud Run threat detection, and you can start to monitor for suspicious activities across your Cloud Run workloads. A thing that we had probably more enterprise…

Each feature is a binary authorization where you want to ensure that what is deployed has been signed. by your CI-CD pipeline and not built on a local developer machine, right? Because you never know if this developer machine was affected. So at least if it’s your CI-CD pipeline and you can attest that it comes from the CI-CD pipeline because you’ve signed it. So those are things that we’ve built into the platform and into Cloud Run. But yeah, we are absolutely always looking for how can we make that even better for customers.

James Governor (1:04:02)
100%. So I think I’ve just, mean, frankly, I think it’s a really interesting story. mean, yeah, maybe this is for a follow-up or something. I’d love to know about some of the personalities of a cloud run, some of the people that were there at the beginning, that have been through the journey. That’s always an interesting one, you know, hearing some of the human stories behind the engineering. But I think…

Steren Giannini (1:04:26)
Mm-hmm.

James Governor (1:04:29)
I think, yeah, maybe we’ll, we can come back to that. A couple of things would be one, you you mentioned Ford, are there any other sort of, are there any, and they could be enterprise, could be, you know, start, are there any other stories you can tell that you just think are really exciting? Like what are some of the things perhaps you’re proudest of with Cloud Run or? Just some customers where you’re like, wow, it’s amazing what they’re doing there.

Steren Giannini (1:05:03)
We’ve seen companies that are the ones that in the financial sector, for example, they have the obligation to be resilient to a regional outage of their cloud provider.

in Europe, not only. They must be resilient to a regional outage. So Cloud Run supports out of the box zonal redundancy. So when you deploy, you deploy to a specific region. If a zone goes down of that region, as a customer, you barely see it. And we repeat that exercise very often so that your workloads get seamlessly rescheduled on other available zones. And for us, it means we have N plus one redundancy in everything we design and in our capacity.

But those customers, go one step beyond. They want to be resilient to the loss of a Google Cloud region. And that is where Cloud Run shines. So those customers are DZ Bank in Germany or like Commerzbank, ANZ Plus. So basically a lot of them in the financial sector, availability is paramount. So they want to build high availability applications. And the beauty of Cloud Run is that they don’t need to pre-provision capacity in all of those regions. It doesn’t cost them much more to spread their traffic across two

region and when one region has an issue to reroute all the traffic to a single region or maybe even more than two, it doesn’t cost them more to do that than to go to a single region because it’s of its own domain nature and that’s one big plus. So that’s one example of change we’ve brought to Cloud Run.

we brought multi-regional deployments. Now, still using the same simplicity, gcloud run deploy dash dash image, except that now you can pass dash dash regions and the list of region. And suddenly, your deployment becomes multi-regional. So they really valued the fact that that was baked into the product. The same way you can have multi-regional database with Spanner or even storage with Cloud Storage, you can now have multi-regional compute runtime with Cloud.

and that’s baked into the product. So that’s a use case I would… That’s a type, like financial services is a type of customer I would not have predicted would be valuing that much Cloud Run. But it turns out a lot of them are… Some others are, you know…

James Governor (1:07:35)
Well, I mean, with the Cyber Resiliency Act, I think in Europe even more, the need for that sort of technology is going to be huge. The Cyber Resiliency Act, by the way, if you haven’t all looked this up, please do. Basically, the requirements on organizations that even use software in running their businesses are going to significantly increase vis-a-vis security. We’ve been speaking a bit about security the past 15 minutes or so.

Steren Giannini (1:07:39)
Yes.

James Governor (1:08:03)
All of these things are frankly relevant. Yeah, that I know there are some standards the EU has that people don’t like. GDPR is something that certainly a lot of American firms have a lot of bug bears about. But certainly European companies are going to have to get very, very serious about the resilience of the systems that they’ve got in place. So yeah, I think if you’re a vendor, find out about it because it’s an opportunity.

If you are an enterprise user, definitely spend some time looking at the CRA and seeing what your legal implications are because you may not be fully aware of them.

Steren Giannini (1:08:42)
We’ve seen a lot of adoption in the media industry where here the traffic patterns are often can be very spiky. So we supported the World Cups, many World Cups, with a company called Televisa Univision. The BBC has been using Cloud Run and they’ve publicly talked about how when the Queen passed away, they saw a drastic increase in unpredictable,

James Governor (1:08:51)
Yes.

Steren Giannini (1:09:12)
increase in some of their systems. And the systems that were built on Cloud Run absorbed that with no issue. So this is, again, the on-demand hyper scalability of this compute runtime. Cloud Run is not only a developer product which developers love, it is also an extremely capable and scalable runtime that very big customers are using at scale.

James Governor (1:09:37)
Okay. No surprises there. And as I say, I mean, I still, if we think about where we started, the simplicity was, that was the key. But of course now we’re in a slightly different, we’re not in Kansas anymore. So in the Wizard of Oz world of AI and like where we’re going as an industry, like what’s next for Cloud Run? What are your…

How you going to maintain simplicity, find those new idioms? You know, obviously you can’t pre-announce anything exactly, but you mentioned an announcement at IO, which is going to be happening now. By the time people hear this podcast, that will be public. But yeah, what sorts of things keep you up at night about where and what you’re going to need to do with the platform going forward?

Steren Giannini (1:10:30)
There are really two areas. One is a runtime to host agents. And here is where you will see over the just this year many changes to Cloud Run.

to help you deploy your agents on Cloud Run. Many people are already doing it today, but we want to give them the primitives to do it even better. a good litmus test is, can you run OpenClaw? Today, you cannot. And within two months, you will. The second one is that, to me, it’s the more profound change is that who is a developer? The definition of developer is changing.

James Governor (1:10:52)
Mm-hmm. Yep.

Steren Giannini (1:11:14)
The barrier to entry used to be high, right? And now you have tools like AI Studio. which literally enables people who were not technical protectioners before to build applications and to deploy them. So that’s where we feel we have a role to play for Google and for the industry because we are a runtime that has been designed for that. Those Vibe coders, they’re not going to be creating a Kubernetes cluster. Those Vibe coders, don’t even want to open the cloud console necessarily. They open ai.studio,

James Governor (1:11:48)
No, 100%.

Steren Giannini (1:11:52)
I invite the audience to give that a try. They vibe code an app that they might want to be only sharing with themselves or with their family or who knows, with the world and build a business on top of it.

They want to click publish and they want that to just work. And the expectations of that audience is probably even stricter than what developers like for a developer. Yeah, when it took you days to build your app, it was okay if your deployment took minutes. When it takes you one minute to build your app, your deployment should be instant. So that is the kind of investment we are doing to simplify deploying to Cloud Run, to speed up deploying to Cloud.

run so that developers don’t have even less things to think about. Even if the product was extremely simple, we want to simplify it further.

James Governor (1:12:46)
That’s perfect. Because I’ve got to tell you, is that deployment, you know, you know, we talk about the Heroku lesson, you know, we talk about everything you’ve done. it, VibeCode, VibeCoding an app is very often it’s actually the deployment is where you get hung up. That’s where the problems emerge. Um, and you know, I think the models are getting much better than this, but better at this, obviously platform integrations, you know, we’re seeing it across the board in the industry and making it easier, but that, that remains a key point.

So you’re going to be having all of those Google Docs users also creating apps and deploying them to Cloud Run. Is that what you’re talking about?

Steren Giannini (1:13:27)
Yes, you know, one sentence I say to my team is it should be as easy to build and deploy an app than it is to write and share a Google Doc.

That’s the bar we are aiming for. And I believe that with AI Studio and the new publish flow that we are introducing at Google I/O., we are getting very close to that. It is extremely easy to build the application. And now it is extremely easy to publish it to a point where you don’t even need a credit card. By the way, we are talking about Cloud Run, but your application can use a database, can authenticate users with Firebase. We are adding Cloud SQL to that with

with a special developer edition of Cloud SQL. And your app can also connect to Google Docs, Google Spreadsheet, Google Slides, Google Tasks. And so all of those services help you not only run the application, but also store data and send emails and connect to the Google Workspace ecosystem. And so all of these are being…

at everybody’s reach through AI Studio. that they can deploy. A small personal story, I have a daughter, she’s doing a spelling quiz every week. And at one point she was struggling to have good grades on this and I built her an app using AI Studio that she now uses to study those spelling tests. And now she’s been like 10 out of 10 every week and she loves it. So you see how, I would not,

James Governor (1:15:07)
Yes, sure.

Perfect.

Steren Giannini (1:15:13)
have spent the time to build that application before. have much time. But with AI Studio, in a few prompts, I ended up building what she’s now using all the time. And when she gives me feedback about something could be better, I just one prompt away to update the application. And in one button, it gets redeployed and updated. So those are like, I encourage everyone to think about what kind of personal software would be beneficial to your daily life and just prompt it. Because at this point, it is very much the barrier to creating is lower than ever.

James Governor (1:15:52)
amazing. I think that’s a pretty good place to close. But now you’re making me think, my goodness, I’m have to get this edited quickly because of this Google I/O. content. It feels quite fresh. It was supposed to be about the past, present, and future, a piece that would stand on its own for a bit, slightly more longer running. I’m, yeah, no, looking forward to I/O now.

Great, so Steren, thanks so much. Thanks to all of you for joining us. Hope you’ve enjoyed this episode. I do love a bit of history. That’s one of the reasons I do what I do at RedMonk, know, try and put things into context in the short term and the long. So thanks all for joining us. Thanks again, Steren. And we will be creating more and more, hopefully great stories in the RedMonk conversations to come. So sign up for the

You know, all those like, subscribe, that good stuff, and please do share this because I think it’s a great and interesting story.