JENNIFER THOMAS: So far we've learned
that a scalable app can gracefully handle
peaks and dips in traffic.
But each application has its own infrastructure
and scaling requirements.
Let's take a look at how Critter Junction launched a new app
and how they chose where to run it.
[MUSIC PLAYING]
With more users than ever and with their new immutable
infrastructure, Critter Junction was in a great place
to launch a new app.
They wanted to launch a companion game that
used the same database but lets you build and share
house layouts using your inventory,
codenamed The Layout App.
With a new app launch, scale and unpredictability
is always a big challenge.
You may never know exactly how many players
will show up on launch day.
They needed to find a solution on Google Cloud that
could automatically handle any amount of load.
The team already knew they wanted a layout app
to scale independently from their web servers,
but they have lots of options.
One solution is to run The Layout App
on a separate set of VMs.
Using Google's Global Load Balancer,
you can send traffic to backend managed instance groups.
These can automatically scale multiple identical machines
based on metrics like CPU utilization.
So they could easily handle more traffic across regions.
But it turned out The Layout App didn't
need to run with access to the operating system.
And the team wanted their apps to be lightweight and portable
across environments.
So they decided to containerize it.
Containers are basically an isolated package
for just running an application.
It's a great way to build a cloud-native app,
but you still need to serve it.
Two choices for serving containers
would be managed instance groups running container-optimized OS
or Google Kubernetes Engines.
Both solutions automatically scale up as demand increases,
adding new machines as needed, and removing them
when demand is low.
This can increase the availability at peak times
while keeping your costs manageable.
Either would work to run their app
and meet their unpredictable scaling needs,
but the team wanted further abstraction
from the infrastructure.
They decided they didn't want upfront provisioning
and wanted the ability to scale down to zero resources.
The next step was to look at serverless tech.
These technologies almost completely abstract away
the infrastructure and orchestration.
Unlike the previous options, these
handle automatic resource scaling
with virtually no configuration or server provisioning.
Serverless mainly keys in on running your application
so you can focus on your code.
Google Cloud has three main options for running serverless.
First up, Cloud Functions is great for snippets
of code and small, single-purpose applications.
Functions scale by creating new instances as demand rises.
And each function handles a single request.
You can scale down to zero and limit
the maximum number of instances for full flexibility.
It's perfect for gluing together different cloud services
like calling an API based on a schedule
or sending notifications.
But it was too simple for running The Layout App, so they
looked to App Engine, which offers the ability
to run containers and custom web applications
in a serverless way, automatically creating
and shutting down instances as traffic fluctuates.
You can configure the settings for automatic scaling
based on your app's needs.
For example, scaling can be based
on CPU utilization, throughput utilization,
or maximum concurrent requests.
This could run their containerized app
without a problem.
But the team wanted to make sure they
could run their app in multiple clouds down the road
and didn't want to re-architect.
Finally, there's Cloud Run, which
is built on a project called Knative.
Knative is all about serverless running of containers
on top of Kubernetes.
But with Cloud Run, all the Kubernetes action
is taking care of behind the scenes.
Each deployment is automatically scaled
to the number of instances needed to handle
all incoming requests.
And it can scale from zero to your specified max instances.
Because the app team expected traffic spikes,
Cloud Run let them keep some idle instances
to minimize cold starts.
And if they wanted to bring in multiple clouds,
they could use the same application and just
leverage Knative.
Given their needs for container portability, fast scaling,
and minimal infrastructure overhead,
the team decided on Cloud Run and was
able to launch faster than they thought possible.
While each option has auto-scaling capabilities built
in, you can decide which of these solutions
works best for the requirements of your app.
Plus, you can use different solutions for different apps,
giving you the power to choose and scale.
Stay tuned to find out what's in store for Critter Junction.
And remember, always be architecting.
[MUSIC PLAYING]