Friday, August 16, 2019

Understanding the Art of Designing Microservices - Part 1


"Microservices" a keyword which is well-known in these days and people are trying to move their systems to use Microservices Architecture to win the clients and also to develop a loosely coupled applications.

Before we go into more technical details will see a experience i had in the context of Microservices. One was, there was a requirement for a system to develop using Microservices Architecture and it was a call from the client side and all were get into to design it. Once it goes live after a month we observed that there were not that much request to the services and almost 10 per month. At this time only we realized whether there should be a system needed for this kind of need, where the traffic is very low. So in this case client initiated and without doing much research on the domain we are implementing the Microservices, went into not a failure but a costly development, which is not needed for the particular requirement.

After this just found cartoon image similar to the situation what happened to us. Courtesy :

The above scenario will not happen if all done a research on WHY the Microservices came in and how this approach is implemented using the Model introduced by Eric Evans.

That means - Yes History is important.

So in this article i planned to cover below and the last two will be covered in my next blog.
  1. History
  2. Service Oriented Architecture
  3. What we are doing with ESB / SOA?
  4. Need for Microservices Architecture
  5. Deriving Microservice Architecture
  6. Getting into Design - Domain Driven Design
  7. Strategic Design
  8. Tactical Design
  9. Uber case study
  10. Guide
  11. Analyze Development Frameworks
  12. Implementing Microservice - A Use case

1. History

When going through the history first we will start with earlier Desktop Application model where when built a code we need to deploy that in all the required Desktops separately.
After to make our application coding reusable the modular concept came in and it was resolved the Application Development concern not the Application Deployment concern.
Then came the client-server model which helped us to deploy all the applications in one server and then all can connect to that server and access the applications. At this level we were able to achieve centralized server concept.

2. Service Oriented Architecture

After all these the service oriented architecture came in and all the combined Applications splitted to several services and the client can access the services through REST/SOAP calls and combined the results to retrieve info from different services.

3. What we are doing with ESB / SOA?

Now we have services in different places and if client want to fetch data from more services then he need to do the coding at the client side and execute multiple calls. To avoid this bottleneck at client level the ESB concept came in and below diagram explains the architecture of it.

4. Need for Microservices Architecture
  • In SOA - we splitted application into several services
  • Introduced ESB to centralize the client requests, to avoid the complexity at the client level.
  • All our centralized ESB code is running inside single server, consider if we want scale down a particular integration then whole ESB instance server machine need to upgraded. And if there is a less used integration it also uses high performance server machine. - This means decentralization needed.
  • When one integration message is large and got a heap memory issue it will shut down all the services and blocks pickup of messages by the inbound endpoint. - This means we need a separate runtime.
  • Coarse-grained and fine-grained services
  • Develop, Deploy, and Scale Independently : Autonomous
Now we have a question?

If we decentralizing who is going to handle the work done by ESB?

Decentralizing the Database and when need data of another service need to go through the API? How to handle this. Upcoming paragraphs explains the concept behind it.

5. Deriving Microservice Architecture

When you see the above image, I have split the components which are used in a typical SOA with Enterprise Service Bus. So now consider that we are removing the Enterprise Service Bus component and after that if we merge the other components we will get a Architecture like the below.
There must be a way to define the Design?

6. Getting into Design - Domain Driven Design

In the previous section we derived the design by removing the ESB and merging all the other components in a way where it can be workable based on our understanding, but in a standard way there should be some concepts or pattern which need to explain how to design the microservices. This was resolved by Eric Evans by introducing the "Domain Driven Design".

So what is domain?

“When we are developing a software our focus shouldn’t be primarily on technology, it should be primarily on business or whatever the activity we are trying to assist with the software, the domain.”

Eg: Banking, Insurance, Transport, Telecom

Microservice and Domain Driven Design relationship?

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

-Martin Fowler

Domain-Driven Design (DDD) is an approach to software development for complex businesses and other domains. DDD tackles that complexity by focusing the team's attention on knowledge of the domain, picking apart the most tricky, intricate problems with models, and shaping the software around those models.

The above definition explains us how the DDD and Microservices inter relate each other. In Simple words DDD is "The software experts and the Domain Experts get together and explore the domain and split them into Models ( Simplification of a system or a process ) and then the software experts will write software based on the Model identified through the discussion between the software experts and domain experts.
Now we will move into more deep to get understand the concepts and keywords behind the DDD. Below diagram explains it.

To explain this diagram, when we started the discussion on DDD we spoke about "Domain", that is the main component. When software experts and domain experts get together they will split this Domain to functional sub-domains. This sub-domain will be split into 3 as core domain, supported sub-domain and generic sub-domain. This segregation done at the Business Level also called as problem space. The way or the design pattern which used here is called as "Strategic Design".

Then you can see another block which mentioned as "Implementation Level or Solution Space". This is the place where Software Experts come into picture. Here the technical design will be made. I'll explain more on this under Tactical Design.

7. Strategic Design

To get it understand here I'm using a "Rise of Nation Image" to explain the sub domain types through the below image.

In Rise of Nation the Town Center is the Main component here we can say it is the core-domain that means this is the place where our main business or profit comes in. Supported Domain, i mapped it to paddy-field as without it the Town center can survive for some time period, but it needed for long term run. And when it comes to Generic sub domain, it is not needed but add additional functionality. Here when you see Temple and Watch Towers, without watch towers the town center can be survived until a attack is on. If there is no threat then it is not necessarily needed.

The mapping between a bounded context and a microservice isn’t always one to one, it may be one to many.

From the Keynote of Vladik's in DDD eXchange 2018
  1. A service is a unit of functionality exposed to the world through it's public interface.
  2. A microservice is a service with micro interface.
  3. The micro interface is relative to the use cases of the system that the service is a part of.
Context Map Explained

This helps to visualize the nature of the relationship and based on the nature , architects can decide what kind of technical solution would be adopted.
  • Shared Kernel
  • Customer/ Supplier
  • Conformist
  • Anti Corruption Layer
  • Open Host
  • Published Language
The above way of communication between bounded contexts will be selected based on the requirement. Another thing which comes when designing the communication is to specify the data flow and it is denoted using upstream and downstream.

The upstream context (denoted with a u) is the context that influences the downstream and might force it to change. Denoted with d, the downstream context undergoes changes on the upstream context.

Shared Kernel: Two bounded-context use a common kernel of code - for example common-component / library, but the other developments are in their own way. Any changes major/minor should be agreed upon all the parties unless it would break other parties code.

Customer/ Supplier: One bounded-context uses the services of another and is a customer of the other bounded-context. The context which produces data marked as upstream and the context which consumes data called downstream.

Conformist: One bounded-context uses the services of another and is not a customer to that other bounded-context. The upstream is not aligned with downstream and does not care they are free to change there published endpoint or contract any time and not taking any request from downstream.
Please refer my next blog [1] for the continuation of this...