Solo.io Proposes OCI Format Extension for WASM
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.