Posted on

How to start your journey in 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, Google
  • You are doing this for the first time
  • If you have already researched and have decided that Microservices architecture is going to be your secret sauce

Microservices architecture is believed to be the most simplified 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, discussing in team or online forums:

  1. What exactly is a microservice?
    1. Some said it should not exceed 1000 lines of code
    2. some say it should fit one bounded context (if you dont know what is a bounded context, dont bother just now; keep reading)
  2. Even before deciding on what would be the “micro”service, what exactly is a service?
  3. Microservices does not allow updating multiple entities at once, How do I maintain consistency between entities?
  4. Should I have a single database cluster for all Microservices?
  5. What is this eventual consistency thing all are taking about?
  6. How to 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 for always getting consistent data?
  9. How to manage version upgrades to a few or all microservices? Is it always possible to do it without a downtime?
  10. And the last unavoidable question – how do I test the entire application as an integrated application?

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

Journey to the Microservices land

Now, I’ll share my complete journey towards microservices.

We started researching by

Divide and rule

We understand that if we are developing a big application as a single Java process (single JVM), then its scale is finally limited by the capacity of the underlying single hardware. We cannot keep optimizing the code infinitely. We must architect our application to be able to work on multiple machines as a single co-ordinated application. So we need a way to break our application into smaller components which can be deployed and scaled independently of each other.

Domain Driven Design

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

  • How to break a bigger domain into smaller bounded context
  • and define contract between them

These smaller components are the microservices.

At the finer level, domain driven design (aka DDD) provides tactical methods to help us on

  • how to write code in a single bounded context
  • how to break up the entities and
  • how to become eventual consistent
  • understanding and definig aggregates
  • Event Sourcing and CQRS

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 provides all the functionality that we require to do microservices like:

  1. Writing Services
  2. Testing Services
  3. Integration with Kafka, the messaging framework for message passing between services
  4. etc

From the experience and consultation so far, I would recommend to use Lagom as it greatly simplifies setting up the developer environment with all the right nut-bolts and tools already in place.

This is the part-1 in the series of articles, and I explained on how we got our direction on getting started with Microservices.

In the next article I will talk about what excatly is Domain Driven Deisgn and how to break up a real example domain into different microservices.

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