Russ Miles and I started the chaostoolkit project about three months ago with the idea we wanted to express with code discussions we had been having on Chaos Engineering and its principles. I’ll leave you the opportunity to read Russ’s post about the Chaos Toolkit effort as I would like to focus here on the choice we made to use Python to implement that Open API for Chaos Engineering.
When we started the core implementation, we wondered which language we should pick up for the project. As a long Python developers, I have always felt faster and more at ease with it but I thought it would be wise to give the other existing languages a thought.
At its core, the Chaos Toolkit attempts to define a declarative API to drive your chaos engineering experiments. That experiment is serialized in a JSON file the chaos command ingests and validates it before executing declared activities sequentially.
It felt clear to us that we would be handling a lot of strings so we wanted to have something that was simple, yet powerful, when dealing with them. That alone is not a strong enough requiremement to make a choice. Afterall, most dynamic languages are capable with strings while static languages, although perhaps more verbose, would be able to as well.
We also knew we meant the chaostoolkit to be extended as widely as possible so we looked for a rich ecosystem with various capabilities. It also meant, we should pick up a language that would help us load extensions in a simple fashion (Note that the Chaos Toolkit API describes three extension mechanisms: Python functions, HTTP calls or process. This means that you do not need to write Python code when you want to extend the toolkit).
It was also relevant to select an ecosystem that was well spread to reduce the quantity of steps for users in order to get started.
On the other hand, speed never was a requirement per-se. Indeed, the Chaos Toolkit is a CLI that runs things sequentially from a single machine. There is no need for raw speed because the Chaos Toolkit runs things as fast as they actually need to be.
Language prowesses with paradigm X or Y didn’t matter to us as long as the language was sound and dependable.
Those requirements, if we can call them that, aren’t very strong nor well-defined but they served us as guidelines.
Having worked a little with a variety of languages this past two years, I kept wondering what to select. Afterall, languages such as Clojure, TypeScript or Go all fitted the bill fairly well.
I dismissed Clojure mostly because I didn’t know its ecosystem nor community well-enough and I could not afford the time to thoroughly explore it. However, should have I had known it more, it would have been a strong candidate if only because of its code-as-data approach felt appropriate. Nonetheless, I do wonder still about its ecosystem.
TypeScript was an interesting one because it does remind me of Python in many respects. Much like Clojure however, I left it out it because I wasn’t sure its ecosystem would be the right one for the sort of experiments that users would care for.
As for Go, it’s mostly the question whether a statically compiled language would fit the requirement for string handling. I don’t mean to say Go is bad at dealing with strings. I made the decision that if I had to end up with empty interfaces, I might as well directly rely on a dynamic language.
I realise you could argue it’s mostly a lack of knowledge of all those languages and ecosystems that made me uneasy about picking them up. Indeed, I certainly think they could all have worked out.
But I settled on Python. In fact, I picked Python 3 specifically. To me Python 2 feels legacy and new projects should not start there any longer (except in rare cases).
Python does check all the boxes the project needed. It’s readily available, has a massive ecosystem, with native libraries for platforms we believe the Chaos Toolkit will provide the most benefit to (such as Kubernetes), and has powerful string handling (specially with the most recent Python 3 releases).
I know most DevOps tools seem to be written in Go these days, but I strongly believe, Python is a sound choice depending on your requirements. Specially Python 3.
Will choosing Python over Go impact the Chaos Toolkit as a project? I certainly hope not and I worked hard to design the code base so that it is comprehensible and easy to ge involved with (well I hope anyhow ;)).
In the end, what tipped it over was that Python is awesome and absolutely fun to work with.
Python has a tremendous ecosystem made of high-quality libraries. The changes in the language in the past years have not just made it more feature-rich but also actually more sound and relevant to new scenarios.
But, at the end of the day, this is just for the little story really, what matters is that we are proud of the Chaos Toolkit and really enjoy using it. We do sincerely hope it will meet its community, so if you fancy a project for 2018 or want to experiment with Chaos Engineering, make sure to join it and say hello! We love a good chat.