Working with the Chaos Monkey
codinghorror.com
Working with the Chaos Monkey
1–10 of 43 posts
Re: Working with the Chaos Monkey
#2Re: Working with the Chaos Monkey
#3CM is a form of active TDD at the system architecture level. This might evolve into setting up partition tests as a prerequisite to instantiating the deployment model (Translation: before you start putting something on a cloud instance, write code that turns the instance off and on from time to time) This assures that the requirements for survival are baked into the app and not something tacked on later after some public failure like the Amazonocolapse.
I was reading on HN the other day a guy talking about Google. He said he saw engineers pull the wires from dozens of routers handling GBs of data -- all without a hitch. The architecture was baked enough that failure was expected.
Many times failure modes like this are burned into hardware, but that kind of design is a long, long, long way from most people's systems.
Re: Working with the Chaos Monkey
#4Re: Working with the Chaos Monkey
#5Building things this way strikes me as expensive. At Netflix's scale, it pays off, but for systems that don't serve as many requests I'm forced to wonder whether just avoiding the cloud might be more cost-effective.
Re: Working with the Chaos Monkey
#6Re: Working with the Chaos Monkey
#7Building things this way strikes me as expensive. At Netflix's scale, it pays off, but for systems that don't serve as many requests I'm forced to wonder whether just avoiding the cloud might be more cost-effective.
Re: Working with the Chaos Monkey
#8Re: Working with the Chaos Monkey
#9Building things this way strikes me as expensive. At Netflix's scale, it pays off, but for systems that don't serve as many requests I'm forced to wonder whether just avoiding the cloud might be more cost-effective.