Open Outlook: Middleware (part 2)

In the previous blog we talked about the importance of containers as an enabler of fine-grained, microservices software architecture that in turn enables the more rapid, trial-and-error innovation necessary to compete in digital business. Let's take a closer look at what middleware looks like in this containerized world.

Beginning in the pre-virtualization era when software was architected as coarse-grained, "monolithic" compiled binaries installed on an operating system running on a physical server, middleware mostly consisted of standard libraries that were combined with custom code into the monolith at the moment of compilation. A later innovation was the "application server" approach, where foundational middleware functionality such as clustering, database connectivity, and transaction support was packaged into an independently installable and runnable unit onto which the custom application code was subsequently deployed. In addition, some middleware functionality was packaged into units such as data grids, rules engines, and service busses that ran independently and were called as "services". So you had three basic ways to incorporate middleware into an application: include libraries in the deployment element, deploy the element to an application server that provided additional capabilities, and call out to surrounding services for even more capabilities.

In a containerized, "cloud-native" environment, the application server aspect of middleware changes significantly. Some of the functionality previously provided by the application server, such as clustering and load balancing, is now provided by the cloud platform. Other functionality, such as database and transaction support, is provided by standardized, pre-built components more akin to libraries that get combined with the custom application code into the the container. A particular combination of custom code and pre-built code that goes into a single container instance is a "microservice" in a containerized, cloud-native, microservices architecture.

So in this modern, cloud-native environment, the notion of an independently-running application server to which one deploys applications morphs dramatically; one deploys to the cloud platform an application consisting of a larger number of finer-grained components, each of which runs in a container. Each containerized component ("microservice") has some middleware included within it and also makes calls to other middleware running as separate, containerized microservices.

Thus, of the three traditional forms of middleware--included libraries, application server, and separately-running services, the included libraries and separately-running (micro)services remain highly important in the cloud-native world. And in order to take advantage of the rapid, trial-and-error style of development afforded by the containerized, microservices architecture, enterprise developers need middleware that is fundamentally designed and optimized to support this approach.

Middleware that best supports this cloud-native approach must have several characteristics. The middleware that exists as libraries that get combined with custom code into containers must be lightweight, which means componentized at the right granularity such that the developer can easily include just what is needed without dragging in too much extra. The middleware that exists as external services, such as data grids, rules engines, business process runtimes, etc. must be containerized at the right granularity so that components can be easily updated and restarted with minimal disruption while not lowering overall application performance with too much inter-container communication.

In addition to being lightweight and optimally granularized, the best cloud-native middleware should be engineered together in a way that provides the developer and operator with a unified, coherent, and complete environment. The pieces should make sense on their own as well as together. There should be consistency where consistency makes sense--in how services are called, scaled, secured, lifecycled, etc. – yet things should be loosely enough coupled that subsets of functionality can be used in ways that minimize unnecessary things being paid for or hindering performance. We think of this loosely coupled but unified, engineered-together world of cloud-native middleware libraries and services as the application environment.

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