Introducing Litmus 2.0 - Simplify Chaos Engineering

Ajesh Baby — Wed, 01 Sep 2021 11:36:24 +0000

I am feeling delighted to write this blog on the eve of the announcement of LitmusChaos 2.0. We had spent a bit more than a year planning on adding additional features and making the user journey better and simpler. While more requirements and improvements are flowing in, we are encouraged by the possibilities and feedback. The principles and features of 2.0 have been solidified over many months of beta.

Let me put the thoughts before making LitmusChaos 2.0. We wanted to have a clear distinction between the existing 1.x and 2.x versions. The items which we concentrated are as mentioned below.

Provide a single pane for orchestration ChaosCenter. This piece of LitmusChaos is not just, and it’s built upon the API layer. Keeping any user interaction can be achieved through this either through UI, API or LitmusCTL. Hold on. I will be covering LitmusCTL later on this blog.
Didn’t want to deviate from the principle on how the Chaos Engineering Platform should be built and stick the features in alignment with these principles.
Users should be able to share or collaborate the workflow with others
GitOps enabled, i.e. the user should be able to source control the workflow or execute workflow based on the changes in the environment
Open Observability, able to observe chaos injection impact using their existing observability tools. Support Non-K8S Chaos from Litmus and enable it to schedule it the same way as other workflows.
Central repo from which users can consume or contribute the experiments. ChaosHub.
For Novice have a predefined workflow so that they can consume the ChaosEngineering on a Standard microservices reference architecture like Sock-Shop, PodatoHead Application and Bank of Anthos.

Now let’s briefly explore the new feature additions in LitmusChaos 2.0.

Chaos Center

Let us consider the life cycle of Chaos Engineering in 4 simple steps as depicted in the diagram. And let us increase a bit more complexity in your environment. You want to manage the multiple clusters and cross-cloud or do it across various teams. You need an interface, i.e. to do either using UI or API. To answer this, we devised ChaosCenter.

A chaos control plane or portal provides centralised management and orchestration of chaos operations on multiple clusters across data centres/clouds. The control plane carries out experiments through agents installed on the registered clusters.
Comprises documented APIs to invoke chaos programmatically.
Provides visualisation capabilities and analytics
Supports an org-project-teams-users structure to enable collaboration within teams for chaos operations.
Introduces chaos workflows - to (a) automate dependency setup (b) aid creation of complex chaos scenarios with multiple faults (c) support definition of load/validation jobs along with chaos injection
Provides flexibility in creating/running workflows in different ways - via templates, an integrated hub, and custom uploads.
Supports setup (control plane & agents) and execution of chaos experiments in both: cluster-scoped and namespace-scoped modes to help operations in shared clusters with a self-service model

LitmusCTL

LitmusCTL is a command-line tool for advanced users who would want to perform operations in the command line. At present, this has support for registering Chaos agents to ChaosCenter.

*Open Observability & Steady State Hypothesis Validation *

Provides an increased set of Prometheus metrics with additional filters - that can be used for instrumenting application dashboards to observe chaos impact
Provides a diverse set of probes to automate validation of steady-state hypothesis - thereby improving the efficiency of running automated chaos experiments

GitOps for Chaos

Integrates with Git-based SCM to provide a single-source-of-truth for chaos artifacts (workflows). Changes are synchronised bi-directionally b/w the git source and the ChaosCenter - thereby pulling the latest artifact for execution.
Provides an event-tracker microservice to automatically launch “subscribed” chaos workflows upon app upgrades affected by GitOps tools like ArgoCD, Flux.

Non-Kubernetes Chaos

Adds experiments to inject chaos on infrastructure (cloud) resources such as VMs/instances and disks (AWS, GCP, Azure, VMWare) - irrespective of whether they host the Kubernetes clusters or not.
Introduces chaos experiments to bring down bare metal nodes that provide IPMI-based out-of-band access.

We invite you to discuss GitHub or Slack with us and provide us with your requirements to improve Litmus as a community project.

Conclusion

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?

Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes: https://slack.litmuschaos.io (#litmus channel on the Kubernetes workspace)

Litmus 2.0 - Simplifying Chaos Engineering for Enterprises

Ajesh Baby — Fri, 16 Apr 2021 12:51:31 +0000

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 trying to build new documentation. Currently, we have published the beta documentation here and will be moved to the main documentation website with the launch of 2.0 GA.

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.

Conclusion

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.

DEV Community: Ajesh Baby

Introducing Litmus 2.0 - Simplify Chaos Engineering

Litmus 2.0 - Simplifying Chaos Engineering for Enterprises