The Discipline of Chaos Engineering
blog.gremlininc.com
The Discipline of Chaos Engineering
1–10 of 15 posts
Re: The Discipline of Chaos Engineering
#2> read "Origins of Totalitarianism"
> break totalitarianism
> get t-shirt that reads,
> "I broke totalitarianism and all I got was this stupid t-shirt"
Re: The Discipline of Chaos Engineering
#3>Kolton is co-founder and CEO of Gremlin Inc. Previously he was a Chaos Engineer at Netflix improving streaming reliability and operating the Edge services.
Right - this makes sense. I thought this philosophy sounded Netflix-ish. Interesting to see it "spun out" into a product.
Re: The Discipline of Chaos Engineering
#4>>> Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
I don't like how they define "Chaos Engineering" as being strictly related to distributed systems.
Re: The Discipline of Chaos Engineering
#5>>> Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production. I don't like how they define "Chaos Engineering" as being strictly related to distributed systems.
Chaos Engineering seems most useful in the context of distributed systems though, and I'm not entirely certain how you would implement it outside of that context.
I would consider applying invalid inputs, etc. to non-distributed systems to be more along the lines of traditional testing. Perhaps you could implement chaos engineering principles in a non-distributed system by simulating the failure of a CPU core or a region of memory? It seems less useful though, as those things seem very difficult to effectively recover from.
How would you define "chaos engineering" to apply to non-distributed systems?
Re: The Discipline of Chaos Engineering
#6>>> Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production. I don't like how they define "Chaos Engineering" as being strictly related to distributed systems.
Chaos Engineering seems most useful in the context of distributed systems though, and I'm not entirely certain how you would implement it outside of that context. I would consider applying invalid inputs, etc. to non-distributed systems to be more along the lines of traditional testing. Perhaps you could implement chaos engineering principles in a non-distributed system by simulating the failure of a CPU core or a re…
> Perhaps you could implement chaos engineering principles in a non-distributed system by simulating the failure of a CPU core or a region of memory?
Could be. In a general sense of chaos engineering.
For me, I think chaos engineering would be to keep generating "chaos" in a system or module or any unit. Chaos in this sense would be to break it, or any kind of maltreatment to it.
Re: The Discipline of Chaos Engineering
#7I'm curious though. What does one do if the database goes away? Also, how does one achieve high availability without doubling costs? Is this covered anywhere as a topic area or book or dedicated blog? Quite curious how to get started with something like this.
Re: The Discipline of Chaos Engineering
#8I'm curious though. What does one do if the database goes away? Also, how does one achieve high availability without doubling costs? Is this covered anywhere as a topic area or book or dedicated blog? Quite curious how to get started with something like this.
I'd be very surprised if you could get a 1-out-of-2 system with only double the cost. You need twice the hardware and significantly more complex logic.
Re: The Discipline of Chaos Engineering
#9I'm curious though. What does one do if the database goes away? Also, how does one achieve high availability without doubling costs? Is this covered anywhere as a topic area or book or dedicated blog? Quite curious how to get started with something like this.
It depends of what you are trying to do.
About the database : Cache. Offer a different flow that does not need the database, like with hardcoded stuff. Etc etc
About doubling the costs : It highly depends. On a small app, sure it may double the cost. On a big thing with thousands of servers, you can play a bit more with redistributing roles and all.
Re: The Discipline of Chaos Engineering
#10Isn't this basically what Google has been doing for years with their DiRT exercises?