MARTIN: Hi, Kevin.
KEVIN: Hi, Martin.
MARTIN: I heard you work for a car sharing
service called GreenMobility, and the company
is using serverless.
KEVIN: Yeah, our dev team is really productive
thanks to serverless computing.
MARTIN: Oh, maybe you could share some tips
on how to use serverless to get your developers more
productive?
KEVIN: I would be happy to.
[MUSIC PLAYING]
MARTIN: So, Kevin, GreenMobility is a car sharing service?
KEVIN: Yes.
We run a car sharing platform in seven European cities.
We have hundreds of cars.
And people use them for [INAUDIBLE] trips every day.
We have about 100 employees, with headquarters
in Copenhagen. And we are listed on the NASDAQ main market.
MARTIN: Oh, cool.
I guess many people want to use cars, but not necessarily
own cars these days.
KEVIN: Yeah.
Like, more and more people want to live in cities.
And they're interested in sustainability.
And they also prefer sharing things rather than owning them.
MARTIN: Oh, right.
So what kind of data processing does the company
need to make this car sharing happen?
KEVIN: We've processed hundreds of thousands
of events every day.
Trips, stars, car moves, a car trip ends.
We could have built this infrastructure
for handling these events with virtual machines.
But there would have been a lot of work.
Instead, we went with serverless.
It make this much easier.
MARTIN: Oh, cool.
I love serverless.
Where do you store these events, Kevin?
KEVIN: We store them in Firestore.
We also have a Cloud SQL database for other data.
But we got better data writing performance
at a lower cost with Firestore.
And Firestore is serverless, which means less iteration
work for us.
So we will have SQL and NoSQL databases.
MARTIN: Ah, got it.
Machine learning is hot right now.
Are you doing that, too?
KEVIN: We're working on it.
We like to predict where cars will be needed,
so we can put cars in those places ahead of time.
Our plan is to export the Firestore database to BigQuery
every night.
Then we can run reports in BigQuery
and run BigQuery ML to do the machine learning on the data.
MARTIN: Oh.
Are there any other factors that made you go with serverless?
KEVIN: We also have uneven demand.
More people are driving during the day than at night.
So it would be inefficient to scale our computing
and databases up and down ourselves.
But Cloud Run and Firestore do it automatically.
MARTIN: Ah.
Why did you pick Cloud Run specifically, Kevin?
KEVIN: We really like containers.
And Cloud Run lets us host containers
without having to worry about the server.
If a server is acting up, Google fixes the problem
and we don't have to.
Also, we like the billing model.
We pay for container time, even if the container
is handling multiple requests at the same time.
MARTIN: You mentioned billing.
How much are you actually paying for Cloud Run?
KEVIN: Our Cloud Run bill has been growing.
So I'm keeping an eye on it.
Last month, we handled six million requests.
With Cloud Run, we paid 2,000 Danish kroner,
and that's about $320 US dollars.
MARTIN: Not too bad.
How do you deploy your containers to Cloud Run?
KEVIN: When a [INAUDIBLE] merges into the main branch
in our source control, a trigger ultimately builds
and deploys the container to our staging environment.
And that happens about 50 times a week.
And when we're done testing that particular release,
we manually run a script to deploy that container
to our production environment.
And that also happens about 50 times per week.
MARTIN: Are you building the containers
on one of your machines, or up in the cloud?
KEVIN: How are we using cloud built-in Google Cloud platform?
Yeah, yeah, yeah.
Our build was recently getting slow and taking 15 minutes.
But it was easy for us to change that machine type
in one line on our cloud builder YAML,
which reduced the build time to five minutes only.
MARTIN: Oh, nice.
So, when you do 50 deployments per week, that's a lot.
How do you keep these deployments straight.
KEVIN: We're big fans of immutable deployments.
When Cloud Run deploys a container,
you can't tweak settings and environment variables.
Instead, you do a new deployment.
So immutable deployments prevent drift
in our production environment.
MARTIN: Ah, that makes sense, Kevin.
I'd love to hear more about that.
Maybe you could tell us more details in the next episode?
KEVIN: Sounds good.
MARTIN: And thank you, everyone, for watching.
If you have questions for Kevin or me,
please add them in the comments.
Also, this episode was a little different from others
in the Serverless Expeditions series.
Please let us know if you found it useful.
Until next time.
[MUSIC PLAYING]