TONY PUJALS: You've probably heard
about Anthos, Google Cloud's application
platform for modern enterprise environments.
If you want a chance to try Anthos for yourself,
the good news is now you can.
I'm going to show you exactly how easy
it is to get started exploring Anthos using the Anthos sample
deployment.
When we're done, go ahead and follow the link
to our online tutorial, launch your own sample deployment,
and try out Anthos for yourself.
We have a sample application, an online store
that's an example of a modern micro services application that
will run in the multi-cluster Kubernetes environment created
by our deployment.
Everything I show you and more is
published as a tutorial in our online docs.
This is where you want to go to get started.
What I'm going to show you will be running in Google Cloud.
But keep in mind that Anthos is here
to help you build and manage your modern application
workloads running where your enterprise needs them,
whether that's on Google Cloud, multi-cloud,
or in hybrid environments.
This sample deployment has two clusters
for hosting copies of our application services.
There's also a config repo that we'll
use for maintaining all configuration under version
control.
We'll access Cloud Shell from a browser to edit policies
in a clone of the config repo.
We'll push our committed changes to the upstream config repo,
and then they will get automatically synchronized
across both clusters by Anthos Config Management.
Let's dive right in.
We need a project for the services and resources
that the Anthos sample deployment will use or create.
For this tour, we'll start with the new one.
And then let's navigate to the Anthos dashboard.
We'll need to enable the Anthos API.
And then again back at the dashboard,
we can now launch the deployment.
You can click through, accept any defaults.
After around 10 minutes, everything
will be deployed, configured, and running.
After the deployment is finished,
let's go back to the Anthos dashboard
to explore the infrastructure resources that were created.
From here, we can see overall health.
We can go ahead and inspect our clusters
and drill down into individual clusters.
And then head over to Kubernetes Engine,
where we can see more details.
Drilling down into physical nodes.
Or we can see the pods that are scheduled on them.
Or take a look at the actual workloads,
where we can see everything running across all nodes
and namespaces.
Or a specific namespace, like the one for the application.
Now let's take a look at the web front end.
Services and ingress show us a list of all the services
with network endpoints.
Let's filter on istio ingress gateway,
which is the name of the services hosting
the endpoints for our application's front end.
Click on one of these for either of our clusters.
Ingress manages inbound traffic to our application.
And we can see what that looks like by clicking on the exposed
endpoint.
Looks like the application is working.
Let's switch view now.
This web application is made up of a number of communicating
micro services.
So let's see how things look from the internal traffic
perspective of Anthos Service Mesh.
Back at the Anthos dashboard, let's inspect services
managed by the service mesh.
We've got two views available, the default table
view and a topology view.
These views provide a great deal of information
without having to write any custom monitoring
code whatsoever.
The table view presents us with essential service metrics,
like error rate and percentile latency,
while the topology view presents us
with a graph visualization of our workloads and services.
From either view, we have a way to drill down
into a detail page for any service,
as we can see here, using the shipping service.
In this service detail view, we can see telemetry details
that provide an overview of the shipping services performance.
If we use the left nav and click connected services,
we can inbound and outbound connections for our shipping
service.
We can even note that traffic over these connections
is unencrypted by looking at the lock icons.
From these pages, we're able to inspect service mesh details.
But what happens when there's an issue?
Let's check out the monitoring built into Anthos Service Mesh.
At the table view, we can see a summary
at the top of the services we're monitoring with the service
level objective, or SLO.
Right now it looks like none are being
monitored for performance.
So let's fix that.
We'll click into the shopping cart service
to create an SLO using latency as our indicator performance
and choosing a very low threshold, like five
milliseconds with a goal of 90% compliance
over a one-day rolling period.
This will let us see an example of what
it looks like when we have service performance that
exceeds our daily error budget.
After we submit this SLO, we can easily
see it in the health panel.
Let's go back to our services table.
We can see that we've now upgraded to have
only 10 services without SLOs.
For the shipping cart service with an SLO,
we can see that our intentionally aggressive
objective has put us past our error budget.
Now let's look at how to better secure our service traffic.
As an e-commerce application, data security
is critical to our enterprise and customers.
We need to ensure our services are only
using encrypted traffic.
But recall that we noticed earlier our shipping service
had an open lock, revealing that unencrypted traffic can
pass through.
Anthos lets us easily fix this with an encryption
policy applied through configuration
so we don't even have to touch the service code.
Let's activate Cloud Shell so we can make some changes
to configuration.
To be able to access our project and make changes from the Cloud
Shell environment, we'll need to ensure that we
have a few tools installed.
We'll be using kubectl, a clone of our configuration
repository, to synchronize our changes and the kubeconfig
environment for our project.
We'll source an initialization script
into our shell environment that takes care of all of this
for us so we're ready to go.
Once this is all done, let's head to the config repo
clone directory.
Then let's use integrated editor to quickly edit
our mesh policy.
So we can tighten up our restrictions
by getting rid of permissive mode
and by requiring mutual TLS for all matching hosts.
After we make these configuration changes,
we'll nomos vet to ensure there aren't any other issues.
Once we push our changes to the upstream repository with git,
Anthos config management will quickly detect and apply
the changes to our clusters.
We'll run a little function helper
to go ahead and watch for those changes here.
And that's how easy it is to apply a policy
and have Anthos Config Management synchronize it
across all the clusters in your environment.
Finally, we can return to the connected services view.
And after enough time passes for the desired span,
we can visually confirm that we only
had mTLS traffic with the green locks for connected services.
There are plenty of examples of security guard rails
you can set to protect your application
environment with Anthos.
Start with a tutorial and check out the docs to learn more.
We've just taken a short tour of Anthos
using a sample deployment.
This is just a taste of things for you to try.
So check out our tutorial, launch a sample deployment,
and explor Anthos for yourself.