MARTIN OMANDER: Hi, Derek.
DEREK DOWNEY: Hi, Martin.
MARTIN OMANDER: So, Derek, you are
a developer advocate specializing in databases,
right?
DEREK DOWNEY: Yeah, that's right.
MARTIN OMANDER: Great.
I have a question from a customer who
is building the product on top of Google Cloud using
serverless products and they need a relational database
for their application.
DEREK DOWNEY: Sure, happy to help.
[MUSIC PLAYING]
MARTIN OMANDER: The customer is building a system
using Cloud Run, and they picked Cloud Run
so they don't have to provision and maintain servers.
And this reduces the ops work needed
to keep the system running.
Initially, they picked a NoSQL database
that helped them get their MVP out the door really quickly.
DEREK DOWNEY: That makes sense.
MARTIN OMANDER: They got great feedback from customers
for version 1 of their system and they're
getting ready for version 2.
They realized they will need ACID transactions and also
aggregations, like sums and averages,
across thousands of records from their database.
And they can't do that easily in their NoSQL database.
DEREK DOWNEY: Got it.
Any particular issues they're trying to solve
with ACID transactions?
MARTIN OMANDER: Yeah, they've been
having consistency issues with the data as more customers use
their app.
And they're spending a lot of time fixing those issues.
DEREK DOWNEY: Ah-ha, Yes.
OK, do they have any other requirements?
MARTIN OMANDER: Well, they want a managed database
that scales as they grow.
And they want to minimize the ops work needed
to keep the system running.
DEREK DOWNEY: Well, in that case,
they should look at Cloud Spanner.
It's a fully-managed relational database
that ensures strong consistency and great availability.
And it has unlimited scalability,
so it will easily scale as their needs grow.
MARTIN OMANDER: All right, Derek, let's break that down.
You started out saying fully managed.
What kind of ops work would they need
to do to keep their Spanner running smoothly?
DEREK DOWNEY: Well, for starters,
they don't have to worry about patching
or other typical server maintenance.
They also don't have to manage any complex architectures
for load balancing or failovers.
They don't even have to manage encryption,
though Spanner has the option for the customers
to manage encryption keys if they require it.
They will have to manage access control
and schedule their own backups.
They're also in charge of schema migrations,
but Spanner manages the deployment of those changes.
Schema changes in Spanner are online, though,
so they won't block the app during the migration.
MARTIN OMANDER: OK.
And, next, you said unlimited scalability.
That's a pretty bold claim, Derek.
DEREK DOWNEY: Yeah.
Spanner provides consistent transactions,
like other relational databases, and is a horizontally scaling
database similar to NoSQL databases.
So it grows with your data.
To give you an idea, Spanner processes
over 1 billion requests per second at peak.
MARTIN OMANDER: Wow, that's a lot.
Then you said strong consistency.
How can a global relational database
be strongly consistent?
DEREK DOWNEY: Great question.
Spanner relies on TrueTime to provide commit timestamps
to guarantee global consistency.
TrueTime is an internal Google service
that guarantees monotonically increasing timestamps
with microsecond granularity across all nodes.
These timestamps, combined with Google's
dedicated infrastructure, allows Spanner
to be strongly consistent at low latencies.
MARTIN OMANDER: Great.
And, finally, you said great availability.
What does that mean in this context?
DEREK DOWNEY: Spanner comes with an SLA guarantee
of up to five nines of availability
to ensure users have access to their data.
Spanner stores multiple copies of your data in different zones
or regions to handle maintenance and outages.
This is transparent to your application,
so your code doesn't need to know where the replicas are.
MARTIN OMANDER: It sounds like Spanner
fits the needs of the customer.
Could we take it for a spin?
DEREK DOWNEY: Yeah.
What did you have in mind?
MARTIN OMANDER: My test app is a simple REST
API for managing users.
I'm thinking I'll swap out its NoSQL database with Spanner
to get a feel for how much work it would
take to migrate a real project.
DEREK DOWNEY: We can totally do that.
First, go to the Cloud Console.
Click the hamburger menu and scroll down
to the Databases section and click Cloud Spanner.
Then click Create Instance.
MARTIN OMANDER: Mhm.
OK, I did.
Aha.
I see a lot of options here.
What should I pick?
DEREK DOWNEY: If all of your users are in a single region,
you'd want a single region configuration
to minimize latency.
If the database will be accessed from multiple regions
or you need five nines of availability guarantees,
you'd want the multiregion configuration.
MARTIN OMANDER: Let's use a regional configuration.
And I see that the price changes up here
as I change the options.
Do I need a full node?
DEREK DOWNEY: Probably not yet.
To get started, you'd probably want to go smaller.
MARTIN OMANDER: All right.
For now, I'll set up a dev environment
with 100 processing units, which will come out
to $0.09 per hour or about $65 per month.
DEREK DOWNEY: Good idea.
They can always scale that instance up later
without any downtime.
MARTIN OMANDER: All right, I'll click Create here.
Now I assume my code will need to change to access Spanner.
DEREK DOWNEY: Yeah.
I sent you some code before.
Did you get it?
MARTIN OMANDER: Yep, I'm pasting it in now.
DEREK DOWNEY: Spanner provides client libraries
for many languages, including Node.js.
Since our application is Node, all we have to do
is require the library, instantiate the Spanner class,
and then provide the instance and database information.
We could tune how session pooling is handled,
but the defaults are a great starting point.
Accessing the data is done with standard SQL.
MARTIN OMANDER: Does my code need
to specify which Spanner replica or region to hit?
DEREK DOWNEY: No, Spanner handles that for you.
All you need to specify is the instance and database.
If Cloud Run is configured with a service account that
can work with Spanner, you don't even
have to provide credentials.
Otherwise, you can provide those, too.
MARTIN OMANDER: All right, I'm deploying my updated Cloud Run
service now.
Looks like the API is still working.
So what kind of loads can it handle?
DEREK DOWNEY: I set up a load test
that hits our test application at roughly
3-to-1 reads to write, which is the observed
pattern from production.
I'll start with 32 concurrent users.
Let's see what happens.
MARTIN OMANDER: Looks like a decent amount
of operations per second here.
DEREK DOWNEY: Yes.
Now let's look at the CPU to see how it's holding up.
MARTIN OMANDER: Mhm.
It looks like a load is crossing the recommended CPU
threshold here.
What do we do?
DEREK DOWNEY: Right.
If it goes much beyond that threshold,
you would see request latencies increase.
We don't want that.
We can just increase the processing units.
Let's do that now.
MARTIN OMANDER: All right.
It looks like the CPU is having an easier time now.
And in Locust, we're able to handle many more requests
per second than before.
Those extra units really helped.
Pretty impressive for a globally consistent relational database
with ACID transactions.
Nice that you can tweak capacity while the database is
under load.
Yeah, and there are no changes to the application needed.
Great.
The customer will get ACID transactions
in a managed database with Spanner.
They can start small and scale up
without users being impacted Thanks for showing me
how to do this, Derek.
DEREK DOWNEY: You're welcome, Martin.
I think Spanner would work well for the next version
of the customer's system.
MARTIN OMANDER: Yeah, I think so.
Thank you, everyone, for watching.
If you have questions for me or Derek about Spanner,
please enter them in the comments below.
Also let us know in the comments if you have suggestions
for other serverless topics we should bring up on the show.
Bye for now.
[MUSIC PLAYING]