Enterprises are increasingly adopting microservices architecture to create applications that are easily scalable. In a previous post, we covered the basics of microservices and a look at how they compare with a monolithic architecture. We also discussed some quick pointers of why a microservices architecture is a better choice.
However, the superiority of microservices is heavily dependent upon the application that it is meant for.
For example: if your application is a relatively simple one, or is in the early stages of development, a monolithic architecture is comparatively easier to design. It just requires a basic understanding of exactly what the application is meant to do, and you can create it as a tightly-coupled architecture.
On the other hand, a microservices architecture requires greater developmental and design awareness, to break down an application concept into its constituent parts. And that could lead you to invest more time and resources than is actually required on a simpler or smaller application.
So, when to choose microservices?
While that’s just one example, there are two factors to consider when it comes to choosing between monolithic and microservices architecture - Application & Business Size and Resource Availability.
Application and Business Size
Monolithic architecture is well suited for small businesses with applications that have a limited scope. The application handles fewer requests, has fewer points of failure, and often uses a single database, and hence can be managed with fewer resources.
As the business grows in size, both in customer and code base, monolithic architecture becomes inefficient. With heavier loads on servers, a monolithic architecture would take too long to process several requests and render output within a reasonable amount of time.
With a rising requirement for additional functionalities and features, branching out into a microservice architecture makes sense because:
- You gain the flexibility to develop and deploy each service individually, without affecting other services.
- Each microservice can be simultaneously developed by different teams, and hence the application can be built faster
- Teams can make frequent updates to the application without the risk of altering other functionalities, unlike a monolithic architecture where every change can impact everything else.
Resource availability
The availability of resources is an important deciding factor for monolithic vs. microservices architecture.
Small team
If you have access to a small team, monolithic applications are the right choice. Monolithic architecture gives you fewer points for failure, and hence easier for a small team to identify and resolve. However, each member of the team has to have a sound understanding of the overall context the program and the purpose of each module. Any and all edits or additions to the program will, by nature of tight coupling, affect the overall functioning of the architecture.
Larger teams
Opting for microservices architecture is wise only if you have greater resources at your disposal. As each service in the application is refactored into independent entities, you will need different teams to develop, test, deploy, update, and maintain each service. So even though microservices introduce multiple points of failure in the application, they do not impact the whole application and having service-specific teams makes it easier isolate and fix the exact cause of failure.
Onboarding new resources
If your application development is outsourced to a third-party, or is a long-term project, chances are you will get new developers on onboard frequently. With monolithic architecture, each new member has to understand the complete application before they even begin to work on the application.
However, with a microservice architecture, adding new developers to the team is much easier. Because each microservice is self-contained, they don’t need to have an in-depth knowledge of the entire application architecture.
Opted for a microservices architecture. What next?
Post an evaluation of all aspects, let’s say you do decide to adopt a microservices architecture for your next application. How do you make sure you achieve successful application development with it?.
There are a set of best practices to follow , both at the level of application design, as well as organizational design.
Organizational best practices
Conventional monolithic architectures have their organisations structures such that the development team is separate from the testing and security team, which is different from the deployment and maintenance teams. And each of these teams work on the entire application.
However, with the adoption of microservices, a few changes are required:
Individual teams: Each microservice is independent and dedicated to achieving a particular goal. Each of these need to go through all the stages of development, testing, deployment and maintenance. And hence, each individual microservice should have it’s own dedicated team comprising of people assigned to all of the above stages.
Autonomous teams: Since the microservices are meant to be autonomous, the teams themselves should also be to a certain degree autonomous. This is what allows different teams to simultaneously build different microservices to bring in faster delivery times, without being held up by dependencies on other teams. While communication is essential between all the teams, it should ideally be a function of the degree of coupling between their services.
Once these organizational best practices are met, there’s another set of design practices that can help you create an optimal microservices architecture. And that’s what we will be covering in our next installment of this post. We will also be taking a deep dive into understanding event sourcing microservices and handling deployment with docker.
Srijan is assisting enterprises in moderninzing applications with microservices architecture, primarily leveraging Docker and Kubernetes.
Looking to drive your digital transformation with microservices? Just drop us a line and our expert team will be in touch.
