I. Introduction
When comparing the microservice architecture and service-oriented architecture (SOA), it is almost impossible to reach agreement on their relationship with each other. If application programming interfaces (APIs) are added to the melee, it becomes more difficult to understand the differences. Some people may say that these concepts are completely different, they each solve their own set of problems, and have a unique range of applications. Others may be more generous and think they have achieved similar goals and have the same working principle. They may also say that the microservice architecture is a "fine-grained SOA" or "appropriate application of SOA."
Second, an overly simple point of view
The reason why it is difficult to compare SOA and microservices is that their definition leaves a lot of room for interpretation. If you only have the surface knowledge of these two concepts, you may think they are very similar. Some of the key aspects (such as componentization, decoupling, and standardized communication protocols) describe most software initiatives in recent decades, so we need to do more in-depth analysis.
Consider the following simple definition:
Microservice architecture is an alternative method of constructing an application. Applications are broken down into smaller, completely self-contained components, which gives them greater agility, scalability, and availability.
SOA exposes the functionality of applications as easier-to-access service interfaces, making it easier to use their data and logic in next-generation applications.
The following diagram illustrates these definitions. SOA seems to have a corporate scope where applications communicate with each other. SOA exposes services through a standardized interface between applications. The microservices architecture seems to have an application scope that focuses only on the structures and components within an application.
The definition of these SOA and microservices is too simple. In fact, the relationship between them is much more complicated.
Third, the SOA initiative split
When you analyze SOA in more detail, you can see that its original intent is not just to expose the interface as a SOAP web service. SOA is based on two perspectives that satisfy different needs.
3.1 Integrated Leading Technology Elements
The first perspective includes complex proprietary data formats, protocols, and transport mechanisms that require deep integration into existing systems. Then you need to expose them using standardized mechanisms like SOAP/HTTP or recent JSON/HTTP to make them easier to reuse in new applications. This view is shown on the left of the figure below. Part or all of this view is often referred to as the Enterprise Service Bus (ESB) model. However, the word was used at will so as to lose its original meaning.
The need to perform deep integration (integration centers or adapters) and expose these integrations as services or APIs in a standardized manner (public gateways) is essential. This aspect is closely related to integration challenges, and it is also somewhat related to application design. So it does not seem to have anything to do with the microservice application architecture.
3.2 Business Guided Functional Elements
The second point of view comes from the business perspective. The concern is that the interfaces on the current system are largely meaningless. They don't make sense for business. They don't provide the next-generation applications. Their granularity may be too fine, revealing too many complex data models within the system. The data required may be spread across multiple systems. The data model may be different from the terminology used by the business unit.
This requirement requires a refactoring function in order to expose what some business people can actually build into future solutions. This refactoring requires the creation of new applications that bind requests across existing recording systems. In the SOA reference architecture, these applications are often referred to as service components (right side of the figure below). This view expresses the relationship with the process of application design (and thus microservice architecture) and the decomposition of functions into individual components.
3.3 The Challenge of Mixing These Viewpoints
There are differences in the views of organizations on which perspectives have greater challenges. For some organizations, their greatest challenge is the diversity and complexity of integration. For other organizations, refactoring and re-layout to achieve the correct business function is a major challenge. The chart above shows how different views are based on what kind of challenge you think is dominant.
For many organizations, the challenge is that the mix of the two viewpoints is very painful. The reason for the pain is that it is difficult to combine the two viewpoints into a single course of action. Integration tools are not the right place to perform business logic. Instead, you don't want your business applications to be full of technical integration issues.
The goal of most SOA programs is to implement functional aspects. They want business-related services that can be easily accessed to build new applications more efficiently. However, many organizations have exhausted their energy, or, more often, budgets, and the technical integration challenges remain unresolved. In large enterprises, SOA is often considered to be a failure. This idea may be right because they fail to provide the ultimate business value, despite great efforts to improve the accessibility of the recording system. However, in smaller companies (or more constrained environments in large companies), SOAs often claim to have truly achieved business success because they can quickly overcome integration issues and turn this into functional gains.
These two SOA perspectives make it difficult to compare with microservices.
Fourth, API and SOA public service comparison
The API usually represents a low-level programming code interface. In recent years, this word has been misappropriated and used to represent a simple interface provided via HTTP. Usually it is equivalent to REST interfaces that use JSON data format (sometimes XML) to provide data, using the HTTP verbs PUT, GET, POST, and DELETE to describe create, read, update, and delete operations. These protocols and data formats are easier to use than the more popular SOAP-based Web service standards in earlier SOA. In addition, they are more suitable for languages ​​such as JavaScript that are commonly used when creating API requests.
However, the difference between SOA Web services and APIs is not defined by protocols and data formats because they do not use them consistently. The difference lies in the intent behind the API and SOA services. A key difference is their economic principles.
4.1 Reusable SOA
In an SOA program, the exposed service aims to expose each business function so that the service can be reused as much as possible. In this way, each new project does not need to experience the pain of performing the integration with the back-end system again. A typical user is an internal application that tries to place a completely new user interface on the old record system. In doing so, integration is very difficult and it costs a large part of the IT project budget. If you can expose all the company's core functionality through a reusable interface, you can significantly reduce project costs. SOA aims to save costs instead of creating new revenue.
The API has different starting points and it assumes integration has been simplified. This simplification is achieved through an earlier SOA initiative or by upgrading back-end systems to provide easier-to-use modern interfaces. The new challenge is to design an attractive interface for potential users. APIs are designed for the context in which they may be used. For example, they are well suited to provide the data needed for a particular type of mobile application.
4.2 Dawn of API Management
With the increase in smartphone usage, the popularity of the API is also rapidly growing. Smartphones run rich client applications and create a disruptive new business channel. Therefore, application developers need to simply access back-end capabilities and data; they need an API. The API became a best-selling product, and API providers were fiercely competing to attract the attention of developers. The API's focus is not SOA's focus on reuse and cost savings. Its focus is on usability and competition in participating in the API economy. API is a best-selling product.
Compared to SOA services, this dynamic change has changed the technical requirements for APIs. The API requires a sophisticated portal so that developers can discover and experiment with the API. They also need some mechanism for developers to register to use and pay for APIs. API providers need to be able to set up payment plans to accommodate various API usage. Because the API is public, the public gateway requires strong security features. All of these features need to be self-service and most importantly simple. This change introduces a new IT feature that is now called API Management.
For this reason, the focus of the API is as a function that is exposed to external users; the demarcation line between the API and internal SOA services has become clear. As API management technologies mature, APIs have brought benefits such as ease of use and self-management. As a result, many companies now want to use API technologies and protocols to expose internal company services, as shown in the figure below. The boundaries between SOA Web services and APIs have now become somewhat blurred and almost irrelevant. They differ in the origin, the data model to which users are exposed and used, but many SOA "services" can also be described as internal APIs.
Today, the term API is often used to refer to any interface exposed through REST (HTTP/JSON) or Web services (SOAP/HTTP). APIs are usually categorized by their scope, such as public APIs or enterprise APIs. Companies that maintain SOA initiatives sometimes retain the term "services" for internal and enterprise APIs.
The term API represents an evolution of SOA's "service disclosure." It uses a simpler protocol and is more expert in the disclosure itself, including developer portals, policy control, and self-management.
V. Microservices: an alternative architecture
Before considering the comparison of microservices and SOA, it is necessary to understand the meaning of microservice architecture. From a basic perspective, microservices are an alternative architecture for building applications. They provide a better way to decouple components within application boundaries. In fact, if microservices are called "microcomponents," their actual nature will be more clear.
The boundaries of the application remain the same. As shown in the figure below, although the application is internally broken down into different microservice components, the application is still the same from the outside. The number and granularity of APIs exposed by a microservices-based application should not be any different from building an API as an orphaned application. The first word "micro" in microservices represents the granularity of internal components, not the granularity of the exposed interfaces.
Logically separating components within an application is not a new concept. Over the years, a large number of different technologies have been developed to achieve a clean separation of all parts of the entire application. The application server can run multiple application components within it for a long time, as shown in the middle figure below. Microservices go one step further, with absolute isolation between these application components. They become separate processes running on the network, as shown on the right side of the figure below. In order to achieve decoupling, you should also split your data model to be consistent with the microservices.
Sixth, the advantages of microservices
A completely independent microservices component helps to achieve full ownership and brings the following advantages:
Agility and productivity: The team that develops the microservices can fully understand the code base. They can build, deploy, and test the code base independently of other components in a much faster cycle. Because the microservice component is just another component on the network, you can write it in the language or framework that best suits your needs, and use the most appropriate persistence mechanism.
This method can significantly reduce the amount of code to be written, which significantly simplifies maintenance. It ensures that teams can adopt new versions of new technologies or existing technologies as needed, rather than waiting for the rest of the application domain to keep pace. For the definition of microservice granularity, the microservice component should be simple enough to be rewritten in its next iteration if necessary.
Scalability: Microservice development teams can extend microservice components independently of other components at runtime, enabling efficient use of resources and quick response to changes in workload. In theory, the workload of one component can be transferred to the most appropriate infrastructure for the task. It can also be relocated independently of the remaining components to take full advantage of the network location. Well-written microservices provide extraordinary on-demand scalability, as early innovators and adopters in the field have demonstrated this. These microservices have also been optimally arranged to take full advantage of the resiliency capabilities to access the native cloud environment of a large number of resources in a cost-effective manner.
Resilience: An independent runtime can immediately provide independent recovery capabilities from failures in other components. With a carefully decoupled design, such as avoiding synchronization dependencies and using circuit breaker patterns, each microservice component can be written to meet its own availability requirements instead of introducing these requirements throughout the application domain. Technologies such as containers and lightweight runtimes enable microservice components to fail quickly and independently, rather than invalidating all unrelated functional areas. As such, they are written in a highly stateless manner so that the workload can be immediately redistributed and the new runtime can be called up almost simultaneously.
Examples of these advantages are some of the most common reasons why organizations use microservices instead.
VII. Key Factors to Consider When Choosing Microservices
When deciding whether to write an application as a microservice, you must understand the following factors to ensure that your organization is ready to handle them:
New technology model. Microservices are a completely different approach to application construction. Because they are on the network, they need a whole new set of components on the network. Some support technologies already exist, including service discovery, workload scheduling, container management, and logging frameworks. However, you must put them in a tightly combined collection, which requires a lot of experimentation, skills, and experience. You must identify the elements of a perfect microservice setup that meets your needs, and they may be different from other enterprise microservices.
Application suitability. Microservices are not suitable for every application. One paradox in the current microservices community is that the application of the new, relatively simple, highly aggregated data model adopts the concept of microservices, and doing so will not gain any advantage. In addition, refactoring a complex, existing application into a microservice architecture is a tedious task.
If you are not on an old or new application, when would you use microservices? One suggestion is to not use microservices until the traditionally written application reaches the turning point of complexity. However, to make this method work, you need to write a properly built application from the beginning and choose to perform the transition at the right moment.
Different design paradigms. Microservice application architecture requires different design methods. To get the best results from the microservices approach, you may need to:
You also need:
If you need to take advantage of important rapid scalability, make sure your application logic is stateless.
If you separate yourself from downstream components, you need to be familiar with the subtle potential side effects of asynchronous communication.
Understand the logical consequences of implementing circuit breaker patterns.
Recognize the error handling limitations of HTTP/JSON communication over in-process communication.
Consider network delays in chained interactions.
Accept the final consistency model instead of the transactional interaction you are used to.
Understand how to handle event source applications that do not have a central operating data store.
DevOps maturity. Microservices require a mature delivery capability. Continuous integration, deployment, and fully automated testing are all essential. The developer writing the code must be responsible for the production deployment of the code. Building and deploying chains require major changes to provide the right separation of concerns for the microservices environment.
VIII. How microservices integrate into SOA environment and integration challenges
If our SOA mental model focuses on integration, microservices are completely separate. It is an alternative to writing an application that the integration architecture attempts to connect to, as shown in Figure 1.
However, if our SOA mental model focuses on re-layout applications as "service components" that make more sense to the business, the service components shown on the right side of Figure 2 may look more like microservice components. Microservice architecture can now be seen as an evolution of SOA. To demonstrate this, let us compare the two extremes.
First, consider a new start-up company that has a new idea for an entirely online product such as social media or transactions. Because it does not initially have an existing architecture available, the company must create a new set of applications to meet the unique aspects of the business. The company can then choose to outsource some of the non-core value-added services and use software-as-a-service (SaaS) applications to provide customer relationship management capabilities.
To a large extent, the company's structure may be established from scratch. The main concern may be its ability to quickly add new features with minimal downtime in a continuously available environment (green concept). The company may want to achieve flexible scaling (ie expansion and reduction) based on unpredictable customer demand. It may wish to achieve an all-weather, highly available online presence.
Microservice architecture is a logical choice for many of the company's landscapes, as shown in Figure 6.
New applications may be located in a single microservices framework that provides non-functional capabilities such as scalability, availability, and resource management. You may expect that low-level integration problems are rare because all microservice components and involved SaaS applications will use common protocols such as the HTTP/JSON API for communication. One of the key goals of SOA to expose valuable functionality is that it can be used in conjunction with the entire enterprise. In this example, the boundaries between carefully implemented SOA and microservice architectures have become blurred. If you imagine the perfect implementation of SOA, it may look the same as this example, but only new companies can create architectures of this nature.
This article does not discuss whether SOA "service components" are commensurate in size with microservice components. The granularity of microservice components and their groupings are entirely another topic.
Now let's consider an opposite example, a large company that has grown up and it has established its own IT landscape for decades. This enterprise may be a traditional bank or insurance company and may have hundreds or even thousands of important applications built using technology that dates back decades. The company may have strict divisions such as medical, pension and general insurance, or retail and investment banking. Each business unit may have a separate application that handles its core business. These departments may also have a set of applications, such as human resources, where applications are shared as much as possible.
The company may have developed through the acquisition of competitors. In this landscape, you will find a lot of data duplication between applications. According to the company initially serving the customer, the customer account may be spread across many systems. The relevance of the same customer in multiple systems may not be very intuitive. These back-end applications are often difficult to make changes internally. In this environment, a daunting task for SOA is to re-imagine back-end systems as something more useful for future business needs.
The integration challenge is also complicated. It may require integration tools (as shown in Figure 7) that allow people to access data and functionality from back-end applications in the presence of protocol, transmission, and data format challenges. For historical reasons, this integration approach is often labeled as "SOA," although it focuses only on half of the SOA challenges. It is labeled as SOA because integration is the first area that most SOA initiatives handle. In many cases, this is all that they have done within the available funds.
However, another aspect that companies need to use to implement SOA is to transform data and functionality into more business-centric capabilities. They need to determine how to meet new channels such as mobile, which require a completely different service granularity than traditional applications. To achieve these aspects, companies need to provide responsiveness, availability, and scalability that may not be available in the current system. Applications must be written to meet these new channels in a special style that supports rapid agile changes, offers extreme scalability, and provides excellent usability.
It is easy to see the attractiveness of using microservice architecture for these new applications. As shown in Figure 7, the initial use of microservices in large enterprises focuses on new interactive engagement system applications. SOA concepts may be affected by early integration-centric work. As a result, microservices are often seen as distinct from SOA, which provides greater agility, scalability, and responsiveness, but in many cases these depend on the foundational work of the SOA integration phase.
Nine, combining microservices, SOA, and APIs in the future
From an architectural perspective, SOA has 3 key elements:
Deep integration enables aging systems to expose their data and capabilities to use an interface to discover these data and capabilities;
Services openly standardize and simplify the way these interfaces are exposed to a wider audience;
The service component further integrates the interface into more valuable business assets;
9.1 Deep integration
Some systems still require deep integration capabilities provided by the integration center in order to expose their basic functions and data as APIs. Other systems may be able to provide APIs directly when upgrading to a new version. When SOA tends to integrate deep integration capabilities into a centralized function, key differences emerge. More advanced tools and technologies should support integration in order to more frequently associate with the application owner, as shown in the location of the integration center in Figure 8.
9.2 Service Disclosure
In addition, all systems need to provide APIs as long as they want to stay connected. The application-level API requires a lightweight control layer, as shown in the API gateway in Figure 8. This control layer is an evolution of the concept of service disclosure from SOA. It has become a broader, more decentralized API disclosure.
API gateways and management functions may be a common resource for the entire enterprise. It is "decentralized," and application teams can publish their own APIs. They can also subscribe to their own APIs without the need for an additional team. You can obtain standardized traffic management and monitoring, logging, auditing, and security mechanisms in a standard way across the enterprise while retaining the agility required by business people. These same API gateways can also be used to help manage interactions with business partners and external SaaS features.
9.3 Service Components
Traditional, more isolated applications are still suitable for some implementations. However, microservices provide an alternative way to build certain types of applications, providing agility, scalability, and resiliency that traditional applications cannot. Microservice applications are the most common at the interaction layer. This layer needs their specific characteristics most, supporting the creation of new channel-specific features and Internet-facing APIs.
Tenth, concluding remarks
There are at least two different perspectives on what the SOA intends to achieve. Direct comparisons between SOA and microservice architecture can be fraught with difficulties. The concept of SOA exists in modern architecture but has evolved in many ways. Integration tools, patterns, and standards have also evolved, so features and data are more open to the public. Service disclosure has evolved into an API that simplifies disclosure, use, and management. In some cases, it can also benefit from business functions. New application architectures (including microservice architectures) enable developers to focus more closely on business logic and continuously push infrastructure details into their environment. The combination of these development methods helps to build solutions in a more agile style, helping applications gain new levels of elastic scalability and fault tolerance.
Electrolyte Additive Lithium Tetrafluoroborate (LiBF4)CAS:14283-07-9
Shandong Huachuang Times Optoelectronics Technology Co., Ltd. , https://www.dadncell.com