Evolving Integration Strategy at Major Canadian Bank, Part 4

Migration From Monolith to MSA

If you can't build a monolith, what makes you think microservices are the answer?[10]

Decomposition of a System Into Microservices

Migration to MSA is a painful and long journey, involving a steep learning curve, and requiring a different mindset and cultural changes.

DDD patterns help to understand the complexity in the domain and define the scope and boundaries. It is important to understand that the Bounded Context could be composed of several services but not vice versa. Sometimes transaction boundaries may dictate service boundaries. The detailed analysis of the decomposition strategies is way beyond the scope of this paper. A good overview of strategies and techniques to define microservices provided in [11]. The company’s story is pretty common. They started with microservices architecture focusing on cool technological things and invested in the advanced messaging mechanisms, serverless platforms, etc. They didn’t think how to decompose the monolith into microservices. The author shows how easy to get from a big ball of mud to a distributed big ball of mud.

Figure 14: Over decomposition of the system

Iterative Approach

Well, we applied our decomposition strategy and have a good understanding of how we want to decompose the system into microservices. How do we get from the monolithic system to well-defined microservices? We need a migration strategy.

As a migration strategy, building a well-structured, modular application with a monolithic deployment architecture will be much more productive initially, and the application may never reach a point where there is truly benefits in absorbing and managing the complexity of many microservices [12]. As Martin Fowler noted: [13]

• Almost all the successful microservice stories have started with a monolith that got too big and was broken up.
• Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

Figure 15: Iterative approach to break Monolith to Microservices

Modular Monolith may be an intermediary step before microservices. The number of decomposition approaches emerged to divide monolith to microservices. The basic approaches, as shown in the diagram below, are [12]:

• Split the monolith — with this approach, we need to identify "seams" in the application where the number and nature of dependencies indicate both a logical loose coupling and a simpler task to implement technical loose coupling.
• Strangle the monolith — Strangler Pattern describes a solution to incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.
• Extend the monolith — this approach is very similar in architecture to strangling the monolith but aims to minimize change to the existing application. In essence, new features that would previously have required significant change management of the monolith will be implemented as independent services.

The decomposition strategy might include a combination of these approaches, i.e. first strangle some services from the monolith, then split or extend the remaining monolith.

Figure 16: How to divide Monolith to Microservices

Isolation Layer

Domain-Driven Design

The microservices architecture derived from service-oriented architecture (SOA) and domain-driven design (DDD). Where to draw the boundaries is the key task when designing and defining a microservice. DDD patterns help to understand the complexity in the domain. Using DDD, models are developed in Bounded Contexts. Chris Richardson sees DDD Bounded Contexts and aggregates as the building blocks for microservices. When we employ DDD, we strive for each Bounded Context to mark off where the meaning of every term used by the domain model is well understood, which is sometimes called a linguistic boundary [14].

To better understand the Bounded Context, let’s consider the following example:

Figure 17: Bounded Context

In this example, we see that the same term, "Account", has a different meaning in the Web domain and Banking domain. Obviously, the Web domain model is not valid in the Banking domain. So, we have two bounded contexts here, each defines boundary where the domain model is valid. We need an isolation layer to protect the models and perform the required translation to have services in these domains talk to each other.

Code reuse between   BOUNDED CONTEXTS     should be avoided. The integration of functionality and data must go through a translation [3]. The translation logic provided by the Isolation Layer.

Architecture

The isolation layer could be part of the consumer, part of the provider or implemented as a standalone service. The major use-cases include [3]:

Customer/Supplier

The consumer/provider relationship is that of customer and supplier, when customer's requirements must be met. The different customers' demands have to be balanced in negotiation—but they remain priorities. Service Provider must create Isolation Layer to meet Service Consumer requirements.

Figure 18: Customer/Supplier

Conformist

Sometimes the provider has no motivation to customize the interface to meet the requirements of a specific consumer. The consumer, in this case, must conform to the interface exposed by the provider. He can adopt the provider’s model but in most cases, it is not realistic. The more practical option for the consumer is to create an isolation layer that will transform the consumer model to the provider model.

Figure 19: Conformist

Anticorruption Layer (ACL)

• Anticorruption Layer is a means of linking two Bounded Contexts. Create an isolation layer to provide clients with functionality in terms of their own domain model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in both directions as necessary between the two models.

Figure 20: High-level architecture of the ACL

The public interface of the ACL usually appears as a set of services. One way of organizing the design of the ACL is as a combination of facades, adapters, and translators, along with the communication and transport mechanisms usually needed to talk between systems.

Implementation

There are a number of options to implement the isolation layer. Usually, the implementation will leverage well-known patterns as adapter, façade, proxy, etc. [15]. One option is to write the transformation logic from scratch in custom code. Another option is to leverage some open source or COTS tools and libraries.

As explained earlier, the isolation layer could be deployed as part of the service consumer, service provider or as independently running service, depending on the integration use-case.

The diagram below represents the end-to-end lifecycle to create a service when transformation logic and the service business logic packaged as one service. The transformation logic implemented with Red Hat Fuse Integration Services (FIS). FIS provides a set of tools and containerized xPaaS images that accelerate the development of the transformation logic within Kubernetes. FIS comes with 150+ built-in components and data transformation patterns [16].

Figure 21: High-level end-to-end flow architecture of a service generated by APIF

• API Foundation generates a project, including API Stub and distributed API Gateway (APIF Handlers)
• Developers implement service business logic
• Developers implement transformation logic. FIS used to facilitate development.
• Ready to deployment service image created to include business logic, Isolation Layer (transformation logic) and API Gateway (APIF Handle)

Read More!

The series of articles discuss challenges of modernization the technology landscape in the major Canadian Bank, introduces Integration Pattern and API Foundation Platform and provides actionable recommendations to implement the pattern:

Part 1: https://dzone.com/articles/evolving-integration-strategy-at-major-canadian-ba-1

Part 2: https://dzone.com/articles/evolving-integration-strategy-at-major-canadian-ba-4

Part 3: https://dzone.com/articles/evolving-integration-strategy-at-major-canadian-ba-3

Part 4: https://dzone.com/articles/evolving-integration-strategy-at-major-canadian-ba-2

References

1. https://www.networknt.com/
2. https://www.youtube.com/watch?-RhMIlo&.be
3. Domain Driven Design, by Eric Evans, 2003
4. Reconciling GraphQL and Thrift at Airbnb, by Adam Neary, May 29, 2018
5. Innovation Insight for Microservices, Gartner, Published: 27 January 2017 ID: G00312990, Analyst(s): Anne Thomas, Aashish Gupta
6. Pattern: Backends For Frontends, Nov 18, 2015, by Sam Newman
7. Innovation Insight for Microservices, Gartner, Published: 27 January 2017 ID: G00312990, Analyst(s): Anne Thomas, Aashish Gupta
8. F1: A Distributed SQL Database That Scales, Google, Inc., University of Wisconsin Madison
9. https://www.cockroachlabs.com/
10. Distributed big balls of mud, 2014, by Simon Brown
11. Bounded Contexts, Microservices, and Everything in Between, Vladik Khononov, 26th April 2018 in London at CodeNode.
12. How to Design Microservices for Agile Architecture by Gary Olliffe, Gartner, Jan. 2017
13. Monolith First, Martin Fowler, 3 June 2015
14. Implementing Domain-Driven Design, by Vaughn Vernon, 2013
15. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm, 1995
16. Enterprise Integration Patterns, by Bobby Woolf and Gregor Hohpe, 2004
17. http://eventuate.io/ platform by Chris Richardson.