Improve Application Resiliency with Chaos Testing

What is Load Testing in general?

What about load requirements?

One of the difference between load tests and other testing types is how we define error conditions.

What are the different types of load tests and how they can be best described using throughput and duration of each test?

Is load testing same as performance testing?

What are the myths behind load testing?

Complex software architectures makes it difficult to predict failure modes under extreme load. This is the reason that we need to implement and integrate a testing process as early as possible in the development cycle.

k6's approach is different. k6 is best used for continuous, iterative testing.

See, when you think of testing as an activity done at the end of every release, it's a heavy lift - something that requires a lot of upfront effort - and one that is completed before the release goes live.

Instead, the k6 way of testing is more like rolling a snowball. You start small, addressing the most pressing issues or risks, and ship it by pushing it down the hill. As it falls, however, it picks up steam– just like your test suite should grow alongside your application.

What are the few characteristics that Grafana k6 has that makes it stand out from other load testing solutions?

Everyone says that reliability is the most important feature. Is that true? What is true is that it is hard nowadays!

xk6-disruptor is an extension that adds fault injection capabilities to k6. It implements the principles of the Chaos Engineering discipline to test the reliability of our applications under turbulent conditions such as delays and response errors.

Key features include:

• Everything as code. Facilitate test reuse and collaboration between teams without learning a new DSL.

• Fast to adopt with no day-two surprises. No need to deploy and maintain a fleet of agents or operators.

• Easy to extend and integrate with other types of k6 tests. No need to try to glue multiple tools together to get the job done.

Why reliability is hard and what are the key ingredients of the chaos engineering?

In this lecture we are going to learn how to :

• Use Prometheus as an output in K6

• Use Grafana to visualise that output coming from K6

• Use execute K6, Prometheus & Grafana

In this lecture we are reviewing the four distinct lifecycle stages and why they are important for test execution.

In this section we are going through different type of metrics k6 supports and provide practical examples.

We successfully build our very first web service and deployed to local k8s. The service is get current timestamp API.

Structure to be added:

• deployment.yml

• service.yml

• main.go

• go.sum

• go.mod

• Dockerfile

We successfully build our consumer API service.

Structure to be added:

• deployment.yml

• service.yml

• main.go

• go.sum

• go.mod

• Dockerfile

Now let’s implement the chaos testing scenarios. We will try to inject faults to the get current timestamp API using ServiceDisruptor and see how the consuming API responds to those injection faults.

To make the consuming API more stable and fault-tolerant, we need to apply a retry mechanism for the consuming API so that when it receives the 500 status code from the get current timestamp API, it will try to make another request.