订阅我们的博客

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


关于作者

Imaginative but reality-grounded product exec with a passion for surfacing the relevant essence of complex technology. Strong technical understanding complemented by ability to explain, excite, and lead. Driven toward challenge and the unknown.

Read full bio

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事