In June Benjamin Wilms from codecentric presented in our User Group about why we need Chaos Engineering.
He stated, that the complexity in modern and distributed architectures still continues to increase. And there are approaches to successfully brake down an application into small and maintainable components. Each individual component can be automated and brought into production at any time. A lot of effort was put into the development to keep the test coverage as high as possible. Every release has to successfully pass our pipeline and countless unit, integration and acceptance tests.
But why do we have this unpleasant feeling shortly before our arrival at the most beautiful place in the world (production)?
It helps us to become master of chaos and please do not claim that you are not in chaos! There is a whole industry that sells us ticket systems to document chaos.
Many open questions cannot be answered by simple unit or integration tests:
- will our fallbacks work?
- does the retry take effect in case of an error?
- is our Service Discovery up and synchronised?
- has anyone seen our client-side-load-balancer in action?
- where’s our database gone?
This is where Chaos Engineering comes in.
Chaos Monkey Toolkit: