From SOA to microservices, how are enterprise distributed application architectures reshaped in the cloud native era?

Introduction: From a variety of distributed system research and development more than ten years ago to the present container cloud, from supporting the original business to incubating each new business, the development of enterprises can not be separated from the unified, advancing with The Times technology architecture. This article introduces the changes brought about by cloud native computing architecture from the perspective of enterprise distributed application architecture, hoping to help more enterprises transform IT and use cloud computing technology to promote them to become an agile force in the market competition.

Since the beginning of the 21st century, we have witnessed the evolution of enterprise distributed application Architecture from SERVICE-ORIENTED Architecture (SOA), to microservice Architecture, and then to cloud native application Architecture.

To illustrate the thinking behind the evolution of enterprise architecture, let’s start with some metaphysics.

• First, the complexity (entropy) of enterprise IT systems conforms to the second law of thermodynamics. As time goes by and business changes, the complexity of enterprise IT systems will become higher and higher.

• Second, there is a well-known law of conservation of complexity in computer interaction design. The complexity of application interactions is not going away, it’s just going to change. The same principle applies to software architecture. Introducing new software architectures does not reduce the overall complexity of IT systems.

Hear here, whether let life, toss over more than we feel a cool cool? : -)

One of the core tasks of modern software architecture is to define the boundary between infrastructure and applications, to cut complexity and reduce the complexity faced by application developers. In other words, let developers focus on core value innovation and leave some problems to the right people and systems to solve.

Let’s start with this diagram to explore the logic behind the evolution of enterprise distributed application architecture.

twitter

Pain of transformation – SOA

In 2004, IBM established SOA Global Design Center. As a RESEARCH AND development TL and architect, I participated in a series of pilot projects of global customers, helping Pepboys, Office Depot and other international enterprises to optimize internal and inter-enterprise business processes with SOA and improve business agility.

At that time, the general background was that with the gradual deepening of economic globalization, enterprises faced intensified competition and business reform began to accelerate. IT systems within large enterprises have evolved over decades. The whole technology system becomes extremely complex, coexisting such as CISC/COBOL transaction application on mainframe system, RPG business system on minicomputer AS400, and C/JE /.net application on X86/Power and other distributed systems.

A large number of application systems are provided by third-party vendors, and some systems are even unmaintained. Moreover, with business iteration, some new business systems are continuously constructed. Due to the lack of reasonable methodology guidance and organic links between systems, several islands are formed, which continuously aggravate the complexity of IT architecture and fail to support business development demands. This is as if the various factions of masters in order to help wounded Linghu chong, the alien true qi into the body, although it can alleviate the injury for a short time. But many true qi can not be fused, agitate each other, down for a long time will be injured on the injury.

Therefore, the primary challenge facing enterprise IT is to integrate a large number of silo-ed IT systems in the enterprise, support increasingly complex business processes, make efficient business decisions and support rapid business change. In this context, IBM and other companies put forward the concept of SOA (service-oriented architecture), the application system abstract into coarse-grained services, building loosely coupled services architecture, can be flexible combination of services through business process, improve enterprise IT asset reuse, improve the adaptability, flexibility and expansibility of the system, Solve the problem of “information silos”.

SOA laid out a set of principles for building distributed systems that are still relevant today:

1. First, services have well-defined, standardized interfaces. The Service definition description decoupled the implementation of Service Consumer and Service Provider, and services should be developed in a contract-first rather than code-first manner. The communication between services adopts document-oriented message instead of RPC protocol, which can solve the decoupling between services and implementation language on the one hand, and can flexibly choose synchronous or asynchronous communication implementation on the other hand, so as to improve system availability and scalability.
2. Services should be loosely coupled and there should be no time, space, technology, or team dependencies between services.
3. The service should be stateless, decoupling the service invocation from the session context state;
4. Services should be autonomous and self-contained, and the implementation of services can be independently deployed, versioned, self-managed, and recovered;
5. Services are discoverable and composable. For example, Service discovery can be done through Service Registry, enabling dynamic binding between Service consumers and Service providers. Business services from different systems can be choreographed and assembled in business processes.

When SOA systems are initially built, most use point-to-point communication connections, with service invocation and integration logic embedded in the application implementation. This approach is indeed a simple and efficient development approach when the number of services is relatively small. However, the biggest problem is that with the growth of the service scale, the communication between services becomes more and more complex, and the connection path and complexity will increase dramatically, bringing great challenges to service governance.

To address these challenges, the Enterprise Service Bus (ESB) is being introduced. An enterprise Service Bus provides the capabilities for connection, transformantion, and mediation between services. IT can connect enterprise internal and various services to the service bus, realize the loose coupling architecture between information systems, shield the complexity of system integration, improve the flexibility of IT system architecture, and reduce the cost of information sharing within enterprises.

The goals of SOA methodology are like the Yi Jin Jing, which can help to sort out and aggregate different realities for my own use. However, the process of cultivation is by no means easy. What are the reasons behind the large number of ambitious SOA projects that do not achieve the desired results?

The success of any IT architecture requires alignment with business goals, technical infrastructure, and organizational capabilities.

On the business side, SOA at the time focused on addressing the stock market of enterprise IT. This has resulted in the SOA methodology being largely narrowed down to Enterprise Application Integration (EAI). In SOA philosophy, opening up the channels between information systems is only the first step. In addition, the enterprise IT architecture needs to be constantly reconstructed and iterated, so as to keep the enterprise IT architecture agile and flexible and continuously support business development and change.

In terms of organizational structure, the IT department was still the cost center and the subsidiary supporting department of the business in most enterprises at that time. Most enterprises lack a long-term IT strategic plan, the IT team also lacks growth identity, and SOA becomes a project operation without organizational support and continuous investment. Even successful projects at the time tended to lose steam under the weight of complexity. Last year, a friend living in the United States sent pictures. The business system we built for our customers 15 years ago is still supporting their existing stores across the country. This is the success of technology projects, but reflects the lack of enterprise technology strategy.

Technically, the ESB architecture, while decoupling business logic from service integration and enabling better centralized service governance, also exposes some serious issues:

1. Due to an overemphasis on reusability of business systems rather than governance and refactoring of enterprise IT architectures. A lot of the implementation logic for service integration is sunk into the ESB (as shown on the far right of the figure above), which is very difficult to maintain, migrate, and extend, and becomes a burden that the ESB cannot afford. We must deal with complexity in the right places, not simply transfer it;
2. ESB is based on a centralized message processing system, but with the rapid development of the Internet, ESB has been unable to meet the challenges of enterprise IT scale growth;
3. The architecture of Smart Pipes, Dumb Endpoints systems like ESB is an architecture that cannot accommodate rapid change and mass innovation. By way of analogy, telecom operators once wanted to integrate video communications, teleconferencing and other complex functions into their telecom infrastructure, with a single Dummy phone terminal providing rich communications services. However, with the popularity of smart phones, the innovation of distributed collaboration tools such as wechat and Dingding has completely overturned the way people communicate, and the telecom network has returned to the fate of pipelines.

Beauty of Emergence – Micro services

With the development of the Internet, especially the arrival of the mobile Internet era, the economic form of the whole world has undergone tremendous changes. The focus of enterprise IT has evolved from the traditional System of Record (transaction System, such as ERP, SCM, etc.) to System of Engagement (interactive System, such as omni-channel marketing). These systems need to be able to cope with the rapid growth of the Internet and be able to iterate quickly, with low cost of trial and error. Enterprise IT has become one of the engines driven by innovation. The ideal of technology expanding business boundaries also helps IT teams to have a sense of mission, which further accelerates the evolution of enterprise IT.

A series of Internet companies led by Netflix and Alibaba led the new transformation of enterprise architecture – micro-service architecture. Apache Dubbo, Spring Cloud and other microservice frameworks have been widely used.

The core idea of microservices is the separation and decoupling of application functions to reduce the complexity of business system implementation. Microservices emphasize the dismantling of application functionality into a set of loosely coupled services, each adhering to the Single Responsibility Principle. Microservices architecture solves several inherent problems of traditional monomer architecture: each service can be deployed and delivered independently, greatly improving business agility; Each service can scale up/down independently to meet the challenges of Internet scale.

Martin Fowler’s definition of microservices architecture

Of course, the disassembly of large single applications into multiple micro-services will also increase the complexity of IT system r&d collaboration, delivery, operation and maintenance. At this point, the microservices architecture naturally came together with DevOps and containers to form the prototype of cloud native application architecture.

The microservices architecture inherits the architectural principles of SOA, but at the implementation level it tends to replace the ESB with a decentralized architecture style of smart endpoints and dumb pipes. These issues are discussed in detail in “The Microservice Thing,” and I won’t go over them again.

Microservices architecture first faces the inherent complexity of distributed architecture, refer to the pitfalls of distributed computing. Microservices frameworks need to be able to address the complexity of service communication and service governance, such as service discovery, fuses, traffic limiting, full link tracing and other challenges. Microservices frameworks such as HSF/Dubbo or Spring Cloud encapsulate these capabilities in the form of a code base. These code bases are built into the application itself, distributed and maintained along with the application.

The original source

Service communication and governance is essentially a horizontal system-level concern that is orthogonal to business logic. But in the microservices architecture, the implementation and lifecycle are coupled to the business logic. The upgrade of the microservice framework will result in the rebuilding and deployment of the entire service application. In addition, because code bases are often tied to specific languages, it is difficult to support polyglot implementations of enterprise applications.

Evolutionary Light – Cloud primordial

SOA adopts a centralized service bus architecture that decouples business logic from service governance logic. Microservices architecture returns to decentralized point-to-point invocation, promoting agility and scalability while sacrificing the flexibility that comes from decoupling business logic and service governance logic.

To address these challenges, the community proposed the Service Mesh architecture. It re-sinks service governance capabilities into the infrastructure and deploys them as separate processes on both sides of the service consumer and provider. This not only achieves the goal of decentralization but also ensures the scalability of the system. Service governance and business logic are decoupled, and the two can evolve independently without interfering with each other, improving the flexibility of the overall architecture evolution. At the same time, the service grid architecture reduces the intrusiveness of business logic and the complexity of multilingual support.

The original source

Istio project led by Google, IBM and Lyft is a typical implementation of the service grid architecture and has become a new phenomenon of “Internet celebrity” projects.

The diagram above shows the architecture of Istio, which is logically divided into a data plane and a control plane. The data plane consists of a group of intelligent agents deployed in sidecar mode, which intercept application network traffic, collect telemetry data, and implement service governance policies. In the control plane, Galley was responsible for configuration management, Pilot was responsible for delivery configuration, Mixer was responsible for policy check and telemetry data aggregation, and Citadel was responsible for security certificate management in communication.

Istio provides a series of high-level service governance capabilities, such as: service discovery and load balancing, progressive delivery (grayscale publishing), chaos injection and analysis, full link tracing, zero trust network security, etc. IT can be choreographed by upper-level business systems into their IT architecture and distribution systems.

But Service Mesh is not a silver bullet, and its architectural choice is to trade for architectural flexibility and system evolution by increasing deployment complexity (sidecar) and sacrificing performance (adding two hops).

In order to solve the challenge of deployment complexity, the community and cloud service providers are making joint efforts: on the one hand, simplifying the automatic operation and maintenance level of the service grid (for example, Ali Cloud greatly simplifies the upgrade operation of Istio and the complexity of cross-K8S cluster deployment through operator); On the other hand, it provides managed service grid services to help users focus on service governance at the business level rather than infrastructure implementation.

In terms of performance, on the one hand, Service Mesh needs to reduce the performance overhead of its own control plane and Service plane, such as offload mixer load as much as possible, and sink the execution of governance policy to the data plane. Another aspect is the need to rethink the boundaries between applications and network infrastructure in the entire communication stack.

In order to realize the interconnection between container applications, Kubernetes community proposed the CNI network model to decouple the container network connectivity from the underlying network implementation. At the same time, K8s provides basic meta language such as Service, Ingress, Network policy to support Service communication and access control of application layer. However, these capabilities are far from meeting the application’s requirements for service governance.

The service grid in L4/L7 has added new features such as traffic management, full link observability, and secure interconnections, implemented through the introduction of Envoy agents running in user space, increasing flexibility while inevitably increasing performance overhead. There are interesting explorations in the community to systematically address this problem. For example, in the Cillium container network, the service control capability (such as service and network policy provided by Kube-Proxy) of the application layer can be reduced to the operating system kernel and network layer by using eBPF/XDP and other operating systems and underlying network capabilities. The Service Mesh data link is optimized to reduce context switching and data copy, which effectively reduces the performance overhead.

Service Mesh is still in the early stages of the maturity curve. In addition to providing flexible Service communication capabilities at L4/L7, the community is also exploring flexible L2/L3 networking capabilities through network Service Mesh. We believe it will be the future enterprise distributed application communication infrastructure.

New ideas and projects are constantly being created in this process, and we need to be able to rationally analyze their business value and technical limitations. Avoid using the Service Mesh as a panacea, and avoid sinking application integration, application-side security, and other business logic into the Service grid to avoid the pitfalls of complexity. Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh

Looking back to history

The general trend of the world, long separated, will be divided. Enterprise distributed application architectures have also followed an on-again, off-again evolutionary path. In today’s era of new technologies, we should not only embrace the architectural changes brought about by new technologies, but also pay more attention to the evolutionary logic and core values behind them and systematically control complexity.

This article introduces the changes brought about by cloud native computing architecture from the perspective of enterprise distributed application architecture. Later, we will share our thoughts on r&d process, integration architecture and other aspects.