A monolithic application is one where all modules are packaged together as a single deployable unit of execution. This is simple business logic and it’s the best approach for small teams when we are looking to create a minimum viable product (MVP) or proof of concepts (POCs).
However, we need a more effective approach when faced with complex application business logic such as scalability and maintainability or when there is a need to adapt to the latest technologies (including cloud). A monolithic architecture can significantly increase time and effort spent on testing and debugging, and this can lead to delays in releases.
Shifting from Monolithic to a Microservices Architecture
A microservices architecture divides the complex business logic into different tiny applications with certain rules. Individual tiny applications can be scaled and maintained individually, and this, in turn, drives faster development. Testing becomes easier and releases are faster. What’s more, independent teams build individual microservices with greater autonomy to operate their services.
Microservices comes with their own set of challenges. In this blog, we will look at three key concerns:
- How do we identify the boundaries between microservices?
- How do we manage communications?
- How do we handle complexity in the deployment setup?
Let’s look at the solutions for these key microservices challenges.
- Identify Microservice Boundaries with Domain Driven Design
Domain Driven Design (DDD) helps define the boundaries that represent the different business processes an application needs to perform.
DDD breaks down complex business logic with the help of certain building blocks such as aggregate root, aggregates, entities, and value objects. The aggregate is a cluster of associated objects (entities and value objects) that makes one of the entities the aggregate root. Only by using this aggregate root can we access other entities, thereby ensuring data integrity within the domain model.
The key to identifying microservices’ boundaries is to use the central building block called the bounded context. Bounded context is the logical boundary within a domain that in most cases is aligned to the subdomains and completely aligned to business capabilities.
Bounded contexts are not isolated and must communicate between individual microservices. The same real-world entities will have different representation in different bounded contexts. For example, a product in payment subdomain and product catalogue domain will have different sets of properties and behavior.
Finally, each bounded context can be considered an individual microservice, which eventually enables its scalability and maintainability.
Diagram 1. explains how e-commerce business logics can be split into different bounded contexts.
2. Enable Event Driven Communication
The second major challenge in microservices architecture is managing communications. Microservices involve both synchronous and asynchronous communications, of which the asynchronous method is preferred. An event driven architecture is best suited to drive asynchronous communication between services.
In event driven architecture, an event is published from one microservice and subscribed in another microservice. We use platforms such as Kafka and RabitMQ to make this happen. But if we need real time responses, we use synchronous http requests via API gateways.
3. Simplify Deployment with Docker and Kubernetes
Microservices application consists of a multitude of services written in a variety of languages and frameworks. Deployment of microservices applications can therefore be complex and challenging. We can surmount this complexity with Docker and Kubernetes container technologies.
Docker is an open source platform that helps package microservices as individual docker images and run them on a container. We can achieve scale merely by increasing the number of containers. Kubernetes is an open source orchestration platform that extends Docker capabilities. It automates deployment and scaling and manages the orchestration of Docker containers.
For more insights on Microservices, read our blogs: