Technology

Red Hat OpenShift Container Platform

Red Hat
2021/03/08

I.    Introduction:

To support different e-commerce platforms (B2B and B2C) and respond in real time to rapidly changing business and market demands, Alibaba Group has introduced the “middle office” in addition to the traditional “back office” and “front office” in the end of 2015. The concept of the “middle office” is that it is the gearbox of the “back office” and “front office”. With greater stability than the “front office” and higher flexibility than the “back office”, the “middle office” aims to balance the two.

II.    Obstacles in digital transformation

Take e-commerce for example. “Member service”, “product information”, “transaction payment”, and “logistics track” are common system requirements of B2B, B2C, C2C, and C2B platforms. In consideration of the technological burden, however, enterprises usually choose to build new systems, bringing three major obstacles to transformation:
1.    A waste of resources for the construction and maintenance of repeated functions
2.    A higher cost for integration and collaboration of the information silo architecture
3.    Unfavorable for business transfer and sustainable development

III.    Solutions for overcoming transformation obstacles: System layering strategy

While the “front office” aims to make real-time market responses, it must be simple and upgraded rapidly. The “back office” for processing business bottom-level resources and core traceable orders must be stable and reliable. As a result, the upgrading pace of the back office cannot keep up with the tempo of the rapidly changing front office.
In the 2016 “Pace-Layered Application Strategy” report, Gartner proposed that enterprise systems can be divided into three pace layers to deal with different technical architectures adopted for different purposes.
1.    Systems of Record (SOR) – Front Office
2.    Systems of Differentiation (SOD) – Middle Office
3.    Systems of Innovation (SOI) – Back Office

 


IV.    Solutions for overcoming transformation obstacles: Microservices, focusing on each small thing

In terms of application, from the past monolithic architecture through the service-oriented architecture (SOA) to the microservice architecture in recent years, the concept has basically been the same—breaking down services into discrete units in order to:
1.    Reduce the collaboration cost of development teams of different modules to respond to market needs with greater agility
2.    Reduce the coupling and overall complexity among systems for individual development teams to focus on developing their respective functions
3.    Avoid the overall impact caused by the failure of individual modules
4.    Enhance the scale-out capability of individual services to reduce the unnecessary waste of resources

Containerization: Realization of the DevOps concept

By containerizing microservices, it is possible to build an independent, self-determined production environment. The following benefits are gained by realizing the DevOps concept:

1. DevOps and ITOps separation: Layering services by stability and agility for different roles can make a high-performance team a reality.

2. Flexible resource dispatch with containerization: Since end resource usage is inconstant, it is difficult to accurately assess the resources of virtual machines, and buffers are often added to the peak usage. Containerization can prevent resource locking and reduce resource usage.

VI.    Red Hat OpenShift Container Platform Enterprise Solution

Kubernetes only provides container management and dispatch functions, while Red Hat offers the enterprise container platform solution for the operating environment, with functions including application packaging, mirror files without worries about information security, container operation, information security protection, service monitoring, and CI/CD.

VII.    Strategy for building the middle office: Red Hat Total Solution

1.    Extending e-commerce scenarios with middle office design
Transfer common services such as member services, product information, transaction payment, logistics tracks from the “front office” to the “middle office” to enable frequent change for a streamlined “front office” in order to respond to rapid market changes in the IoT era.
Extract the functions requiring frequent updates of the “back office” to the “middle office” to provide more flexible fire support for tense frontline business.
2.    Red Hat solution recommendation
The microservice design is recommended for the middle office, to prevent the SOA system from causing information silo issues.
Red Hat’s total solution and the enterprise-grade Red Hat OpenShift Container Platform are the best practices for building the “middle office”.

Contact Us