(bright music)
- [Rafael] Hello, and welcome to a new video series.
focusing on Amazon DevOps Guru,
a machine learning powered service from AWS,
helping developers
and operators automatically detect anomalies,
and improve application availability.
My name is Rafael Ramos.
I'm a senior solutions architect with AWS,
and I'll be leading you through this first episode.
In this introduction, we'll establish a foundation
about how AWS is bringing AI and ML
into the development, and operation workflows,
to materialize what we call NextGen DevOps.
We also cover the basic concept of DevOps Guru,
and typical use cases.
In subsequent episodes,
we'll dive deeper into concepts, best practices,
and how to use DevOps Guru in specific contexts.
Regardless of whether you are a small business,
or an enterprise,
applications are becoming more distributed and more complex.
Because of this, maintaining and improving
application availability,
and resolving operational issues is difficult.
Solutions, demand additional dashboards, alarms,
and metrics, that allow you to monitor
all the IT resources and applications.
Every time you add a new service or resource,
you need to complete the observability coverage.
This entails manually enabling monitoring,
configuring all the alarms, and setting various metrics.
You also need to define different thresholds
for alarms, which is a very tricky task.
From an operational perspective,
configuring all that manually,
and collecting aggregated metrics
from so many different resources can be overwhelming.
When an issue occurs,
there are multiple alarms you must deal with.
Then you need to stitch together all the various data points
and correlate the failures with potential causes
for the issue.
This process usually takes a significant amount of time.
And because of that,
your meantime to recovery or MTTR, is affected.
Your customers are then impacted with downtime,
or poor user experience.
Think about the number of alarms, metrics, and traces,
that an operator must track,
in order to find the root cause of an issue
on a microservices environment,
with dozens, or hundreds of applications.
Then, think about the number of alarms and thresholds
you need to enable just to have full coverage.
This is why Amazon DevOps Guru was created.
With its ML based anomaly detectors,
DevOps Guru makes it easy
to improve application availability,
nd this is the key aspect I want to highlight
in this introduction.
Our approach towards NextGen DevOps
is to apply machine learning
to operational data from your AWS resources.
So when an anomalous behavior is detected,
instead of having noise from several different alarms,
DevOps Guru provides an intelligent digest
of various events and anomalies that you can use
to quickly find the root cause issue,
and reduce the MTTR.
DevOps Guru is a fully managed service,
which means you don't need machine learning expertise.
It uses pretrained models,
informed by years of experience
from amazon.com, and AWS operational excellence.
These models can identify anomalous application behavior
such as increased latency, error rates,
and resource constraints,
and surface critical issues
that could cause potential outages, or service disruptions.
You don't have to manually configure
tons of alarms and thresholds across your AWS resources.
With these pre-trained ML models,
DevOps Guru implicitly sets thresholds dynamically,
based on the behavior of the application,
and alerts you
only when the implicit thresholds are breached.
For example,
if your application typically handles
10 requests per second,
and suddenly the number of requests increases to 1000,
you might be under DDoS attack,
and DevOps Guru will notify you.
On the other hand, if these 1000 requests per second
become the standard traffic,
you don't have to change the threshold manually,
because DevOps Guru anomaly detectors
will adapt accordingly.
Enabling DevOps Guru is as simple as clicking a button,
and providing guidance about your application boundaries.
To understand the applications' behavior,
DevOps grew automatically starts
to monitor the AWS resources,
by ingesting CloudWatch vendored metrics
and AWS CloudTrail events.
On its dashboard,
DevOps Guru doesn't display fancy graphs, charts,
or running counters.
This is by design,
because we want to upload you
from monitoring the system's health.
DevOps Guru takes care of this aspect,
and only notifies you when an anomalies detected.
When this happens,
DevOps Guru correlates issues, and trails,
to provide you with a meaningful sequence of events,
which is called an insight.
Instead of dealing with multiple alarms
that don't pinpoint the symptoms,
and root cause of an issue,
a DevOps Guru Insight
groups together the information you need
about the failing resources,
and provides prescriptive guidance,
with recommendations to resolve the issue quickly.
Now let's look
at how DevOps Guru works behind the scenes.
This diagram depicts a simple serverless application,
defined by CloudFormation template.
After it's deployed, the CloudFormation stack
defines the application boundaries for DevOps Guru.
This application has three main components
we can see in the diagram:
an API gateway endpoint,
that invokes a lambda function
to process the business logic,
in a DynamoDB table, where we store the data.
Let's say that someone
accidentally updates the DynamoDB table
to reduce its read capacity.
At the same time,
there is a surge of HTTP traffic to the application.
Eventually, the DynamoDB table will be throttled,
because it can't keep up with the new number
of read requests.
In this hypothetical scenario,
the operator would see all three components failing.
The DynamoDB table would be throttled.
The lambda function would have failed executions,
and the API gateway endpoint would respond
with 500 HTTP errors.
To resolve this issue,
the operator would need to understand
the root cause of the issue,
and what the side effects are.
In this case, even though the lambda function,
and the API gateway endpoint, are both failing.
they're just side effects of the root cause
which is the reduced capacity of the DynamoDB table.
After resolving the incident,
the operator would have to spend more time on a post mortem,
to identify the read capacity
of the DynamoDB table being decreased,
because of a bug in a previous application release.
This is how DevOps Guru can help you
with machine learning based anomaly detectors.
It monitors your application,
by ingesting operational data
coming from CloudWatch and CloudTrail.
In this example, DevOps Guru checks the relevant events
on CloudTrail, and compares them
with the operational metrics from CloudWatch.
Based on this data, when it detects the anomaly,
it creates an insight, which presents the relevant metrics,
so the operator can quickly find
and fix the root cause of the incident.
Taking it a step further, the DevOps Guru
can identify that someone has changed the DynamoDB table
read capacity, just before the anomaly was detected,
and recommends rolling back this change.
One thing to keep in mind
that after DevOps Guru is enabled,
it takes at least 24 hours
to create a reliable behavior baseline of the application.
Let's take a closer look
at how to enable DevOps Guru on the console.
Navigate to the settings,
and you'll be able to enable it with just a few clicks.
You can either choose to analyze all AWS resources
in the current AWS account and region,
choose specific CloudFormation stacks,
or AWS tags, to define your coverage boundary.
Let's select choose layer, and click enable.
Now we can see the DevOps Guru dashboard.
As a summary, it displays the number of resources analyzed
in the last hour, as well as ongoing and impacted insights.
We haven't selected our coverage boundary yet.
Let's do it now,
by selecting which CloudFormation stack we want to monitor.
Click on analyze resources.
and then on the manage AWS resources selection button
let's select the option to analyze all AWS resources
in the specified CloudFormation stacks in this region
and select which CloudFormation stack we want.
Then click on the save button, and confirm.
DevOps Guru is now monitoring the resources
from that CloudFormation stack,
and will create an insight every time it detects an anomaly.
You probably want to be notified when an anomaly occurs.
If we go back to settings,
you'll see an option to set SNS notifications.
Click on set up notifications, add SNS topic,
and create a new SNS topic.
Give it a name, and click save.
Now every time DevOps Guru creates an insight
it'll send a notification to this SNS topic.
If DevOps Guru sounds like something you want to try,
you can start with the free tier.
At the time of this recording
the free tier includes analysis of 7,200 AWS resource hours,
for each resource group A and B,
and usage of 10,000 DevOps Guru API calls per month,
for three months.
And one last thing.
DevOps Guru has a cost estimator tool.
If you want to know how much
monitoring a CloudFormation stack will cost you,
go to the tool, select a stack,
and click estimate monthly cost.
Lastly, I want to leave you
with links to a few additional resources.
The developer documentation includes detailed information
how to use DevOps Guru and its APIs.
We also regularly publish blog posts
that go into detail on new features and scenarios.
And since it can be useful to have hands-on experience,
we have a workshop where you can get started,
and see DevOps Guru in action.
I hope this episode gave you a good sense
about how DevOps Guru applies AI and ML
into your development and operations workflow,
to improve your applications availability.
Please join us for upcoming episodes,
where we will dive deeper into specific topics
related to DevOps Guru.
You will see insights in connection,
and how it's applicable for containers, databases,
and serverless.
Thanks for watching.