17.30 - Meet and greet
17.45 - Presentation - Why do you need Chaos Monkeys? You've got developers.
18.30 - Break with Pizza and Beverage
19.00 - Discussions
Netflix’s Chaos Monkey randomly terminates parts of a system to create real problems to test/verify the resilience of the full ecosystem. This is a rather ingenious way of making sure that you are ready for sudden failures and for honing your devops’ response times and troubleshooting skills. The whole idea being that failures are inevitable, so why not force them to happen when you’re already at work and have had your morning coffee.
Agile development is common in most software companies today.
- But can you move fast with basically no requirements, no estimates and no specific QA department?
- Can you let loose a legion of full stack developers on all corners of our systems, releasing fixes and features several times a day, every day?
Each deployment potentially introducing new bugs and bringing you closer and closer to the next system crash.
In a way we are all our own army of chaos monkeys. And is also possible to apply the word “chaos” to your development methodology and allow for an almost chaotic approach. Empowering the developer to basically just “figure it all out on your own” can lead to a great sense of responsibility and high quality. At the same time the risk of misguided decisions, erroneously perceived business values and perhaps a never ending cycle of refactoring increases.
How can you balance the pros and cons of such an approach to software development?
What are the challenges, when does it work, and what happens when it fails?
Jonas Andersson is the sole member of the "everything else"-team in the Telavox Product and Development department. He sees things in graphs that noone else can and lays the ground so that everyone else can make their job without too much anxiety about DevOps stuff. He has a black belt in social human interaction but prefers talking to computers through ansible-playbooks.
Henrik is one of the old timers at Telavox. He has been around since the beginning of time and was one of the first developers. Now he is the head (and beard) of the Product & Development department and balances his time between developing the business model, enhancing the user experience of our products and instead of writing essays he prefers equally long SQL queries.