This is a sneak-peak blog for Litmus 2.0 GA which would be available in a few weeks from the publication date of this blog. You can find the latest Beta here. I am excited to write this blog with the progress we made in Litmus and will cover the transformation of Litmus 1.x to Litmus 2.x.
Let’s jump back a bit, the goal of the Litmus project is to create a complete platform to practice chaos engineering at scale in a Kubernetes way. Of course, this had to be done incrementally, first create a toolset for chaos injection and then add additional features to make it a platform. Litmus 1.x achieved the goal of keeping it completely open-source, creating a ChaosHub and creating the required CRDs, Operators and Schedulers. With Litmus 1.x, users have a working chaos engineering toolset aligned with the original goals.
Back to the present date, Litmus 2.0, over time the monthly cadence releases and community engagement we have added the following features and made LitmusChaos much easier for end-users. With the launch of LItmus Chaos 2.0, a new way of chaos engineering can be performed by the users, capturing a few high-level features. A detailed list can be found on the release page.
Chaos experiments become building blocks of a ChaosWorkflow, to allow users to create a larger chaos scenario using sequential or parallel experiment execution.
A cross-cloud control plane has been built which can be used to
- Predefined workflow for easy onboarding.
- Construct a custom workflow from a UI interface for both parallel and sequential workflow from both public or private hub.
- Orchestrate chaos workflow across K8S agents(clusters) from a single control plane.
- Centrally visualize the chaos workflows, get chaos analytics and compare the same.
- Get the teaming in place for collaboration of chaos workflows.
- Agents can work in namespace scope or cluster scope.
Chaos workflow can be stored in Git.
Chaos GitOps for highly scalable automation of chaos workflows. Chaos can now be triggered as a result of a change to an application. This integrates with other CD tools like ArgoCD and FluxCD.
Chaos Interleaved dashboards. A step toward open observability that is interleaved with chaos incident details.
Litmus itself is composed of microservices. And we made sure that by adding the above features for 2.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 2.0 is completely backwards compatible. No features are deprecated.
The migration path is about constructing new artifacts such as ChaosWorkflows that include the current chaos experiments in use by the users.
A high-level comparison between Litmus 1.x and Litmus 2.0 providing a holistic view of the feature addition you get in Litmus 2.0.
|Litmus 1.x | Litmus 2.0 |
| --------------------- | ------------------------------------------------------------ | | Chaos Experiments | Chaos Workflows composed of one or more Chaos experiments that can be run in sequence or parallel. | | Per-user | Teams (Multi-Tenant) | | Per cluster | Per organisation (Cross-Cloud) | | Only Public Chaos hub | Public and Private Chaos Hubs | | CLI only | CLI and GUI | | | GitOps | | | Scalability | | | Integrated observability and Interleaved monitoring |
We are accepting help from the Litmus community in the form of their valuable feedback and much-appreciated contributions. We invite you to get into a discussion on GitHub or Slack with us and provide us with your requirements to improve Litmus as a community project.
That's all folks. Thank you for reading it till the end. I hope you had a productive time learning about Litmus and we hope you are as excited as we are about the upcoming features/additions to Litmus. Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you? Want to chat with us, we are available in Kubernetes slack #litmus channel or direct link.