There has been a lot of debate about whether microservices are advantageous over monoliths and vice versa, but it is important to state that each of these approaches has its own uniqueness. Let’s take a step back to the early days, most organisations built their applications using the monolithic approach, where the user interface (UI), business logic, and database instances were housed together. However, this was possible because most of the applications were built with simplicity in mind, and end users, i.e., the customers’ expectations, were modest, but since human needs are limitless and have become more complex, it became vital to address these needs and still have the simplicity mindset. End users now expect fast, secure, and continuously improving digital experiences, whether it is an instant payment, seamless eCommerce checkout, or personalised processes such as recurring or scheduled actions like bill payment and more. To address these needs, organisations are gradually shifting to polyrepo paired with microservices architectures to boost their application processes.
What is Monolith and How Does it Differ from Microservices?
Monolith is an approach associated with monorepo and in simple terms, the word “mono” means one and “repo” is the short name usually given to repository, putting these two (2) words together and relating it to Information Technology (IT) simply means the approach of putting all services or projects required for an application to function into a single repository. In relation to monorepo, a monolith can be described as a single and tightly integrated architecture where all system components are deployed and maintained as one application or service. Think of a monolith as a store where foodstuffs, electronics, clothes, medicine, and every other thing needed by customers are kept or housed in a single room and under the same roof.
Practically, we cannot mention microservices without complementing it with the term polyrepo, and by applying the same word combination stated above to polyrepo, i.e., “poly” and “repo”, simply means having multiple projects, but each of these projects has its own separate repository with its own version control, build pipeline, and access permissions. Hence, microservices architecture can simply be described as an approach where a system or an application is divided into small services, with each of the services responsible for a specific function and contributing towards achieving the bigger need or aim of developing the application. In order words, picture microservices approach as a store with three (3) floors up and each floor is dedicated to specific things or items sold in the store i.e., food stuffs has a floor to itself, electronics section has a dedicated floor and clothes section has its own floor too, yet they are seamlessly linked to ensure customers can easily access and navigate within the floors to get and satisfy their needs.
It is essential to note that both monolithic and microservices approaches aim to organise and structure an organisation’s architecture effectively. However, their differences become most notable based on the need that is expected to be addressed. For example, an organisation or a team decides to develop an e-commerce system, the strategic decision on the approach to use can be measured based on the following five (5) areas. By exploring these five (5) key areas, such an organisation or team can safely decide if the monolithic or microservices approach should be adopted.
- Scalability:
Scalability is an important aspect of any system, and since end users’ need requires continuous digital improvement, it becomes a key area to be considered in deciding the approach to be used. With the monolithic approach, it means if a team or an organisation is to scale its application, then it means everything about its system has to be scaled at once. For example, an e-commerce system experienced a surge in the number of orders placed on the platform and the need to scale the order process arises. To achieve what is required, the team will have to scale the entire system and not just the order process because it is tightly coupled to other processes within the system. The challenges here is that it may lead to resource wastage and increase the risk of downtime. On the other hand, microservices requires that each service sits in its own repository and runs as an independent unit. Hence, it means to scale the order process of the eCommerce system then only the order microservice will be worked on and scaled, thereby reducing the risk of complete downtime and ensure the effective use of resources. - Compliance & Security:
Since a monolithic approach is one cap fits all, where most sensitive and least sensitive logics share the same repository then the same access policy cuts across all logics. With this approach, everyone in a particular team i.e. the developers, contractors, solution architects, auditors and more will all have the same access to the entire repository even when they only need access to a single logic within the repository and this is simply because applying security or compliance rules to each logic in the repository is extremely difficult because the logics are tightly coupled. However, the risk becomes more intense and varies per application. For example, it becomes more risker with an eCommerce system where a contractor that is expected to access a marketing automation logic now has access to the platform’s payment logic, user identity verification, anti-fraud engine and more. Alternatively, the microservices approach supports each service to be stored in its own repository and runs independently. With this, access can be controlled per repository, and members of a team can be granted access to only the repository that they need and not all by default. For example, it means the anti-fraud microservice of an eCommerce system can be given stricter security and compliance measure compared to marketing automation microservice. Tools such as HashiCorp Vault can securely store and rotate the secrets, API keys, and credentials used by each microservice, keeping them separate and encrypted while Identity and Access Management (IAM) systems from cloud provider services such as AWS IAM, Azure Entra ID (formerly Azure AD), Google Cloud IAM can be used to control identity, access and permissions granted to each member of a team. However, microservices approach helps to create a layered defence system where sensitive operations are tightly controlled and auditable. - Development Speed:
We are in world where first mover advantage impacts how a platform or solution performs in the market, and it is important to state that development speed is a prerequisite to this advantage. Due to the centralised nature of the monolith approach, development speed is usually restricted to some extent. For example, a team developing an e-commerce system will have all its members share the same build and deployment pipeline, so even small changes can cause bottlenecks if they affect the pipeline’s performance. Also, trying out new frameworks or tools can sometimes become serious issues because changes to one part of a system can break others and deter the required development speed. By contrast, the microservices architecture approach empowers teams to move faster and with greater autonomy. For example, each member of a team developing an eCommerce platform will fully own its repository, including its build pipeline, release cycle, and documentation. This evidently reduces dependencies across the team and enables faster feature delivery and effectively utilizing the first mover advantage. Additionally, teams can also try out new tools or frameworks without negatively impacting each other throughout an implementation process. However, the practice of Continuous Integration (CI)/ Continuous Delivery (CD) with tools like GitHub Actions, Jenkins or GitLab CI/CD allow teams to manage code separately thereby ensuring that changes flow quickly and safely across non-production and production environments with aim of meeting the required speed to market. - Flexibility:
This is another important area to be considered when making a strategic decision either to go the monolithic or microservices approach. The flexibility within monolithic approach is limited, and this can become a liability as the supposed system expands because not every problem is best solved with the same tool or framework. To rectify issues within a system that adopts a monolithic approach, large scale refactoring across the entire codebase of the system is sometimes required, this tends to be complex and risky for the system in question. However, microservices approach gives room for more flexibility, thereby allowing teams to choose the right tools and framework that suits each microservice. For example, an eCommerce platform’s search microservice might rely on elastic search without impacting other microservices. Hence, it is critical to adopt an approach that seamlessly supports system flexibility. - Disaster Recovery and Risk Isolation:
Due to the tightly coupled attribute of the monolithic approach, failures often cascade and a bug in one logic can bring down the entire application or service. This lack of isolation can sometimes cause actions like change rollback after a certain deployment slow and risky, as it usually requires redeploying the entire application. The microservices approach, on the other hand, isolates these risks by separating services into independent units because each service has its own deployment strategy, thereby making rollback actions less risky since only the faulty logic or module will be actioned. To this end, it ensures higher service availability and resilience.
What are the Challenges with the Microservices Approach?
As stated in the five (5) areas above, the major challenge faced with the monolithic approach is the inability to independently work on a module or logic as they are tightly coupled together. Hence, it is sometimes tough to seamlessly scale or even apply different compliance policies across different modules or logic; whatever goes for one module goes for all. However, no architectural approach is flawless because in as much as the microservices approach provides clear advantages in scalability, compliance, and productivity, it also introduces another layer of complexity that must be carefully managed by organisations or teams. This includes but is not limited to the following:
- Infrastructure Need: Executing numerous or multiple independent services means more pipelines, servers, and monitoring dashboards to ensure that every service run smoothly and at full potential. Without proper infrastructure in place, the service visibility and control can quickly become overwhelming. Hence, this may cause such an application or platform not to deliver the expected value.
- Inter-Service Communication: Communication is a constant and required aspect between microservices, and if the communication technique is poorly designed then it may introduce bottlenecks, data inconsistencies, compliance issues, or security risks that render the developed application or platform redundant.
- Version Control and Dependencies: The risk of having duplicated code and/or mismatched libraries is another challenge associated with the microservice approach. If this challenge exists, then it may result in increased maintenance costs and reduced overall reliability.
- Cost: The Microservices approach usually means maintaining multiple servers, pipelines, monitoring, logging, alerting tools, communication layers and sometime different personnels to manage each of these components. No doubt, this can significantly drive up costs such as operational, cloud service, and team management costs.
How can the Challenges be Resolved?
- Infrastructure Need: The introduction of containerisation techniques by such as Docker to package services into consistent and portable units, is one of the effective ways of tackling infrastructure challenges. Also, deploying Kubernetes, Azure AKS, AWS EKS or Digital Ocean Kubernetes Service to load balance, auto-scale, and enable container lifecycle management helps with orchestration and infrastructure challenges. Additionally, adopting tools like Grafana for observability, Prometheus or Azure monitor for monitoring, Loki for logging, Google Cloud Operations, and many more helps track performance across all services in one place and this helps tackle challenges around visibility and monitoring.
- Inter-Service Communication: This challenge can be resolved in many ways, such as the utilization of API Gateways for centralised authentication, throttling, logging and even for version management. Adopting Representational State Transfer (REST) with frameworks such as Google Remote Procedure Call (gRPC) can help to put in place a well-defined and strong communication between services. The use of Kafka, RabbitMQ, AWS SNS etc., can help reduce synchronous dependencies.
- Version Control and Dependencies: The use of common libraries or shared modules is an effective way of managing this challenge. Implementing architectural reviews to detect duplication and keep dependencies aligned can also be used to resolve this challenge.
- Cost: There so many ways to manage this challenge and one of the practical ways which I have applied in course of my experience is the adoption of right-sizing strategies by using cloud platforms that auto-scales so that resources are only allocated when demand rises, and I do not have to pay for what is not used or needed. Furthermore, leveraging on serverless functions such as AWS Lambda, Google Cloud Functions, or Azure Functions for lightweight or rarely used services is also another effective way of managing cost. Finally, engaging in the practice service consolidation and avoiding unnecessary over-splitting of features and grouping less needed features together really helps to manage cost to a significant level.
In conclusion, although each of the approaches stated above has specifics where they fit in but the move from monolithic to microservices approach is more than a technical upgrade but a strategic enabler for any platform, which in-turn delivers the agility, compliance, and speed needed by any application or platform to thrive in a competitive digital economy. Finally, it is safe to say that breaking complex systems into smaller, well-managed modules or components unlocks faster innovation, stronger security, and greater resilience, which are some of the essential factors also considered by non-technical stakeholders to achieve their set goals.
