by Chief Technology Evangelist at WSO2, Inc. Humanization Technology. Architectural Transformation.
getty
Spending two decades in the middleware field has given me deep insight into the evolution of this technology field. I started my career as a software engineer on a platform team, building reusable components using technologies such as Object Linking and Embedding (OLE), the Distributed Component Object Model (DCOM), and the Common Object Request Broker Architecture (CORBA). I later joined WSO2, an open source technology and software as a service (SaaS) provider with middleware roots, where I held various 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 quickly. 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 targeting.
• Object oriented.
• Remote Procedure Calls (RPC).
• Database.
• Transaction.
• Gateway.
• Built-in.
• Content-centric.
Middleware gained popularity in the late 1990s when service-oriented architecture (SOA) became the main architecture style. During this time, it was delivered and used in two main categories: server-based and shared library. In the server-based mode, developers deployed code to a middleware runtime and accessed the middleware’s capabilities. Application servers, enterprise service buses (ESBs), and gateway servers are some examples of server-based middleware.
Shared libraries are standard middleware components and features. They are wrapped in reusable media, stored in a shared repository, and exposed via a registry entry. 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), while Microsoft .NET used dynamic link libraries (DLL).
This model has begun to change with some technology trends, such as cloud-native architecture (CNA), application programming interfaces (APIs), and distributed architecture styles such as microservices architecture (MSA). Then, middleware behavior was overturned by a specific technical development: containers.
Containers have made the server-based model obsolete by allowing the development of independent software components (as containers) without bulky runtimes. On the other hand, when applications that link shared libraries are deployed as containers, they cannot take full advantage of the benefits of a container. Instead, they simply use containers as traditional hypervisor-based virtual machines (VMs). The container architecture has introduced patterns – such as sidecar, adapter and ambassador – to support traditional shared libraries, but these are resource-intensive and expensive methods.
Even with our cloud-native container-based development approach, we cannot ignore middleware, which provides fundamentals to application software development. But what happens to middleware in the modern cloud era?
Middleware disappears 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 development. Meanwhile, the open-source, cloud-native programming language Ballerina goes a step further by building middleware capabilities into the language itself. Network interactions, data types, and constructs such as 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) middleware capabilities via APIs, which have become the new DLLs. So, for example, message queues, storage and security policies are open for use by developers in applications running on 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 enabling core 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 CNCF are not sufficient for your application development, you can add custom resources by defining them in a custom resource definition (CRD), because Kubernetes is built with open standards.
As you can see, the middleware is indeed they disappear into code and infrastructure, and the benefits to developers are clear. Middleware within code creates simple builds with more power, and middleware within infrastructure enables scalability, manageability, and observability.
If you work in application development, you can now leverage middleware to reap the full benefits of the cloud using a cloud-native programming language and infrastructure. Also, if you’re developing middleware, it’s time to rethink how you fit into the modern cloud landscape.
The Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Am I eligible?
