[MUSIC PLAYING]
KENT HUA: Hello, everyone.
Today, we're pleased to present to you Google's framework
to build optimal compute platforms designed
to support the business.
Beyond that, we will discuss how to leverage Google Cloud
platform tooling to optimize for reliability, innovation,
and cost efficiency with GKE.
My name is Kent Hua, and I'm a solutions manager
focused on GKE and modernization solutions.
And with me, we have Fernando Rubbo,
a solutions architect specializing in Kubernetes
and GKE optimization.
So to start, we would like to highlight
that Google's business-oriented compute optimization
framework has three main pillars,
and I will start with discussing the first with a question.
Who knows what Service Level Indicators and Service Level
Objectives are?
How many of you knew that 10 years ago?
Well, it turns out about 10 years ago,
everybody had metrics and practices
to assess the health of applications and production
environments.
But at that time, the community, companies, and teams
were facing a big challenge.
There was no consensus about metrics, practices,
and even technical language across organizations.
That was when Google's SRE team created a framework
with a common taxonomy and published it broadly,
for example, with the books we see here.
The first book introduces the topic of SRE,
the second, practical examples for implementing SRE,
and lastly, best practices and additional insights around SRE.
Now, companies use SRE's taxonomy
to discuss concepts of reliability and responsiveness.
These were learnings that resulted
from many years of working on modern, large, and reliable
systems.
Today, you can assess how reliable your environment is
with only four golden signals.
And as such, signals are available in Google Cloud
platform, for example, in Anthos Service Mesh and Cloud
Monitoring.
By adopting Anthos Service Mesh, Google's mesh platform
based on Istio, you get out of the box
the SRE signals to assess how your services are performing.
For example, you can assess how much load your services
can handle with requests per second.
You can assess if your users are having a bad experience because
of failures with error rate or whether your users are having
difficulties due to applications not
being able to respond in a timely manner with latency.
For that, you just need to set Service Level Objectives,
or SLO, to ensure your workloads meet your business requirements
and alerts to realize when error budgets are running out
before it becomes a problem.
All of this without having to make any changes
to your application running on GKE,
Anthos Service Mesh provides a platform
to operate in a common language of SLI and SLO, paving the way
for reliable and performant systems.
The second pillar in our business-oriented framework
is about innovation.
And the question we have to you is, can you
innovate fast enough for the competitive nature of today
and tomorrow?
Well, this is a tricky question because to answer it,
you need to understand where your organization stands along
with the rest of the industry.
With DORA, known as DevOps Research and Assessment, which
is part of Google, you can measure your team's software
delivery performance, compare the results with others,
and discover which DevOps capabilities
you should focus on to improve.
Since 2014, DORA's team has been publishing the State
of DevOps Research annually.
This program represents seven years of research and data
from over 32,000 professionals worldwide.
It runs academically rigorous research
for DevOps providing an independent view into practices
and capabilities that drive high performance in software
delivery, and ultimately, organizational outcomes.
In addition to business outcome highlighted in the research,
DORA also published a white paper
about the ROI of DevOps transformation.
Beyond cost savings, it discusses
how DevOps if done right can be a value driver and innovation
engine, driving business growth by first improved efficiency
through the reduction of unnecessary rework,
the potential revenue gained by reinvesting the time saved
in new offering capabilities, and improved user
experience by reducing outages and downtime.
Because of this State of DevOps Research,
today, you can assess with only four key metrics your company's
software delivery performance.
Through Cloud Deploy, Google's fully managed
continuous delivery platform that has one of its missions,
making it easier to establish and operate software delivery
to GKE, you can follow some of DORA's metrics
in your delivery pipelines, for example, deployment frequency.
This measures how often an organization successfully
deploys resources to production.
And just for instance, based on DORA's performance reports,
elite performers deliver to production multiple times
per day.
Another metric Cloud Deploy tracks
is deployment failure rate, the percentage of deployments
that have failed.
This helps you measure the reliability of your pipeline
and infrastructure while also providing
a signal if more focus needs to be
made to reduce failed rollouts.
By delivering new capabilities quickly and in a reliable way,
organizations are able to innovate faster and be
more competitive, providing the best experience to their end
users.
Cloud Deploy provides you both automation
and monitoring capabilities for your delivery pipelines to GKE.
I will now hand it off to Fernando
to discuss our last but not least important pillar,
cost optimization.
FERNANDO RUBBO: Thanks, Kent.
As Kent mentioned, our third pillar
is about cost optimization.
And I would like to ask you, how many of you
are concerned about cost efficiency in the public cloud?
How many of you are doing cost optimization
in the public cloud or at least thinking about it
or being pressured to do so?
What metrics should you care about?
Where should you start with?
These are some of the questions that we
have heard a lot recently, and they resemble past challenges
where both infrastructure and platform
teams were struggling to assess the reliability
of their systems.
These only reinforce that cost optimization of public cloud
requires a standard taxonomy.
The lack of such a taxonomy drives
both cultural and tooling challenges for individuals
and organizations.
Google has been working on this problem for a few years
now with the goal of creating an independent framework for cost
optimization of the public Cloud, and of course,
to help Google Cloud customers to easily navigate
their challenges.
And today, we are pleased to bring to you
some of the key Kubernetes insights that
came out of this effort.
Learning from a wide variety of customers
and by running a large-scale quantitative research
internally, we figured out the most important Kubernetes cost
optimization metrics, which are now
referring as the golden signals for Kubernetes cost
optimization.
It's important to highlight that although the research was
run inside of Google, these signals can
be applied to any Kubernetes platform
running on any public cloud.
It's also important to say that we have tested this framework
with more than 100 customers, and we are currently
working on refining our research and its insights
so that we can publish it publicly to all of you.
Similar to SRE in DORA, now the industry
can assess how they are doing on Kubernetes' cost optimization.
The golden signals for Kubernetes' cost optimization
are broken into two groups, resources and discounts.
The first resource-related signal
is workload resizing which assess developers' ability
to set the right CPU and memory for their workloads.
The second signal is demand based downscaling.
This signal requires a shared responsibility
to ensure clusters can scale down into off-peak.
For example, developers are responsible for making
their workloads upscale according
to the demand, while platform admins are
responsible for configuring the clustered scalar to follow
the workload dynamicity.
The third signal is cluster bin packing.
This signal assesses the ability of the team
to place the right parts in the right nodes
so that applications can use all the CPU and memory
available in the cluster.
It's important to highlight that to achieve a good cluster bin
packing, developers and platform admins
should also work together.
Developers need to configure their workloads
to be scheduled in certain set of nodes,
which are usually defined by and provisioned by platform admins.
Last but not least, discounts--
most of the public cloud providers
offer Spot VMs and continuous use discount options.
The discount coverage signal measures the percentage
of either resources like CPU and memory or workloads
like pods that are covered by such discounts.
The same way it happened with other products discussed
in the session, GKE is building out of the box
how the learnings from more than two years
Google is working in Kubernetes' cost optimization.
GKE has already implemented a set of cost insight features,
and those features provide you better visibility
into GKE clusters and workloads.
This visibility allows you to predict
the cost of your clusters even before creating them,
quickly identify optimization opportunities,
and attribute costs to application owners,
opening the doors to implement showback and chargeback
practices.
Moreover, with the current actionable workload
recommendations, developers can right size their workloads
with just what they need without compromising the reliability
of the application.
Finally, GKE cost insights allow different parts
of the organization to take an active role in cost
optimization.
With metrics and recommendations exposed
both on GKE UI and Cloud [INAUDIBLE],,
developers and operators can quickly
understand the actual resource utilization,
waste, and act on it, while fin ops and budget
owners can observe the return of the investment of each team
and make business-conscious decisions.
Today, you can understand how cost
optimized your GKE workloads are right into the GCP Console.
Another way to cost optimize your workloads on GKE
is by adopting our fully-managed Kubernetes
offering, GKE Autopilot.
GKE Autopilot goes one step further
than our standard offering by provisioning and maintaining
all the worker nodes for you and by applying
scaling and security features by default.
However, it's important to remember, it's still GKE.
Whatever you run on GKE Autopilot
works the same on GKE standard.
This makes Autopilot a smart and safe choice for most of you.
When using GKE Autopilot, you get rid
of the biggest source of waste and [INAUDIBLE]..
That is cluster bin packing.
In other words, cluster bin packing
is not your problem anymore.
It's now Google's problem.
Beyond that, you don't pay for the resource
used by the system like operational system, kubulet,
system pods.
With GKE Autopilot, you will only
pay per resource your application's request.
For example, if your application requests 1 CPU
and a 64 CPU node was provisioned,
you will only pay for 1 CPU, while in GKE standard,
you will be paying for what was provisioned.
That is the 64 CPU node.
This makes your billing forecast much simpler
once you don't need to consider cluster dynamicity and waste.
Beyond that, Autopilot provides you many other benefits
that improve your total cost of ownership,
such as reduced operational toil.
You don't even need to care about nodes anymore.
Less required Kubernetes administration expertise--
Autopilot configures all the best practices for you.
And of course, it hardens your cluster security.
Leaving all these boring but very important
tasks to Google's experienced SRE, with GKE Autopilot,
you get lots of time back to focus on what
matters most, your business.
Just to make it a little bit more visual,
these are the efforts required to manage
Kubernetes over-provisioning in any public cloud.
As you can see, it's not a trivial task.
There is a cultural part.
There are many things you need to look at,
and it requires a shared responsibility,
mainly between the developers and platform admins,
which usually are very challenging large enterprise.
Now, see how the adoption of GKE Autopilot
make your life simpler.
As we discussed before, you get completely rid
of cluster bin packing.
And for demand based downscaling,
there is no shared responsibility anymore.
Now, it's enough if developers manage
to make the application scale up and down according
to the demand.
Finally, this is what happens if you also leverage
GKE Cost Insights features.
With Cost Insight, you can tackle both the culture
and rightsizing problems by attributing costs
to application owners and by giving teams visibility
and actual recommendations.
To finalize, let's wrap up the three pillars
of our business-oriented optimization framework.
First, Google has written the books of SRE
to provide a framework for designing and running
reliable systems.
And by adopting Anthos Service Mesh,
you can assess how reliable and performant
your GKE services are.
Second, we are the authors of DORA, State
of DevOps Research, which leads to software delivery best
practice.
And by adopting Cloud Deploy, you
can drive your way for innovation
by delivering to GKE faster and in a reliable manner.
And third, we have run a large-scale quantitative
research which we intend to make publicly available shortly
that figure the golden signals for Kubernetes' cost
optimization [INAUDIBLE].
And you can now assess such signals either
on GKE or Cloud Monitoring.
These three pillars together form the Google's framework
to build optimal compute platforms designed
to support the business where you need
to have reliable systems so that your users are
happy with your services, you need
to have an environment, which allows you to innovate faster
in the current competitive world,
and you need to do all these things
in a cost-efficient manner so that you
don't hurt your business.
Hope you found this useful, and if you
want to learn more about our business-oriented optimization
framework or if you need any help
to optimize your GKE workload, please
use the link you are seeing on this screen.
Thanks for watching.
And thank you, Kent, for joining me today.
Have a great rest of next.
[MUSIC PLAYING]