Event Driven Microservices Communicating Using Feeds - part 1

In November 2014, I joined my first project in ThoughtWorks. It was a journey for more than two years and I had plenty to learn. I am writing this blog post to share my few learnings from that project. In this blog, I am going to share my understanding of microservices architecture and its pros and cons. In next blog, I will talk about the event-driven architecture and event feeds.

Before Microservices, Let’s talk about monoliths.

The monolithic architecture is a single piece of software which is self-contained. All the components of the system will be interdependent and will be tightly coupled to each other. All the components need to be present in order to compile the software. The whole software runs on a single machine as a single process. To achieve scalability multiple instances of the same monolith can be run. A load balancer can be used to redirect the traffic to different instances.

Why a different architecture?

While the monolithic architecture has been the traditional model for the design of a software, it has few drawbacks.

• The size & the complexity grows if it is a long-running project. Managing everything in a single codebase becomes a pain.
• Even a tiny change to a specific part of the system requires the whole software to be redeployed and tested.
• The whole system needs to be scaled even though just one part of the system needs scaling.
• If there is a problem with a small part of the system, the whole system becomes unavailable.
• Starting a huge monolith software on your local laptop might not be possible while developing the software.

The Microservice Architecture:-

The Microservices architecture consists of multiple small components following the Single Responsibility Principle. Every component solves one particular and independent part of the business problem. Each of these components will be loosely coupled with each other and will run independently. These components will be communicating among themselves using well-defined interfaces, often HTTP resource APIs.

Benefits of Microservices:-

• Each component has got separate codebase and will be compiled and deployed independently.
• Only the component which requires a change needs to be redeployed.
• Only the components which are heavily used needs to be scaled.
• Unavailability of one component doesn’t affect others which are totally independent.
• The development boxes can be easily setup using vagrant or docker. Only the component which is being developed needs to be started on a local laptop.
• Microservices enable the idea of plug & play. Since the components are loosely coupled and communicate with each other using interfaces, a particular component can be replaced with a different one as long as the interface remains the same.
• Different components can use different technologies(languages, frameworks, databases).

Drawbacks of microservices:-

While there are so many great things about microservices, It comes at a cost.

• The components need to communicate among themselves using remote calls, which decreases the performance.
• Microservices are Eventually Consistent. The updates made to one component might not be available to the other components for some time. However, there should be a time interval in which the updates must be reflected to all the components.
• A Microservices architecture brings a lot of operations overhead. You need to manage more than one services, which are being redeployed regularly.
• Debugging the application can be a pain. Different services will have their own logs and might be on different servers.
• Increased memory consumption, One service will be split into multiple services. If each service requires it’s own JVM(or similar) the memory consumption will increase.
• You might need an API Gateway which defines how clients access a specific service in a microservice architecture.

Is the microservices architecture needed for your project?

The answer is “It totally depends upon the complexity of your project.” The microservices architecture is all about handling complex systems, but it introduces it’s own complexities and comes with drawbacks discussed above.

If we are starting designing a system, better to start with monolith than jumping straight to microservices.

“If you can’t build a monolith, what makes you think microservices are the answer?” — Simon Brown

I personally find it similar to the lessons of refactoring. We should start with a monolith while trying to keep things modular. Once we find out that there is enough responsibility to split this monolith into more than one small services, we should change it to microservices. If we have kept things modular from start, it will be the almost same effort as starting from scratch as microservices.

This is what I have to share about microservices. In my next blog, I will talk about the event-driven architecture and event feeds.