Modern applications are increasingly growing in complexity. Adding a dizzying amount of moving parts, layers of abstraction, reliance on external systems and distribution that all result in a stack that few truly fully understand.
Any developer worth hiring now knows the merits of a thorough testing regime, but one of the issues with testing is that you are often testing for predictable outcomes. Despite our ‘logical systems,’ show-stopping issues are typically unexpected; situations that no one foresaw.
These unforeseen eventualities are what chaos engineering attempts to account for. It’s a reasonably new principle, practiced by Netflix for several years and then formalized in 2015, setting out its principles in a time-honored manifesto.
Naturally, there are critics of the practice, and the comments at the bottom of this TechCrunch article summarize some of them. The typical counterarguments are that the principle is a band-aid for applications that were poorly planned and architected in the first place, or that it’s another buzzword-laden excuse to invent shiny new tools that no one knew they needed.
Still, it’s proponents are a friendly bunch, so in this article, I summarize my findings on the practice and let you decide.
Read the full article at: blog.codeship.com