Solo.io has launched an initiative to define a format to extend the Open Container Initiative (OCI) image specification to standardize how an image bundles and stores metadata when developers write code using WebAssembly (WASM).

Company CEO Idit Levine says that as more organizations embrace WASM as a portable binary-code format for executable programs created using an assembly language, there needs to be a standard format for capturing metadata to promote interoperability across those projects.

WASM, in the case of Solo.io, is being employed to extend the capabilities of Envoy, open source proxy software being developed under the auspices of the Cloud Native Computing Foundation (CNCF). WASM is employed to add custom business logic and filters that extend the capabilities of Envoy to create such things as Solo Gloo, an open source application programming interface (API) gateway and ingress controller for Kubernetes environments. An implementation of WASM is also included as a sandbox-level project within the open source Istio service mesh, which is based on Envoy. WASM was created under the auspices of the World Wide Web Consortium (W3C) to provide a means for building applications that interoperate across multiple browsers.

WASM is now starting to be employed more broadly, but as it gains popularity Levine says more work needs to be done to prevent fragmentation. The format proposed by Solo.io is an outgrowth of the work the company put into developing WebAssembly Hub, a registry for building and sharing WebAssembly extensions such as filters for Envoy.

It’s still early days as far as the adoption of proxy servers and services meshes are concerned. However, as IT environments become more complex in the age of microservices, there is a need for higher levels of abstractions that mask the underlying IT infrastructure from developers. Rather than having to know how to call an API for a specific platform, a developer can request a service through a proxy server or service mesh. That approach ultimately makes networking and security agile enough to incorporate within a DevOps workflow.

Of course, most organizations will need to extend proxy software and service meshes across both monolithic and microservices-based applications. As that transition occurs, the convergence of network and DevOps operations will accelerate. IT teams that deploy microservices on top of Kubernetes clusters can expect to be at the forefront of that transition.

Naturally, the biggest issues most organizations will encounter as network operations and DevOps converge will be cultural. Most networking teams are just now making the transition to software-defined network overlays that allows them to more flexibly manage fleets of routers and switches. Most of those teams are managing those overlays using graphical tools versus programmatically managing them in the same way DevOps teams provision virtual machine resources. In many cases, the functions provided by an SDN today might simply become extensions of platforms such as Envoy and Istio tomorrow.

Regardless of approach, the days when networking services were surfaced manually by network operations teams using command-line interfaces (CLIs) on each network appliance are coming to a merciful end.

The post Solo.io Proposes OCI Format Extension for WASM appeared first on Artificial Intelligence.

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.

The post MayaData Donates Chaos Engineering Tool for Kubernetes Apps to CNCF appeared first on Artificial Intelligence.