Building microservices

In this post we’ll consider major principles and strategies, which will help you to build a platform (application) with reasonably splitted microservices.

How can we identify, whether a piece of functionality should be splitted into a separate microservice, or combine these pieces of functionality into single microservice?
Put it simply, logically independent pieces of functionality should be extracted into separate microservice.

It’s also widely used practice to use Domain Driven Design. Simplest and exhaustive explanation of Domain Driven Design can be found here.

Here are few simple ideas on how to identify and extract domains, sub-domains and microservices within a platform.

Domain Driven Design (further referred to as DDD) operates with so called bounded context. Bounded contexts are based on domain entities (read it simply: nouns from your domain area), which with some approximation are usually represented in form of domain models.
So bounded context can be considered as a set of logically related model entities.

A domain is the platform’s subject matter (problem space). A domain is frequently divided into subdomains.

Think, review your domain model (entities) and stick to the opinion, that it definitely makes sense to decouple a functionality into separate microservice, if it operates with completely different unrelated entities (possibly from different sub-domains).

It’s usually one of the most complex and expensive exercises to prepare reasonably structured domain model for a platform, which requires involving domain experts (subject matter experts).

In this abstract we’ll outline some of microservices challenges and drawbacks, which you’ll have to handle in a microservice platform.

• Numerous components’ management overhead, which usually includes:
  – more complex / sophisticated deployment procedure;
  – managing hosts / ports for each service for various environments. For to handle this, folks frequently use Service Registry.
• Sophisticated Health Check & Monitoring for target state with numerous microservices in place.
• Models: reuse or duplication dilemma.
• More sophisticated Release procedure & inter-dependencies management
• keeping backward compatibility of being updated services in relation to those which aren’t changed.

Brief answer to this question is definitely yes.
Despite initial bigger effort for infrastructure / build jobs setup, necessity of extractting models into separate build dependencies, Micro-service architecture has much better extensibility and will require much less maintainability efforts in long-term.

In next post we’ll consider possible Monolith migration to microservices strategies.