Chaos Monkey can conceivably help any organization that deploys applications via the cloud. So should you turn the monkey loose? Small and midsize businesses (SMBs) that beg off testing for budget reasons, for example, can't argue with Chaos Monkey's price tag. But MacLeod's not too sure many SMBs are prepared for what the software will do. If you lack the resources to quickly respond to downtime, Chaos Monkey is probably not for you. "There's not a 'reverse' of Chaos Monkey to bring things back up [automatically]," MacLeod said.
No matter your company's size, there are two prerequisites before running Chaos Monkey, according to MacLeod. First: "Know what you're getting into. This is something that is designed to cause problems," MacLeod warned. Chaos Monkey could very well knock you offline, something that's likely to inspire fear in some corners of the business. MacLeod also pointed out that it might be just as scary--and probably for good reason--if you turn on Chaos Monkey and nothing breaks.
The second prerequisite is to have the proper organizational philosophy. Given the tool's purpose--to break stuff--you'd better have buy-in from your bosses before turning it on. Imagine trying to explain yourself to non-technical management after the fact if Chaos Monkey runs rampant within your infrastructure. ("A chaos what?!") "It requires an adventurous spirit and confidence that you've got an architecture that's going to survive this, plus enough humility to know that you're willing to test your site to get better," MacLeod said. "One of the big problems out there is arrogance--'Oh, I know I don't have any problems.'
Even if you're unwilling or unable to invite Chaos Monkey inside your infrastructure, it can still offer a valuable lesson from safe distance. "The best thing about Chaos Monkey is that it's making people think about security and uptime and helping them realize that these aren't optional features in a service. They're something that needs to be designed in from the beginning," MacLeod said. Cutting corners on reliability will lead to unexpected failures--and a bunch of unhappy customers.
"It's like realizing, two-thirds of the way through building a car, that you kind of need an engine and a gas tank, and then trying to figure out where to shove those in," MacLeod added. "It's a lot easier if you start out with the reliability and the security in mind."
This Dr. Dobb's virtual event, Developer-Based Testing, will examine developer-based testing of code in its many forms: the tools, the techniques, the best practices. Sessions led by established experts explain the subtleties of different approaches and the best practices that have worked best in the field. If you want to know more about how to test your code with less effort and better results, one or all of the day's sessions are for you. It happens Aug. 2.