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:
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.
Microservices architecture has its own set of complexities.
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.
1603, Capitol Avenue, Suite 413A, 2659, Cheyenne, WY 82001, USA