Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
Editor's note: this is part three of Mike Piech's Open Outlook: Middleware series.
In the first part of this series, we looked at the role of containers as a fundamental enabler of fine-grained, microservices architectures that enable rapid, incremental, trial-and-error innovation. In the second part, we described in some detail the continuing importance of "middleware"--whether it's called middleware or something else--for development of enterprise applications in containerized, cloud-native environments. We arrived at the notion that not only must traditional middleware be substantially reimagined and refactored to optimally support cloud-native applications, it can also be substantially more powerful when it is "engineered together" in a way that creates a unified, coherent application environment. Let's unpack this a bit and understand the opportunities, benefits, and requirements.
Clear menu choice vs. researching and downloading
One of the clearest benefits of building in a cloud environment (we'll keep the idea more general than specifically cloud-native for the moment) is that the developer is typically working at least part of the time in a web-based user interface where pre-built components that can be included or called (i.e., middleware) is presented in menus, drop-down lists, etc. So the developer can dive into the development session or initiative with a fairly vague idea of what's needed and discover pre-built components as she goes along, sometimes not even knowing up front that a given type of component already exists. Even when using a command-line interface (CLI) in a cloud environment, there are often commands for listing available components, so this approach is not strictly limited to web-based graphical interaction.
This menu-driven, incremental discovery style of development is in marked contrast to traditional development, where a developer had to know in advance what middleware was available, choose what he needed, download it, install it, configure it, and wire it together with other middleware and/or his own code. Because there was so much overhead in the process of acquiring and setting up each pre-built middleware component, the middleware tended to come in bigger chunks, dragging along more functionality than was typically needed. This was a worthwhile trade-off--setting up fewer, larger pieces rather than wiring together many more small pieces.
The ease with which fine-grained components can be discovered and incorporated into a development project in a cloud environment, along with the ease with which new components can be made available in the environment, clearly make for a much more rapidly evolving environment, enabling innovations to flourish with blinding speed.
The risks of explosive proliferation
The downside, however, is that even though the cloud machinery hides, standardizes, and automates much of the middleware setup, the explosive proliferation of the components and services in a given environment rapidly outstrips most organizations' ability to test and debug every possible combination that might be incorporated into a given application. While the cloud machinery might have been set up to automate the configuration of each component on its own, the developer is often still left figuring out how to get them working together.
This is why a cloud platform that has a superficially impressive laundry list of services in its catalog might not live up to its promise. The ease with which components can be linked into an application via the web dashboard or CLI can be deceptive. Underlying incompatibilities in the particular chosen set might not come to the surface until long after the initial selection and then become a nightmare to debug.
Harness proliferation with great engineering
Which brings us to the notion of "engineered together." If the middleware built for a particular cloud platform is organized in a way where there is a common set of standards and practices by which individual services and components get developed (ideally in open source communities so as to take maximum advantage of the innovation happening there), unit-tested, integration-tested, and productized, a substantial portion of this risk can be mitigated. By thinking of, designing, and testing individual components in a hierarchical structure of combination, many of the most common patterns and use cases can be effectively covered.
This takes a lot of effort both in design and productization practice, but it is what it takes to provide a truly unified and cohesive environment where the DevOps productivity and agility benefits of the cloud can be provided in an enterprise-viable platform.
These three related notes look in more detail at the runtimes, integration, and process automation areas within Red Hat Middleware. In a future note, we’ll look in more depth at a few case studies of how customers benefited from the engineered-together combination of Red Hat Middleware technologies on OpenShift.
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.