Enterprise IT needs to be agile enough to be able to respond to evolving business priorities. A majority of today’s enterprises with legacy IT systems and processes have to navigate and negotiate the thorny path of Enterprise IT Integration. Enterprises have traditionally tackled integration as an offshoot of their application development activities. But integration can no longer play second fiddle to application development. It is becoming core to the enterprise as business challenges involve more complex interactions across the value chain.

The ask from integration has evolved further with the emergence of mobile, big data, IoT and cloud. The integrated enterprise now needs to enable ‘always on’ convenience to its end customers. It has to provide data and services as APIs to third-parties authorized by customers along with value-added services that go beyond the regular business operations. The digital forces and their pressure on applications to transform has resulted in two-speed IT - where one IT layer focuses on speed and value services, while the other focuses on stability.

Service Oriented Architecture (SOA) addresses Integration issues to a certain extent by making back-end legacy systems available as a service to front-end applications via central Enterprise Service Bus (ESB). Though ESB does simplify integration to a certain extent, it is expensive and requires specialized skills. This makes integration restricted to the centralized team, creating dependence and slowing down response to change.

It is clear that integration needs a whole new approach to meet the evolving needs of the enterprise, those which monolithic approaches like ESB would be unable to address. There is a clear need for a more robust and scalable integration approach; and Microservice Architecture has rapidly evolved as a much sought-after solution. With multiple benefits like agility and scalability, microservices meets evolving business needs and expectations.

Role of microservices in integration 

Enterprises are resorting to a more modular, loosely-coupled approach to building enterprise IT because monolithic architectures are complex and do not allow for agile changes in functionality. Breaking down an application into small and independent components that can perform discrete services is at the core of microservice architecture. For example, instead of implementing a complete mapping module in a travel application, microservice could focus on only a ZIP-code lookup. This allows for shorter release cycle times, a need-of-the-hour in today’s business context.

Microservice architecture, built on the principles of SOA from integration to implementation, gives flexibility on how services can be realized.

Broadly, microservices can be classified into Journey services, Business services, and Data services.

• Journey Services provide or cater to customer journeys like recommendation services in an e-commerce portal, like search and browse services
• Business Services are those that execute the business functionality like placing an order or withdrawal operations in a banking application
• Data Services help retrieve enterprise data in an easy to consume format like JSON, XML. Example: Checking account balance in a banking application

Microservices as a layer provides services and integration with core applications (see Figure 1). A Journey Service implements an API. In order to achieve this implementation, it can talk to an existing service in ESB, or call new Business Services (which could be microservices). Business Services execute the operations. In order to achieve operations, they can either leverage the services in ESB, manage their own data in the database or call the Data Service layer. Thus, microservices can take on the responsibility of business orchestration (as the logic remains in the microservice). The Data Service layer helps to abstract the underlying persistence and provide the data to the calling Business or Journey Services. Microservices can perform message transformation and protocol translation (with use of libraries like Camel) in order to talk to core/ legacy systems.

Thus, microservice architecture bridges the fast layer and the stable enterprise layer, making integration simpler. The slower speed of evolution of core processes does not slow down the digital layers that sit on top. Microservices offers different ways of providing integration solutions, either using ESB, or providing that capability itself with transformation and routing capabilities. A large Irish bank, for instance, built a strategy for migration from a proprietary ESB platform to a more decoupled, decentralized integration strategy based on microservices. The strategy made the ESB’s functions, such as mediation, transformation and routing, more scalable, flexible and agile.

Microservice architecture reduces dependence on central teams that manage a large infrastructure like ESB, as microservices can talk directly to the core systems if required. Thus, ESB becomes an optional part of the target state architecture. So an enterprise can implement SOA with microservices and provide services without requiring a large central infrastructure like ESB. But rather than completely taking ESB out, enterprises can choose to leverage it where they are working well to expose the services to work independently. The decentralized, agile nature of microservices is best-suited to solve complex and changing integration requirements of a digital architecture while leveraging current enterprise assets at the same time.