DEREK DOWNEY: Hi, I'm Derek Downey,
a Developer Advocate at Google.
I am currently working on developing a banking
application that leverages Cloud Spanner for its ability
to seamlessly scale without losing
strong external consistency.
In my last video, I highlighted how simple
it was to get started working with the Spanner
Emulator running on my own device
to run my basic banking app that's in development.
Now, I want to connect to a real Spanner instance
so it can be used for development by my team.
In this video, I will dig deeper into what a Spanner instance is
and the different options available
when creating an instance.
[MUSIC PLAYING]
Like all other Google Cloud products,
Spanner instances must be created inside a project.
So my Spanner instance will be created in my organization's
development project.
For Spanner, an instance refers to an amount
of compute and storage capacity that you get access to.
An instance will have at least three replicas
created, depending on which configuration you choose.
This means that Spanner provides high availability by default.
Each instance can have multiple databases,
depending on your needs.
For my banking application, I will create a single database
for customers and their transaction.
The cost of this instance is determined
by how much compute capacity I provision, how much storage
my database uses, how much storage my backups use,
and finally, how much network bandwidth I use.
As I get started on this application,
the largest cost will come from the compute capacity itself.
The compute capacity cost is determined
by both the number of nodes and the configuration
that I choose.
I should mention that in Spanner, nodes
is the measurement of how much compute capacity that
is provisioned for my instance.
This setting has no bearing on how many replicas I get.
I will always get at least three replicas.
Since I am just getting started with this application,
a full node of compute capacity is too much.
Luckily, I can go smaller than a single node
by using processing units instead.
1,000 processing units is the equivalent compute capacity
of a single node in Spanner.
And I can provision these in increments of 100.
So I will create my instance with 100 processing units,
which gives me roughly 1/10 the compute
resources of a single node at 1/10 the cost.
Besides sizing, the other important factor
for creating a Spanner instance is the configuration.
The configuration determines how many replicas I get
and where they are located.
It also determines the type of replicas
that are handled by Spanner.
And luckily, as a developer, I don't
have to manage the replicas.
They are completely managed by Spanner.
There are two types of configurations in Spanner--
regional and multi-regional.
For regional configurations, I would
get three read-write replicas in the region I choose.
Read-write replicas participate in votes to commit rights,
and these replicas can also be promoted to leader
for high availability.
A regional configuration is a good option
if my application will be operating
within a single region.
I want to choose a region where my application is located
to reduce request latency.
To achieve higher availability, though, I
would consider a multi-regional configuration.
These configurations provide read-write replicas
in two regions, as well as maintaining a witness replica
in a third region.
Witness replicas do not contain any data,
but they do provide votes for quorum.
Also, witness replicas can never be promoted to become a leader.
Some configurations also offer read-only replicas
in additional regions.
These replicas contain a full copy of data
so that they can reduce read latencies in that region.
However, they can never be promoted as a leader,
and read-only replicas don't participate
in voting to commit rights.
So they don't impact write latency performance.
Multi-regional configurations are a great way
to achieve the highest availability
for your Spanner-backed applications.
It's important that applications are effectively
deployed in the appropriate regions
to take full advantage of the configuration.
You can get more information on available Spanner
configurations from the link in the description.
For my development application, I'm
going to create a regional configuration in US Central 1.
All right, so to create my instance,
I provided a size and a configuration.
All I need now is to provide the name
and an optional description for the instance.
Then I can create it.
Once the instance is created, I will
need to update my application to use it.
To connect to Spanner, I will need the project ID
for the project that my Spanner instance is located in.
I will also need the instance ID.
I also need to authenticate my machine
to be able to work with the project resources.
I do this using the gcloud command.
Now, in Intellij, I will create a new data source
and point my new Spanner instance using the project
and instance information.
The URL connection string is different,
as it no longer points to the Emulator.
And there-- it's connected.
Now I will need to modify the application
code with the project and instance information.
If I run my commands to create the database,
it will create the customer table
on the development Spanner instance that I just created.
Now, we have our banking application
using a real Spanner instance instead of the Emulator.
My team can start using it today.
My instance is a regional configuration
with a small amount of compute resources for our development
needs.
Choosing the right configuration is important.
So I have provided additional resources
on Spanner configurations in the video description.
These resources can help you decide
which configuration might be the right one for your application.
In our next video, I will dig deeper
into what database options exist for Spanner.
In the meantime, please let us know
if you have any questions about Spanner instances,
costs, or configurations.
[MUSIC PLAYING]