Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
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
About the author
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.