Open Outlook: Middleware (part 1)

Middleware, both as a term and as a concept, has been around for decades. As a term, like other terms in the Darwinian world of IT jargon, it has followed a typical fashion lifecycle and is perhaps somewhat past its apogee of vogue. As a concept, however, middleware is more relevant than ever, and while a memetic new label hasn't quite displaced the traditional term, the capabilities themselves are still very much at the heart of enterprise application development.

Middleware is about making both developers and operators more productive. Analogous to standardized, widely-used, proven subassemblies in the manufacture of physical goods such as cars, middleware relieves developers from "reinventing the wheel" so that they can compose and innovate at higher levels of abstraction. For the staff responsible for operating applications in production, at scale, with high reliability and performance, the more such applications use standardized middleware components and services, the more efficient and reliable the running of the application can be.

This is just as true in the world of cloud-native applications as it is for traditional applications running directly on physical or virtualized hardware. A definitive characteristic of cloud-native environments is the use of the operating system container as the fundamental deployment unit. Thanks to widely and rapidly adopted standardized container technologies such as Kubernetes and Docker, containers have brought a substantial leap ahead over traditional server virtualization in terms of hardware utilization, elastic scaling, and process standardization.

The container is also important for the developer--and ultimately the business--as well. A significant advantage of the container over server virtualization is that containers are more lightweight. Each container instance has the minimum necessary low-level code within it to run its workload, whereas a virtualized server includes an entire operating system instance within it. Because containers are lighter, an application architect can modularize at a finer granularity, with each module running in its own container. In a world of virtualized servers it wouldn't make sense to decompose an application into a large number of very small modules, each running in its own virtual server--the overhead of so many redundant operating system instances would be too high. But with containers, dividing the application into many small pieces is viable and has many benefits. This approach is called microservices.

Why should the business person care? An application architected as fine-grained microservices can be changed in very small ways, with minimized risk and disruption to the overall application. This means that the business leader can innovate in small, fast, low-risk steps, working side-by-side with the development team responsible for implementing these innovations in the software that manifests the business.

Which brings us, from the bottom up, to a virtuous circle characterizing business today: nearly all enterprises depend in significant ways on software, and in order to compete more effectively, these companies are looking to innovate more rapidly, in a trial-and-error rather than massive-planning sort of way. This is the reality of business disruption happening now, in domains ranging from financial services to healthcare, hospitality to media, manufacturing to retail. This is digital transformation.

So here's the fundamental chain of logic: digital transformation both enables and depends on rapid innovation; rapid innovation depends on the ability to quickly change in small steps; such incrementalism is enabled by a fine-grained, microservices architecture; containers are the key enabler of viable microservices.

Now we come back to middleware. We've argued that a) developers are more efficiently innovative if they can think and design and build with standardized components, and b) supporting business innovation means enabling small incremental change with a fine-grained, containerized, microservices architecture. It follows that middleware for this new world should enable a microservices approach, meaning, as a starting point, that the middleware is itself containerized and cloud-native.

Mike Piech is vice president and general manager of Middleware for Red Hat