Building IT Transformation Architecture with Red Hat OpenShift

2019년 6월 14일Alex Handy4분 읽기

In the era of mobile applications, business challenges to the enterprise IT organizations are more dynamic than ever. Many enterprises have difficulties responding in time because of the inherent complexity and risk of integrating emerging technologies into existing IT architectures. In this article, I will share my experience on how to utilize Red Hat OpenShift as a "Middle Platform" (中台) for enterprises to construct its bimodal IT architecture with agile, scalable and open strategy.

In the past year, I have discussed with many corporate customers--especially in the financial services industry--the challenges of digital transformation, and the solutions. Most of their difficulties are coming from “core systems” which have been working for more than 10 years.

Those core systems are usually built with proprietary vendor technology. It is common for the enterprise to setup an Enterprise Service Bus (ESB) platform to connect the core systems for data and transformation. However, it becomes complicated to maintain the platform because it takes N^(N-1) connections for N systems. Due to the ESB complexity, only a limited number of teams or partners have the skills and knowledge to maintain these systems and implement new applications on them. That means the IT organization may not respond in time for the business requirements.

Until recently, such practices faced serious challenges due to the emergence of mobile applications. The user traffic coming from mobile devices is far more unpredictable than those from Websites. Some events may incur 10 times more traffic than normal.. It takes huge amount of effort to prepare for such an event with many machines, applications and engineers. Mobile applications have brought along even more IT challenges like big data, AI and IoT, etc, and it is usually faster and easier to adopt those emerging technologies through new frameworks or programming languages. However, those new applications may not be fully compatible with existing core systems and ESB platforms.

As shown in the following figure:

Tech companies that can leverage these emerging technologies and respond to the market requirements are well positioned strategically in the marketplace.. We have seen many traditional companies trying to change, through the establishment of digital teams and fintech teams using Design Thinking and Agile Development. These are positive steps, however the strategic IT problems are still obvious:

Is it profitable to change the existing architecture to integrate the new technologies?
Is it profitable to invest in a new architecture to adopt the new technologies?
If we have a new architecture, how do we integrate it with the existing ones?

Gartner has proposed the famous Bimodal mode in response to these problems. From the perspective of information technology, one can imagine that Mode 1 is the traditional core systems and the ESB platform. Before moving to the implementation of Mode 2, I want to explain some concepts of containers and container platform.

What is a container?

A software container, which contains the code of the application software itself, as well as the required operating system kernel and library.

Benefits of Containers?

Linux containers help reduce conflicts between your development and operations teams by separating areas of responsibility.

Why container platforms?

A container platform can manage a large number of container applications, including monitoring containers’ lifecycles and providing high availability (HA) of applications. It can also automatically scale out/in applications in response to high/low traffic. Different teams can develop and deploy their own applications on the same platform without interfering with each other. They can release different versions of the same application on the platform with a single point of access URL for Blue/Green deployment or A/B testing. Many CI/CD automation tools are available on the platform to help with this type of deployment.

Seeing this, we would say those features can resolve the technical challenges of the core systems. The following is an example of Mode 2 implementation based on a container platform working with Mode 1 architecture:

In the above architecture, the front-end Mobile APP calls the APP2 deployed in the container platform, which can autoscale APP2 dynamically in response to bursts of mobile traffic. Then APP2 can direct the traffic to the existing ESB services, or it can access the core system if APP2 implemented the ESB logic. Other front-end applications like Big Data , AI or IoT can call their responding applications like APP3 with different options to complete the request:

Through the ESB to access the core system.
Directly access the core system.
Access the core systems through other applications on the platform like APP2.
Look up the Cache.

Option 1 is for those who want to connect the existing ESB services quickly without understanding the detailed functional logic. Option 2 is for those who want to rewrite the ESB function to improve the technical performance (the Strangler pattern). Option 3 is for those who want to leverage the existing container applications, but add a bit more functionality. Option 4 is for those who want to reduce the loading of core systems and speed up the system response time. Enterprises can use these four options based on different scenarios.

Mode 1 and Mode 2 can work independently, while in some scenarios one of them may access the other for different purposes. In the last graph you can see how these two modes work in the same time.

In China, this container platform is called “Middle Platform” or “Zhongtai,” meaning the middle-end in between the front-end and back-end systems. In other words, the Middle Platform is responsible for rapidly composing reusable application services, responding to front-end demands with the backend core systems. It makes the enterprise take advantage of new technologies to develop applications with multiple frameworks or languages while keeping the core systems work normally in place.

To sum up, the Middle Platform has the following strategic benefits:

Agility
Scalability
Openness
Bimodal implementation

저자 소개

Alex Handy

Principal Product Marketing Manager

Red Hatter since 2018, technology historian and founder of The Museum of Art and Digital Entertainment. Two decades of journalism mixed with technology expertise, storytelling and oodles of computing experience from inception to ewaste recycling. I have taught or had my work used in classes at USF, SFSU, AAU, UC Law Hastings and Harvard Law.

I have worked with the EFF, Stanford, MIT, and Archive.org to brief the US Copyright Office and change US copyright law. We won multiple exemptions to the DMCA, accepted and implemented by the Librarian of Congress. My writings have appeared in Wired, Bloomberg, Make Magazine, SD Times, The Austin American Statesman, The Atlanta Journal Constitution and many other outlets.

I have been written about by the Wall Street Journal, The Washington Post, Wired and The Atlantic. I have been called "The Gertrude Stein of Video Games," an honor I accept, as I live less than a mile from her childhood home in Oakland, CA. I was project lead on the first successful institutional preservation and rebooting of the first massively multiplayer game, Habitat, for the C64, from 1986: https://neohabitat.org . I've consulted and collaborated with the NY MOMA, the Oakland Museum of California, Cisco, Semtech, Twilio, Game Developers Conference, NGNX, the Anti-Defamation League, the Library of Congress and the Oakland Public Library System on projects, contracts, and exhibitions.