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

## Destruction for a positive outcome

There are very few things as satisfying as destruction, especially when we’re frustrated.

How often do you have an issue that you cannot solve and you just want to scream or take a hammer and destroy servers in your datacenter? Or how often do you have a problem in production that is negatively affecting a lot of users, and you are under a lot of pressure to solve it but cannot “crack” it as fast as you should. You have probably experienced this at least once. If something like this has never happened to you, then you have probably never been in a position under a lot of pressure. However, in my case, there have been countless instances when I wanted to destroy things out of frustration. But I didn’t, for quite a few reasons. Destruction rarely solves problems, and it usually leads to negative consequences. I cannot just go and destroy a server and expect that I will not be punished. 


## The goal of chaos engineering

However, what would you say if I told you that we can be rewarded for destruction,  and that we can do a lot of good things by destroying stuff? If you don’t believe me, you will soon. That’s what chaos engineering is all about. It is about destroying, obstructing, and delaying things in our servers and clusters. We’re doing all that, and many other things, to achieve a very positive outcome.

Chaos engineering tries to find the limits of our system. It helps us deduce what the consequences are when bad things happen by trying to simulate the adverse effects in a controlled way. We do this as a way to improve our systems and to make them more resilient and capable of recuperating and resisting harmful or unpredictable events.

That’s our mission. We will try to find ways we can improve our systems based on the knowledge that we obtain through the chaos.

---

The next lesson contains an introduction to the authors.

# Destruction for a positive outcome

There are very few things as satisfying as destruction, especially when we’re frustrated.

How often do you have an issue that you cannot solve and you just want to scream or take a hammer and destroy servers in your datacenter? Or how often do you have a problem in production that is negatively affecting a lot of users, and you are under a lot of pressure to solve it but cannot “crack” it as fast as you should. You have probably experienced this at least once. If something like this has never happened to you, then you have probably never been in a position under a lot of pressure. However, in my case, there have been countless instances when I wanted to destroy things out of frustration. But I didn’t, for quite a few reasons. Destruction rarely solves problems, and it usually leads to negative consequences. I cannot just go and destroy a server and expect that I will not be punished. 


# The goal of chaos engineering

However, what would you say if I told you that we can be rewarded for destruction,  and that we can do a lot of good things by destroying stuff? If you don’t believe me, you will soon. That’s what chaos engineering is all about. It is about destroying, obstructing, and delaying things in our servers and clusters. We’re doing all that, and many other things, to achieve a very positive outcome.

Chaos engineering tries to find the limits of our system. It helps us deduce what the consequences are when bad things happen by trying to simulate the adverse effects in a controlled way. We do this as a way to improve our systems and to make them more resilient and capable of recuperating and resisting harmful or unpredictable events.

That’s our mission. We will try to find ways we can improve our systems based on the knowledge that we obtain through the chaos.

---

The next lesson contains an introduction to the authors.

This lesson briefly explains the goal behind chaos engineering.

Before We Begin

Introduction To Kubernetes Chaos Engineering

Defining Requirements

Destroying Application Instances

Experimenting with Application Availability

Obstructing and Destroying Network

Draining and Deleting Nodes

Creating Chaos Experiment Reports

Running Chaos Experiments Inside a Kubernetes Cluster

Executing Random Chaos

Conclusion

A Brief Introduction to Chaos Engineering

Destruction for a positive outcome