Chaos Engineering is a technique by which you can measure the resilience of your architecture. We will inject Fault and then we will check how the services react.
Chaos and discipline, These two words are an oxymoron, you might be thinking, how can chaos make disciplined microservices?
But the universal truth is discipline means the absence of chaos, so until you have not experienced chaos you can not be disciplined.
If we think about the Law of Entropy, then chaos is the high entropy state, and discipline is the low entropy state. Always disciplined services degrade to chaotic ones to make the system in equilibrium, as the flow of the direction is from high (chaos) to low entropy (discipline) state. So chaos is inevitable.
Now, If we want to make sure our services remain in a low entropy state (discipline) throughout, we need to adopt a few special techniques. As per the laws of physics, this is an irreversible process (flow from low to high entropy state), it is going against entropy we called it reverse entropy (watch Christopher Nolan Masterpiece TNET!!!)
A refrigerator is a reverse entropy object (doing cooling), the crux is to maintain discipline in your services we need to adopt a Resilience strategy but the question is how to determine what resilience strategy needs to be adopted? For that, we have to experience chaos in production and act accordingly.
This is the essence of chaos engineering, by injecting mild fault into the system to experience the chaos and take preventive measures and self-healing against it.
Today I am talking about implementing chaos in production!!!
After hearing this you might think what I am saying? Am I insane? I am encouraging implement chaos in production, which is the most emotional and sensitive area of a developer, we are all praying whatever the error comes, please those come before production. In production, if something goes wrong your organization’s reputation at stake, your organization loses user base, revenue, etc., and I am encouraging you to implement Fault/Chaos.
But the irony is we have the wrong mindset, our mindset should be ‘Failure is inevitable and we must prepare for it’. In this tutorial, I am advocating for this culture.
A Simple Microservice Definition
Microservice Architecture is distributed in nature and it consists of suites of small services which can be scaled and deployed independently.
If we deduce the above statement we will find 3 important things:
- As Microservice is distributed, it is communicated over the network, and the network is unreliable so how come your Microservice will be reliable?
- Over the network, Microservices are communicated to each other so they are dependent on each other, so they can fail if their dependent services fail.
- Microservices Scaled and deployed on infrastructure so if infrastructure fails your Microservices will fail.
These points justify the ‘Failure is inevitable and we must prepare for it’ statement.
But the question is how do we prepare for it?
The answer is Chaos Engineering.
#microservice #chaos-engineering
