If a software developer is working on a project, then s/he is essentially working on an application. The scope of this application can vary depending upon the business requirements. It can be as simple as publishing the current time on screen too as complex as managing an e-commerce website.

The basic idea behind microservices architecture is to break down a complex requirement into a set of simpler requirements with each of it implementing a distinct functionality. So, these sets of simpler functionalities when grouped together will serve the purpose of fulfilling one single complex requirement.

Any server-side application, irrespective of its complexity, follows layered architecture which consists of various components – UI Layer, Business Logic, Database Access Layer, Integration Layer. Despite its modular structure, these applications were packaged together and deployed as a single unit i.e. deployed as a monolith. But over time software development kept on evolving. Though monolithic architecture carries its own set of benefits viz. simple to develop, simple to test, simple to deploy, its drawbacks started to frustrate the software engineering community. Let’s look at some of its major disadvantages:

• As monolithic application starts to grow, the code base becomes complex to understand and hence maintainability becomes an issue.
• Scaling gets challenging.
• Continuous build, integration and deployment process starts consuming more time and resources.
• It becomes difficult for a new team member to kick start his/her development.
• It becomes extremely difficult to migrate the application to newer technology or even introducing different technology in any of its modules becomes fairly challenging. Because with time, everything gets tightly coupled.
• Bug in one module, brings the whole application down.

The disadvantages of monolithic applications gave rise to microservices architecture. As mentioned earlier, the idea behind this architecture pattern is to split one large application into a set of smaller, interconnected services.

Each microservice is in itself a small application which is deployed independently and has its own layered architecture consisting of business logic along with various adapters. Some would expose a REST or message-based API and others would consume APIs provided by other services. In fact, if you want to benefit from microservices, then each microservice should have its own database. Though it would disturb the idea of having one database per enterprise model, it ensures loose coupling. Moreover, service is free to use a type of database that is best suited to its needs.

• It reduces complexity of a large application as now one must develop and maintain set of small services independently.
• Scaling your application becomes easy.
• Enables the continuous delivery and deployment of large, complex applications.
• Speeds up the whole development process as now developer can concentrate on his/her specific requirement and kick start the development.
• It eliminates the use of a single technology stack for the long term. When developing a new service you can pick any new technology stack.
• Bug in one module affects just the one microservice. The other services will continue to handle requests.

Microservices architecture has its own set of complexities.

• As microservices architecture is a distributed system, it has all the disadvantages of it.

1. Network reliability becomes an issue. One should choose and implement an inter-process communication mechanism based on either RPC or messaging and write code to handle partial failures.
2. A security mechanism should be tight and should be implemented from the beginning.
3. There are costs associated with maintaining distributed networks.

• Managing distributed transactions becomes difficult if your architecture is following one-database-per-microservice architecture pattern.
• Developers have to deal with additional complexities while developing microservices.

1. Testing becomes difficult as the developer needs to launch that service and all other services that it depends upon.
2. Implementing use cases that impacts multiple services requires careful coordination among team members.

• Deployment complexities.

1. A microservice application typically consists of a large number of services. Each service will have multiple runtime instances. And each instance needs to be configured, deployed, scaled and monitored.

Building complex applications is inherently difficult. Monolithic architecture better suits simple, lightweight applications whereas microservices architecture pattern is the better choice for complex, evolving applications.

Let’s suppose you are doing a POC on some requirement, and you need to deliver it fast. You have zero ideas about whether your work will bring value. The purpose of this POC is just to check whether you’ll be able to proceed further and start implementing your real product or not. You’re not building it for scale. You’re probably going to be running multiple tests and redeploy your application many times. For this, monolithic architecture must be your go-to approach because changing things quickly can be done all in a single place. Opting for microservices architecture would distract you from your primary objective as it comes with its own set of complexities.

Now when your POC is turned out to be a success, you will start your real product implementation. This involves creating a product team with the manager, developers, testers, business analysts along with a product owner. Now, when your team size is small, and you are focused on quick implementation and you’re still figuring out the right boundaries of business and technical features, then again monolithic approach is what you should opt for. But once your product is kicked off, your team size starts growing and you find the need of scaling it further, then you’re probably at the point to optimize for microservices.

Similar is the case with any flagship/legacy application. If this application has been asking for enhancements frequently and you’re struggling with its existing complexities, then, in this case, microservices can come to your rescue.

The microservices approach is all about handling a complex system, but in order to do so, the approach introduces its own set of complexities and implementation challenges. So, if you’re confident enough to manage your system’s complexities with a monolithic architecture, which requires a lot of discipline and coordination within the team, then stick to it. Otherwise, if modularity and decentralization are your primary objective and you’re committed to use cutting edge technologies then microservices architecture is your thing.