MARTIN OMANDER: Hello.
I'm Martin Omander, a Developer Advocate on the Serverless
team.
CRAIG LABENZ: And I'm Craig Labenz, a Developer Relations
Engineer on the Cloud SQL team.
MARTIN OMANDER: Oh, Cloud SQL, you say?
That's perfect because I'm looking
to deploy my app on Cloud Run, but it's back end
uses a relational database.
And I'm not sure how to combine the two.
CRAIG LABENZ: Ah, yes.
Many developers are using serverless architectures
with relational databases.
Why don't you show me what you're building,
and we can take it from there?
MARTIN OMANDER: Sounds good.
[MUSIC PLAYING]
All right, Craig, I've decided to settle
one of the greatest programming head scratchers of all time.
CRAIG LABENZ: Ah, GIF versus "jif?"
MARTIN OMANDER: No, not that one.
CRAIG LABENZ: What color is the dress?
MARTIN OMANDER: No, Craig.
I said programming.
I created a web app to poll whether developers prefer
tabs or spaces in their code.
CRAIG LABENZ: Oh, I love that idea, because the answer will
obviously be [BLEEP].
Now, your app is definitely going
to get millions of daily active users from day one,
so you'll need to be thoughtful with its infrastructure.
Can you show me what you have?
MARTIN OMANDER: Yep, my app's code is ready to go.
There's a simple front end that displays the most
recent votes plus the totals.
Also, there's a form at the bottom that collects new votes.
CRAIG LABENZ: OK, that sounds like a pretty standard web app.
Now, you mentioned using SQL for its back end.
What went into that decision?
MARTIN OMANDER: Well, I plan to have several Cloud Run
services that periodically run analysis on my data.
And SQL is really good at aggregations
like sums and averages.
CRAIG LABENZ: Hmm, yeah, that makes sense.
It sounds like Cloud SQL is actually
the right choice for your app.
MARTIN OMANDER: Oh, that's good to hear.
But my fear using SQL with a serverless architecture
is that Postgres and MySQL databases,
that they don't scale up automatically
like Cloud Functions or Cloud Run.
CRAIG LABENZ: Oh, we've all been there.
Now, luckily, traditional SQL databases
have a lot of tricks you can use to squeeze
every last drop of performance out of your hardware.
What do you say we deploy your app,
and then we'll run some load tests?
MARTIN OMANDER: Sounds good.
Let's get this baby shipped.
All right, so I'm ready to create my database instance
here in Cloud SQL.
I click Create Instance.
And ah, the first thing, it asks me for database engine.
Do you have any recommendation?
CRAIG LABENZ: Well, all three provide a modern SQL database,
but the community seems to be agreeing on Postgres-style
SQL for new products.
So looking ahead, choosing Postgres
will set you up nicely for upgrades in the future.
But of course, every decision that we make here
will be the same for MySQL or SQL Server.
MARTIN OMANDER: All right.
So I'll call my instance poll-database.
There we go.
And I'll enter a super secret password here.
Let's see, secretpassword.
All right.
Now, regarding location, I'm in California,
so I'm physically closest to, let's see, ah, US West.
But to make sure I have the same experience as users
far from California, I think I'll deploy
my app to maybe Europe North.
CRAIG LABENZ: Oh, that's so clever.
By not deploying your app to the nearest region,
you'll be able to see if users far from your servers
have degraded experiences.
MARTIN OMANDER: Yeah, and, of course,
if I know that all my users are in one place,
I would deploy my app to that region.
But I have a question, Craig.
I put this in Finland now.
But can I then relocate my Cloud SQL instance later on?
CRAIG LABENZ: Oh, yes, of course.
Moving your database location is as
easy as creating a read replica in your new region,
waiting for it to catch up to your main database,
and then promoting it.
MARTIN OMANDER: All right, cool.
Next one is database version.
I'll pick the latest available.
Configuration options, it says there.
Oh, there is a lot here.
CRAIG LABENZ: Yeah, there is.
Luckily, they're not too bad.
The first item, Connectivity, offers a lot
of different ways of establishing
a secure connection to your database.
The Private IP option allows you to connect
to a virtual private cloud.
But I don't recommend that for newer apps.
MARTIN OMANDER: OK, yeah, I want to start simple
but in a way that doesn't prevent me
from growing in the future.
CRAIG LABENZ: For sure.
And you can always add a virtual private cloud down the line
should you desire.
So this means the default connectivity options should
be exactly what you want, because Cloud Run
is designed to connect to Cloud SQL right out of the box.
MARTIN OMANDER: Ah, I love it when things
work right out of the box.
OK, so closing connectivity.
I'm opening machine type and storage.
What should I pick here?
CRAIG LABENZ: Now, here, I usually
start with the smallest machine that
qualifies for Google service level
agreement, which is one virtual CPU and 3.75 gigabytes of RAM.
Now estimating hardware needs ahead of time
is extremely difficult for any app,
especially one not yet launched, which
is why we're going to run some load tests.
MARTIN OMANDER: [CHUCKLES] Cool.
So I pick one virtual CPU, 3.75 gigabytes of RAM here.
But what if I find out that I chose the wrong size later on?
What then?
CRAIG LABENZ: Well, if your app can tolerate
a few minutes of downtime, more database power
is never further away than turning off your instance,
resizing it, and turning it back on.
Of course, if your app cannot tolerate a few minutes
of downtime, then the standard workflow is the same
as changing regions.
You create a larger read replica,
wait until it catches up to production,
and then promote it.
Now, next, as for storage type and encryption,
I strongly recommend solid state drives
and Google-managed encryption.
Those are easy wins, and they reduce your headaches.
MARTIN OMANDER: Oh, OK.
Let's see.
So it looks like next is Backups.
Ah, great, looks like backups are on by default.
And closing Backups.
Then we have Flags, Maintenance, Query Insights, Labels.
That sounds like extra credit, so I
think we might be good to go.
I'm clicking Create.
CRAIG LABENZ: You've taken your first step into a larger world.
But say, we've got a few minutes while this database instance
gets created.
Top off coffee?
MARTIN OMANDER: Ah, well, tea for me.
But yeah, that sounds great.
All right, I refilled my tea, and my database is created.
Before we go any further, I'll use Cloud Shell
to create all of my tables.
So if I scroll down here, I can click
Connect using Cloud Shell.
All right, so I'm in, and I'm going
to paste in the statements to create the tables.
There it is.
All right.
So now, my next question is, what values
should I use in my code to connect to my Cloud SQL
instance?
CRAIG LABENZ: Well, usually, you would use your database's IP
address.
But Cloud Run creates a Unix socket
in your running container for each connected Cloud SQL
instance.
This means all that your application code has to do
is to that socket file.
I sent you a working code sample earlier.
Did you get it?
MARTIN OMANDER: Socket.txt-- yeah, right.
This is the one you sent to me, right?
CRAIG LABENZ: Yes.
So with that, you can copy that and go back into main.py.
And you can remove the host and port arguments,
and, instead, supply that copied code
as the path to your Unix socket file.
And like all of our other database connection values,
it's best to read that path from an environment variable.
Now, in Cloud Run the path is always /cloudsql/ your database
connection name, which you can find on your Cloud SQL instance
screen.
MARTIN OMANDER: All right.
So let's see.
I have an environment file here.
I took out host and port.
So, and in my database-- ah, right.
There's the connection name.
Cool.
I'll just copy that.
So that's the connection.
CRAIG LABENZ: Yeah, so you can put
all the values in this file.
And for the database user, we use the default Postgres user
of postgres.
MARTIN OMANDER: Postgres, got it.
CRAIG LABENZ: And I'm sure you remember
your best-in-class password.
MARTIN OMANDER: Ah, yes, uncrackable.
CRAIG LABENZ: And we also use the default Postgres database,
very nice.
MARTIN OMANDER: OK, postgres.
There we are.
All right, so I placed a database username,
and password, database name, and connection name.
CRAIG LABENZ: Now, it looks like we're ready to deploy your app.
MARTIN OMANDER: So I have a script prepared
that handles the entire deployment process.
CRAIG LABENZ: Well, that sounds amazing.
Can I see it?
MARTIN OMANDER: I'll just start it really quick here.
So what this does is, up here, it
sets three environment variables that
would be used further down.
And then it's two steps.
So the first one is gcloud builds submit,
which just packages everything up in this directory
and sends it to Cloud Build, a Google build server
that builds the container.
That's what's going on right now.
And then down here is gcloud run deploy,
which takes that container and deploys it as a new Cloud Run
service.
Also, it includes here add instances flag
that sends along the connection name
so that Cloud Run knows which database to connect to.
CRAIG LABENZ: Wow.
And to think, now, you can deploy your entire app
with just a few key presses.
This is really going to lend itself
to a nice CI/CD pipeline.
MARTIN OMANDER: Hey, it looks like the deploy was a success.
Let's see if it loads.
I'll go to this.
You're all here.
It looks like I've connected Cloud Run, which is serverless,
with a traditional SQL database running on dedicated hardware.
I can scale it up by adding CPU memory or read replicas.
But will I need to do that?
How much traffic can my system handle, Craig?
CRAIG LABENZ: Well all apps are different.
And the only way to know is to run a load test.
MARTIN OMANDER: Sounds great.
Stay tuned for in the next video, where we do that.
[MUSIC PLAYING]