In society, you have heard the saying that it’s all about money and who’s got the most.

In the IT world, especially with organizations where constant business changes and IT modernization are the key drivers it is, in my opinion, all about integration and who’s done it right. All these years, the industry has been very much focused on “services” - a concept that every developer and architect may has his/her own definition and understanding, whereas challenges and solutions of doing integration between “services” were not discussed in detail. From Service Oriented Architecture (SOA) to Microservices, the situation didn’t get much better.

In this article, I start by explaining “services”, integration between them, then analyze the challenges and why the SOA solution did not save you, and why microservices may not either. I will also talk about why doing integration right between "services" is the key, particularly what a right integration solution would be and how to deliver it.

What is a “service”?

In both the SOA and the microservices world, a service represents a business activity that is aligned with a business capability, forming business processes. It is self-contained, meaning that a service can be independently developed, delivered and operated. Services communicate with the outside world via well-defined interfaces, events or messaging. The following figure lists some typical business capabilities that reside in an enterprise.

Figure 1 Business Capabilities => IT Services

In a smaller and less complex organization, such business capabilities may already represent the IT services within a SOA or microservices architecture, while in larger and more complex domains, each business capability may further be divided into smaller ones representing finer-grained self-contained IT services. Such logical services resemble how we have done our business for decades, and they are very often well separated and delivered by different IT systems from different departments within an organization. The problem comes when a complete view of all services is needed for sales channels, for customer service, etc. The problem gets worse if different services are managed by different IT vendors with different data models, different communication technologies or protocols, or if they are located in different regions. Integration between all these parts became ad-hoc, messy and difficult to maintain.

Figure 2 Integration Problems

A common and logical way of addressing integration problems is to put a middleware layer between all sales frontends, customer service frontends, and the relevant backend services. This middleware layer is also a natural place responsible for the integration and communication among all backend systems.

A big challenge with this middleware solution is it tends to grow, can be easily joined with cross-cutting functionalities like security, and even mixed with product, customer and order services. If it is not designed and maintained properly, it can become a middleware monolith and a bottleneck for adopting new technologies and handling business changes. Furthermore, many of the SOA implementations have made the reputation of this solution pretty bad. Prevalent SOA adoption emphasized on reuse or service composition which led to wrong understanding of a “service” and centralized data models. It also promoted complex SOAP standards and heavy vendor lock-in Enterprise Service Bus (ESB) products.

Figure 3 The Integration Middleware Solution

Microservices has learned most of the mistakes from SOA, and has come up with many good ideas and successful experiences, such as:

1. SOAP => REST
2. Vendor lock-in => open-source
3. Centralized data models like product, customer, etc. => Each service should own its own data and its database
1. Price of a product belongs to the billing domain and which sales channel can sell what kind of products belongs to the order domain
2. Discount agreement of a customer belongs to the billing domain and blacklist of a customer belongs to the order domain
   
4. Microservices also emphasizes the importance of aligning teams with the business services like product, customer and order rather than technical layers like frontend, middleware, backend and database layers, to obey Conway's law.
5. Microservices is also against separating your development teams from operation ones and rather promotes DevOps. Luckily enough, microservices lives in an era where many of the cloud infrastructure and DevOps tools are mature, making it possible to automatically deliver and operate dozens of (micro) services without too much operational efforts or special operational vendors.

Last but not least, microservices suggests moving integration solution between services from centralized orchestration to decentralized choreography, by event-driven or messaging, and the simplest illustration is like the following figure:

Figure 4 From Centralized Orchestration to Decentralized Choreography

There is a short name of it called “Smart Endpoints and Dumb Pipes”. This is very confusing for many organizations that: 20 years ago, you asked me to add a “bus” in between all services and 20 years later, you ask me to remove it. As architectural best practices are context dependent, microservices might be SOA done right, but it does not mean that everyone should follow it or should follow it 100%. Both SOA and microservices should only be applied to systems that are too complex to manage as a monolith.

1. Very often in such cases, the services are already distributed into different sub-systems belonging to different IT departments, and an integration middleware is usually in place. This integration middleware cannot be and should not be simply removed, but rather it must be modernized with the highest priority.
2. Another common case is that, for many organizations which do not have their own IT departments, it is more cost-effective to buy ready-made IT services like sales, billing, customer service, etc. The services are either delivered by some IT outsourcing vendors or from out-of-the-box products. In such scenarios, an integration application is also a necessary part for moving data across different services that “are at different locations” and “speak different languages”.

From both cases, we see that the world is not either “black” or “white”, but rather “gray”.

The best practice of a decentralized choreography integration solution may work for many organizations, especially those modern IT companies, but it is very unrealistic for many others. Even more so, as all services need to be able to communicate and work together as a whole to deliver values for a company, the biggest and key winning point actually lies in that particular centralized integration middleware to ensure this. If it is well-designed or modernized correctly, it can become the driving force for the modernization of all IT services, and also push the business forward, whereas the opposite is a bottleneck “monolith” for any change either from technology or business side.

Three tips for well-designed integrations

The question boils down to how to deliver a good integration solution or application.

It is actually not that different from how to do microservices in general that you need to start from a context map to know all your domains and therefore your services. One difference here is that they are not services but different modules within the integration application. It means that they are development time independent and have separate delivery pipelines, to guarantee decoupling and fast “time to market”. But they are not running in different containers as microservices do. Instead, they can be run in one container as long as runtime redundancy for high availability are provided. Another difference is that instead of implementing business logic for the domains in services, these modules are mostly just doing the integration logic, moving and mapping data within and between services.

Figure 5 A Good Integration Solution with Well-Designed Modularity

1. To deliver a good integration solution, the integration application has to be well modularized to align modules with the business services to ensure development decoupling whereas runtime decoupling or separation is not necessary to avoid operational overhead.
2. Even though all these modules are serving different services for different domains, they share many technical aspects as they are purely doing the integration logic between services. Therefore, some technical libraries have to carefully designed that can be shared or reused by all business modules. One example is that, some business modules have to be flexible and extensible to support e.g. different sales channels and different payment systems.
3. In addition to a well-modularized application itself, you also need other items from the microservices paradigm like REST, open source, cloud computing and DevOps for your integration solution. Namely, you need a whole package that can do both integration logic and also the facility, infrastructure and IT competence around it. Similarly, as you may buy IT services or products for sales, billing and customer service, integration services and products delivered by special vendors might be your best choice due to the cost-effectiveness and the vendor’s expertise.

About the Author

Liping Mu is a senior software engineer and architect at Greenbird. Her variety of expertise comes from working with Large Tech companies on complex systems and earning her PhD in ICT from the University of Agder. Today, she is maintaining, designing, developing integration solutions for customers including DrammenIKT and Flytoget.