>> Welcome to this week's episode of the DevOps Lab.
We're going to be featuring a brand new product launch
into Azure, Azure Load Testing.
Tune in and hear all about it.
[MUSIC]
>> Welcome to this week's episode of the DevOps Lab.
We have an awesome episode for you
with a brand new feature in Azure.
First, let's welcome John Stallo. Welcome, John.
>> Hi, April. Thank you for having me on.
>> Great to have you here. I'm really
excited to talk about Azure Load Testing.
Can you take it away and introduce everyone to
this brand new feature in Azure that has just been released?
>> Yeah. We're pretty excited.
Azure Load Testing is a new service that we
just launched public preview just a few months ago.
>> Awesome.
>> It's really designed to help developers and testers gain
confidence in their application's performance,
in their ability to meet demand.
Needing that confidence comes in a few forms.
The first example would be,
leading up to a really important event,
it could be like a sales event,
tax season, any way
your application really needs to be
ready right from the get-go to meet high customer demand.
Or it could actually be much
earlier in the application lifecycle,
it could be when you're proving out your architecture,
you might be taking on the new dependency,
you might be using Azure service that you've never used before,
and you're really trying to learn how to use it more effectively.
>> Absolutely, and I think we see so many use cases in
the Cloud where we either as a developer,
we deploy a new feature to something in
Azure and we're using a new service,
might be platform in service or virtual machine,
and we need to know how that application is
going to perform and how it's going to scale.
You're exactly right, especially people going to the Cloud.
They're like, how do I resize this VM?
How do I put this into PaaS?
How do I transform my application?
I'm really excited to see how Azure Load Testing works,
because I think there's so many use cases for it in Azure.
>> Yeah, absolutely.
In all those cases,
you really just want an easy way to be able to simulate
real world traffic and then really importantly,
you want to be able to learn how
your application is behaving under stress.
Can I show you how easy it is to get
started with Azure Load Testing?
>> I would absolutely love to see it.
Really excited to see it. John, take it away please.
>> Awesome. I'm right here in the Azure portal.
Azure Load Testing is
a service where you can just go out and create a resource here,
and then you can just
simply search for Azure Load Testing testing right here,
you'll be able to get started right away.
Now what that does,
is it creates a low testing resource.
Think of it as a hub where you can add all of your tests,
you can manage access to those tests,
you can view historical results and everything.
We want to be able to get a load test up and running quickly.
Let's just go create a new test,
I'll give it a name.
Then as part of the test plan,
I upload a JMeter script that I
would have already developed on my machine now.
JMeter is a very popular open source load testing framework,.
It has a really large community,
it's very easy to be able to go and get
help to get started with creating a load test,
a lot of extensibility built-ins for you to
be able to get extensions that the community has already built.
Now that I've uploaded my JMeter script,
really that's all that I need.
I just want to show you one more thing,
Azure Load Testing makes it really easy to be able to
scale out and achieve really high traffic.
That is as easy as you just being able to scale
out your engine instances all the way from one to many,
and we'll take care of all the heavy lifting of the infrastructure
required to be able to run high traffic load.
With that, I'm going to go ahead and just
go and create that load test.
What that does is that is now getting things ready in the service.
You can see over here it's actually
provisioning those load test engines that I requested,
and we will see the load test begin very shortly.
Then what we can see is
the load test has actually started executing,
and so down below here,
I can see a few things already.
There's a few metrics that I get in
real time as the load test is actually running.
Here on the left hand side,
you can see that my load test is
slowly ramping up to be able to simulate
more virtual users that would
be running my application at the same time.
As that is ramping up,
I can see what my response time looks like across different types
of requests that are being simulated.
You can see that I had a bit of a cold start there,
but then it's settled down into like
pretty comfortable territory in terms of your response time.
I also see requests.
I get to see any errors that my application might be experiencing.
Actually, you can see that just popped up right there.
It seems like that at some point,
as the number of virtual users has
been increasing and running my application,
two things I just noticed right away,
the response time jumped up to now between 4-5 seconds,
which is a pretty long time,
and now I'm also starting to see errors as well.
Even now, I'm already learning that my application
may not be handling load at a certain load point.
>> Absolutely. This is great to see
because I think so many times we deploy something
and we struggle to see
how some things correlate in their applications,
or we have to use real time data
and at all times we try to emulate traffic,
but this is awesome to see to get that correlation right there.
I assume we could upload
another JMeter configuration file that will allow us
to get a different usage pattern
potentially on our application as well.
>> Yeah, that's absolutely right.
There's a lot of things you could do with JMeter.
This whole thing of ramping up and
then sustaining some peak was really just in my JMeter script.
I can do all sorts of patterns like
maintain a certain load and all of a sudden spike
up and really understands how's my application
behave under those fluctuations of traffic.
Now at any time during the load test,
I can stop this right
away just in case things are going horribly wrong.
You've got total control over what happens.
At this point my load test has actually ended here.
The next things I'd like to show is how
Azure Load Testing helps you understand
how your application actually behaved.
We already know that at some point
of load that my response time I'm seeing some errors creep in.
But what I know about my application
is that there is a web app or an
API that is taking in these requests and
then it's actually making some calls to a backend service.
There's all sorts of questions that I would have at
this time of which of
these application components is actually
under stress and causing this kind of behavior?
One of the things that is down below
here is what we call server side metrics.
If I click on this "Configure up
components," what I see here is just the ability to be
able to go and search across subscriptions, resource groups.
At this time I know that this application that I'm testing is
actually deployed to this resource group
and here you can see that there's an app service resource,
which is my web API,
there's a Mongo Database that's in Azure Cosmos DB.
I also have application insights which
is the telemetry that I'm using for my application.
Then I can choose now to add all of
those server metrics to this dashboard.
Now when I scroll down,
not only do I see all the JMeter metrics that I saw before,
but now I can see how my application components,
the web API, the database all behaved under load.
>> Awesome. You get a lot more granular and pick
a part that application stuck and figure out
where that failure is occurring,
where the bottleneck's occurring.
>> That's right. Let me just take you
to a example here of a load test that I ran before.
If I open that up we'll see that I ran a similar test like before.
This one actually gave me a few clues.
In terms of my web API,
I can see that the CPU and memory were doing okay.
I started to see some CPU spikes starting to appear later on,
but that might not fully account for the issues that I was seeing.
But if I look down at my Cosmos DB,
I can actually see that my IU utilization,
meaning how much stress
my database was under actually started to really peak,
and and then you add 100 percent.
That has already given me clues of places to look
at to really help my application's scale.
>> That's really cool. I think that gets
some really good insight in the throughput of the application.
It's super clear we.
Can pull us up for reporting.
We can leverage this further,
when we're building our apps,
we're building new stuff.
I assume we can pull out
some reports as well and hand that over to anyone,
the organization that needs proof that our
application's not doing what's supposed to do.
>> Absolutely. Yeah. You can share these reports.
You can compare a load test that you ran last night
to what it looked like
a week ago or two weeks ago before you began a sprint.
All of those ways of
comparing important metrics really tell you a lot
about what's changing in your application and
your ability to be able to meet that demand.
>> Testing is so critical when we're developing our applications,
and it's something that we a lot of times forget or
bypass because it's sometimes hard to do or hard to implement.
This looks really easy. Now I want to take this a step further.
Can we integrate this into a CI/CD pipeline?
>> Definitely. That's actually something that we
see that a lot of teams are increasingly doing.
One of those important confidence levels
that I was talking about before,
is really being able to find and
block performance questions as soon as possible.
We see teams actually integrate
load testing as part of their CI/CD pipeline.
With Azure Load Testing,
you can add load tests
or you can trigger load tests from GitHub actions,
from Azure pipelines,
so that you can run,
let's say at the end of a sprint or before
or as code is deployed to say a staging environment.
You'll be able to really compare the application's performance
right as soon as you deploy it and to be able to
learn whether you've regressed
and need to maybe block that deployment.
>> Awesome. John, I love this.
Really excited to see this come out as a product.
It's something that our customers have asked for.
We talk about testing as being such a critical part,
not only the DevOps process,
but part of the Cloud process.
Thank you so much for showing this to us today.
Really appreciate you being here, John. Thank you.
>> Thank you, April. Take care.
[MUSIC]