What's Happening To Middleware In The Cloud-Native Era?

Photo by Anete Lusina

First published on Forbes.

Spending two decades in the middleware field has given me deep insight into the evolution of this technology domain. I began my career as a software engineer in a platform group, building reusable components using technologies like object linking and embedding (OLE), the distributed component object model (DCOM) and common object request broker architecture (CORBA). Later, I joined WSO2, an open-source and software as a service (SaaS) technology provider with middleware roots, where I’ve held diverse technical leadership roles for over a decade.

The Evolution Of Middleware

Middleware sits between system and application software, helping developers create abstractions, hide complexity and build applications rapidly. The role of middleware in software development is similar to that of an electric food processor in cooking. It’s certainly possible to chop nuts or puree vegetables by hand, but a food processor does the job better and faster.

Middleware can be classified into several buckets:

• Message-oriented
• Object-oriented
• Remote procedure calls (RPC)
• Database
• Transaction
• Portal
• Embedded
• Content-centric

Middleware gained popularity in the late 1990s when service-oriented architecture (SOA) became the primary architecture style. During that time, it was delivered and used in two main classes: server-based and shared library. In the server-based mode, developers deployed the code into a middleware runtime and received access to the middleware capabilities. Application servers, enterprise service buses (ESBs) and portal servers are a few examples of server-based middleware.

Shared libraries are standard components and middleware capabilities. They are wrapped inside for reuse, stored in a commonly accessible repository and exposed through a registry listing. The shared libraries are linked at design time and deployed with the application software at runtime. Different programming languages each had their own way of linking and managing shared libraries. For example, Java used a packaging system (JAR), whereas Microsoft .NET used dynamic-link libraries (DLL).

This model started changing with a few technology trends, such as cloud-native architecture (CNA), application programming interfaces (APIs) and distributed architecture styles like microservice architecture (MSA). Then, the behavior of middleware was turned upside down with a specific technical development: containers.

Containers have made the server-based model obsolete, allowing independent software components to be deployed (as containers) without bulky runtimes. On the other hand, when applications linking shared libraries are deployed as containers, they cannot take full advantage of a container’s benefits. Instead, they are simply utilizing containers as traditional hypervisor-based virtual machines (VMs). Container architecture has introduced patterns—such as sidecar, adapter and ambassador—to support traditional shared libraries, but these are resource-hungry and costly methods.

Even with the cloud-native container-based deployment approach, we cannot ignore middleware, which provides foundational elements in application software development. But what’s happening to middleware in the modern cloud-native era?

Middleware is disappearing into code and infrastructure

This movement is already underway with modern, open-source programming languages. For example, Go and Kotlin have introduced capabilities for cloud-native development. Meanwhile, the open-source cloud-native Ballerina programming language goes a step further by embedding middleware capabilities inside the language itself. Network interactions, data types and constructs like services and APIs are first-level citizens in Ballerina, creating a new cloud-native programming model in which middleware capabilities are used while coding.

Another trend is mega clouds that provide infrastructure as a service (IaaS)-enabled middleware capabilities via APIs, which have become the new DLLs. So, for example, message queues, storage and security policies are open for developers to consume in applications running on the IaaS. But these are vendor-specific services.

Kubernetes addresses the issue of cloud lock-in by bringing an open standard to the cloud-native world, and it enables basic middleware capabilities as components. In addition, the Cloud Native Computing Foundation (CNCF) brings a rich set of Kubernetes-centric middleware, and you can find them in the CNCF technology landscape. However, if the middleware capabilities provided by Kubernetes and the CNCF are not enough for your application development, you can add custom resources by defining them in a custom resource definition (CRD) because Kubernetes is built using open standards.

As you can see, middleware is indeeddisappearing into code and infrastructure, and the benefits to developers are clear. Middleware inside the code creates simple constructs with more power, and middleware inside the infrastructure enables scaling, management and observability.

If you work in application development, you can now leverage middleware to reap the full benefits of the cloud by using a cloud-native programming language and infrastructure. Also, if you develop middleware, it is time to rethink how it fits into the modern cloud-native landscape.

About the Author

Asanka’s goal is to connect humans and technology by helping organizations implement digital transformation programs that result in consumer-driven digital applications. In his current role as Chief Technology Evangelist at WS02, Asanka drives efforts to create, refine, and enhance WSO2’s corporate reference architecture and is responsible for spearheading a thought leadership outlook that defines WSO2’s corporate reference methodology for development, customer success, and implementation.