Analytic microservices Architecture (iii): Micro-Service refactoring applications and IBM solutions

Analytic microservices Architecture Series The article will describe the definition, characteristics, application scenarios, evolution of enterprise integration architecture and micro-service transformation thinking and technical decision-making considerations in several sections, and take IBM technology as an example to introduce how to realize the transformation of micro-service architecture.

The previous article introduced the evolution of enterprise integration architecture into microservices, and introduced the micro-service model and technical decision examples of interactive systems.

This article describes how the transformation of the existing IT applications to microservices refactoring and the introduction of IBM MicroServices-related solutions.

 

Micro-Service Transformation

The adoption of a microservices architecture means higher-speed application delivery and faster market launch at the expense of a more complex operational environment. So organizations need to weigh the tradeoffs between faster delivery and more complex operations.

Most enterprises have a large number of legacy applications, so when it comes to the urgent task of needing to meet business needs faster and better, most of the time the enterprise will not build a completely new application, usually the enterprise refactoring the existing application or want to try to reuse the existing code.

Evolution to a microservices architecture typically involves the following phases:

1. Traditional SOA service transformation;

2. The introduction of some microservices principles and targeted refactoring, such as "one task one service";

3. Introduction of a complete set of micro-service principles;

4. Scale your microservices – add enhanced features such as service discovery, service scaling capabilities, and more.

Not all applications need to complete each of these stages, and one basic principle is to refactor to solve targeted business problems, and to avoid "microservices" in order to "micro-services".

It is important to note that not all applications can be transformed into microservices architectures:

Some systems cannot be refactored into microservices architectures: For example, very old and poorly maintained systems, which can take the "if the application cannot be broken, do not try to solve it" strategy, where the reuse of SOA assets should be a better solution.

legacy applications cannot change the way data is stored: in this case, it is necessary to consider if the data is still in the chimney or centralized storage, that the application of microservices is business value, need to consider whether the segmentation of the database will lead to the lack of transactional security and thus affect the stability of the system At the same time, it is possible to consider whether the application can solve the data consistency problem such as base, CQRS and so on.

How the original system into the micro-service architecture: in the original system to remove some of the functions and re-construction as a micro-service, how to realize the micro-service and the original system in the high-availability of isolation, if the original system and micro-service scalability mismatch and how to deal with. These problems may have to be considered before a microservices reconfiguration.

Micro-Service refactoring

In refactoring applications , microservices can be combed through the following methods: (1) Each rest service is a potential microservices, (2) Each SOAP Web service or EJB is a potential microservices, especially a stateless session bean, A feature-oriented interface needs to be redesigned as an asset-oriented interface and the interface transformed into a restful form, (3) The use of domain-driven designs (Domain-driven design) to discover enterprise assets, which may be microservices.

In terms of refactoring data , the following aspects need to be considered: (1) Finding islands of data that are not associated with other data , checking the entity-Relationship diagram of the system; If there is data disconnected from other data, it is a potential data reconstruction point; (2) data table denormalized , some data tables are normalized to the higher normalized database to reorganize the data into larger logical blocks, which is designed to increase the data redundancy and make it more easily broken; (3) reverse Batch data update , Data refactoring needs to be considered when data refactoring fails to batch the new data back to the old data schema; (4) using master Data Management , a single consistent view of the widely used data entities and the development of corresponding microservices to work with the master data; (5) in SQL database look for code stored in a BLOB (binary large object) field type, and store these objects in a NoSQL database, such as stored as key-value (Key-value) storage, (6) Looking for active record patterns, with other unrelated flat objects, Use a document-mode database for storage, such as Cloudant or MONGO.

MicroServices refactoring also requires repackaging applications , including: (1) splitting the application's ear file and packaging it into a separate war file, (2) applying a "one container service ", Deploy each war file separately to its own Websphereliberty instance runtime or Docker container, and (3) build, deploy, and manage them separately , using separate DevOps pipelines for each war file, scaling and managing each war file independently.

Micro-Service IBM Solutions

API Connect-Create, run, manage, and secure an enterprise-class platform for API-capable open and microservices applications.

In order to accelerate application development to meet growing demand, the need to open internal business and data capabilities and to attract partners and developers based on their ability to innovate quickly, IBM API Connect provides enterprises with a unified and complete API capabilities open platform solution for the creation, operation, management of the API , security assurance, and microservices operating environments to meet the needs of the enterprise to participate in the API economy.

The IBM API Connect platform provides the basic capabilities for digital applications: (1) Create microservices and provide API interfaces to external providers, (2) manage, control, and protect rest and soap APIs, and (3) provide self-service API portals for application developers inside and outside the enterprise; (4) Publish API interfaces to multiple developer portals, (4) Analyze API usage and performance metrics.

Was Liberty+wxs-based on the OSGi core, a highly modular, highly dynamic lightweight WebSphere Application server, and a cache service with enterprise-class high availability, enabling fast delivery of microservices applications

MicroServices applications require a separate operating environment from each micro-service, so traditional application server containers are cumbersome, so businesses need to use lightweight application server containers, but they also need to consider sophisticated technical service support.

IBM was Liberty is a Java-based, lightweight WebSphere Application Server developed by IBM that meets the lightweight requirements of innovative applications and provides enterprises with effective business technical support. Avoid the risk of technical support that enterprises may have as a result of using open source software.