Source: containerjournal.com
The Cloud Native Computing Foundation (CNCF) has accepted a Litmus Chaos application testing tool based on chaos engineering principles as a sandbox level project.
Developed by MayaData, the open source software provides IT teams with a chaos engineering tool that runs natively on Kubernetes.
MayaData COO Uma Makkara says Litmus Chaos was originally created to test OpenEBS, an open source project that makes it easier to access container-attached storage. OpenEBS is the foundation for Kubera, a data management platform the company launched last week.
While there are other tools and services based on the chaos engineering principle, Makkara notes Litmus Chaos makes it possible to run those tests on the same Kubernetes cluster where a microservices-based application built using containers runs.
In theory, microservices-based applications are expected to degrade gracefully in the event a software component or infrastructure element suddenly becomes unavailable. Requests for access to microservices are rerouted to ensure availability. In practice, many microservices-based applications inadvertently have single points of failure. Chaos engineering techniques randomly remove software components and infrastructure elements to test how resilient a microservices-based application really is.
MayaData is contributing Litmus Chaos to the CNCF in the expectation that other organizations building microservices-based applications will want to apply similar techniques to testing their software. Some organizations will prefer to deploy those tools themselves while others may prefer to employ a service that might be constructed on top of Litmus Chaos.
Makkara says chaos engineering tests are also shareable via a Chaos Hub, which eventually will become part of a series of integrated hubs revolving around the Harbor container registry, which is designed to hold multiple types of artifacts such as Helm Charts alongside containers.
Containers make it possible to package code application logic in a more discrete fashion to create a microservice. A microservice packages multiple containers with runtimes in a way that enables them to be more easily executed at the same time. Thanks to that capability, a development team can deploy microservices in a way that allows them to be managed in isolation from one another. Microservices have been around in various forms for some time. However, with the rise of containers, it has become easier to both construct and update microservices. Containers enable any element of a microservice or the entire microservice itself to be ripped and replaced.
The challenge is as applications expand the number of dependencies between microservices grows. Chaos engineering provides a way to discover whether those dependencies are loosely coupled or create a single point of failure that could result in an entire application becoming unavailable.
It’s not clear to what degree IT organizations have embraced chaos engineering techniques. However, microservices based on containers are likely to force the issue. Organizations that build cloud-native applications based on microservices and containers generally employ best DevOps practices that stress continuous testing. That’s critical in the context of any microservices-based application because what works fine today might not work near as well today as more dependencies are introduced.
