How to start your journey into Microservices Part -1

Architecting an application using Microservices for the first timers can be very confusing. This article is very relevant if

• You are you beginning to develop an application that can scale like Amazon, Facebook, Netflix, and Google.
• You are doing this for the first time.
• You have already done research and decided that microservices architecture is going to be your secret sauce.

Microservices architecture is believed to be the simplest way of scaling without limits. However, when you get started, a lot of considerations are going to confuse you. Questions arose as I spent time learning about it online or discussing it with a team:

1. What exactly is a microservice?
   1. Some said it should not exceed 1,000 lines of code.
   2. Some say it should fit one bounded context (if you don’t know what a bounded context is, don’t bother with it right now; keep reading).
2. Even before deciding on what the “micro”service will be, what exactly is a service?
3. Microservices do not allow updating multiple entities at once; how will I maintain consistency between entities? 
4. Should I have a single database cluster for all my microservices?
5. What is this eventual consistency thing everyone is talking about?
6. How will I collate data which is composed of multiple entities residing in different services?
7. What would happen if one service goes down? How would the dependent services behave?
8. Should I make a sync invocation between microservices to always get consistent data?
9. How will I manage version upgrades to a few or all microservices? Is it always possible to do it without downtime?
10. And the last unavoidable question – how do I test the entire application as an integrated application?

Hmm… All of the above questions must be answered to able to be understand and deploy applications based on microservices.

Lets first list down all things we should cover to understand Microservices :

• Decomposition – Breaking of system in Microservices and contracts between them
• Authentication – how authentication info is passed from service to service , how diff. services validate the session
• Service Discovery – hard coded , external system based like consul , eureka , kubernetes
• Data Management – Where to store the data , whether to share the DB or not
• Auditing – very important in business applications to have audit information about who updated or created something
• Transactional Messaging – when you require very high consistency between DB operation and its event passed onto diff. services
• Testing – What all to test , Single Service , Cross Service Concerns
• Deployment Pattern – serverless , docker based
• Developer Environment Setup – All Services running on developer machine , or single setup
• Release Upgrades – How to do zero downtime release upgrades , blue green deployments
• Debugging – Pass tracing id between services , track time taken between services , log aggregation
• Monitoring – API time taken , System Health Check
• UI Development – Single Page Applications or Micro Front Ends and client side composition
• Security – for internal users

The First Thing we should learn is how to Decompose or build the Services:

Domain Driven Design:

While researching the methodology to break up the application into these components and also define the contract between them, we found the Domain Driven Design philosophy to be the most convincing. At a high level, it guided us on

• How to break a bigger business domain into smaller bounded contexts(services).
• How to define contracts between them(services).

These smaller components are the microservices. At a finer level, domain driven design (aka DDD) provides tactical methods to help us with

• How to write code in a single bounded context(services).
• How to break up the entities(business objects within the service).
• How to become eventually consistent(as our data is divided into multiple services we cannot have all of them consistent every moment).

After getting the answer to “how to break the application into microservices,” we needed a framework for writing code on these guidelines. We could come up with a framework of our own, but we chose to not to reinvent the wheel. Lagom , Axon, Eventuate are all java based , frameworks which provides all the functionality that we require to do microservices, like

1. Writing services using DDD.
2. Testing services.
3. Integration with Kafka, Rabbit Mq …, the messaging framework for message passing between services.

This is Part 1 in a series of articles. I have explained how we got our direction on getting started with microservices. In the next article, we will discuss about a sample Application and breakup of that using DDD .

Recommended References

Thanks to the blogs by Vaugh Vernon, Udi Dahan, Chris Richardson, and Microsoft. A few specific references:

1. Youtube for Event Sourcing, CQRS, Domain Driven Design, Lagom.
2. https://msdn.microsoft.com/en-us/library/jj554200.aspx
3. http://cqrs.nu/
4. Domain Driven Design Distilled and implementing Domain-Driven Design, by Vaugh Vernon.
5. http://microservices.io/ by Chris Richardson.
6. Event Storming http://eventstorming.com/, by Alberto.

Advertisement