Level-up your testing with Chaos Engineering. Learn how pushing your programs to failure can help you plan your improvements.

DevOps for Developers

Let’s face it, bad things happen in software engineering, often when you least expect it. Servers go down, there are spikes in traffic, you receive networking errors. Luckily, you can avoid these problems. Enter chaos engineering.
Chaos engineering is where you try to find the limits of a system and simulate adverse effects that might happen. These simulations then help you to determine the best way to improve your system and build up its resiliency.
This course is divided into various sections to get you used to the different types of experiments you can run in chaos engineering. You will start by learning how to destroy application instances in order to show you the importance of scaling, fault tolerance, and high availability.
You will then dive deep into other types of experiments such as destroying a network, draining and deleting nodes, and testing availability. Towards the end of the course, you will learn how to run experiments in a Kubernetes cluster.

Kubernetes Chaos Engineering

# Requirements for picking the tool

Before we start defining and running chaos experiments, we need to pick a tool. Chaos engineering is not yet a segment of the market that is well established and developed. Nevertheless, there are several tools we can pick from. We cannot use them all, at least not in this course. It would take too much time, and the course would never end. So, we’ll have to just pick one.

Before we select a tool, let’s go through a couple of requirements that I believe are important.


## Open-source

The tool should be open-source. I am a huge believer in open-source. That does not mean that everything that we use should be open-source. There is a time and place when we should use enterprise editions of the software, and there is a time and place when we should use a service. However, in this case, I wanted to make sure that it is free that it is open. So, open-source is a requirement, at least for this course.

## Work inside or outside Kubernetes

As long as it is possible and practical, the tool should work both inside and outside Kubernetes. Even though this course is focused on Kubernetes, it would be great if we could pick a tool that can do chaos engineering not only inside Kubernetes but also outside. You may want to destroy nodes directly, or you may tweak some other aspect of your cluster and your infrastructure in general.

# Why are we focusing on Kubernetes?

That begs the question. Why are we focused on Kubernetes, even though we want a tool that works both inside and outside Kubernetes? If I show you how to do chaos engineering on AWS, then you might say that you need examples in Azure. Or, you might prefer Google or an on-prem cluster based on VMware. It would be close to impossible for me to provide examples in all those (and other) platforms. That would require multiple courses. So, I did not want to focus on a particular hosting platform (e.g., only AWS, or only Azure) since that would not be inclusive. I wanted to make the scope as wide as possible. Therefore, the course is focused on Kubernetes, which happens to work (almost) anywhere. Everything you learn should work, more or less, in any Kubernetes distribution with any hosting provider.


---

In the next lesson, we will discuss some of the options that we have in tools and choose the one we will be using in this course.

The requirements of picking the right tool to use are discussed in this lesson.

The Requirements Guiding the Choice of a Tool

Requirements for