On a technical level, a Microservice is simply an application that fulfills a defined set of business capabilities in a collaborative framework of applications, that could have otherwise been part of one big, monolithic piece of software. The development of a software landscape based on Microservices is what is referred to as a Microservice Architecture.
Do I need Microservices?
In short: It depends!
If a Microservices Architecture will provide added value for your project or organization depends on various factors. To figure out if opting for a Microservices Architecture is the correct approach for You, the best way is to look at their benefits and drawbacks:
Why Microservices are useful:
1. Highly maintainable and testable
Building software that can be easily tested and therefore maintained has obvious advantages. Less malfunctioning code means being able to focus more on the business requirements that need to be fulfilled in the first place. Easy testing means we can deploy faster.
2. Loosely coupled
This is where the true ingenuity of Microservices come into play. Loosely coupled services not only give systems more resistance, especially when combined with container orchestration, they also provide structure to the overall system architecture which facilitates communication between teams of developers.
3. Independently deployable
Want to add a CRM module to your ERP system, without adding risks to your production environment? Microservices are here to help! Not only are the tasks of different services separated by their business function, the entire deployment can be executed on different containers. If your newly developed CRM system fails, your ERP modules remain unaffected.
4. Organized around business capabilities
A clearly defined business scope for each Microservice enables your project to leverage their loose coupling and independent deployment. You will be able to monitor, control and configure each business functionality as its own application, providing overall system stability and facilitating error handling.
5. Owned by a small team
“The Mythical Man-Month: Essays on Software Engineering” famously stated that adding more developers to a late software project will further delay it. Part of the reason is the exponential increase in communication efforts in a growing team of developers. Using Microservices allows project managers to mitigate this, by keeping teams small and communication efficient.
When to be cautious
You have now learned where a Microservice Architecture can help to make your and your teams’ life easier. What stops us then, from adopting it? It is mainly about so-called anti-patterns, which describes implementation or project management strategies which are meant to solve problems but do more harm than good. Let us look at some of them:
1. The ultimate solution fallacy
A popular pitfall when considering Microservices is to believe that it is a solution that magically eliminates all major problems or that it inherently provides added value to any existing system. Instead, it should be considered an enabler for process improvements that can and should be implemented in the process of migrating to Microservices. If a transformation project fails to address this, rather than solving existing issues, it will exacerbate them. Moreover, if your monolithic system works, the cost and risk of a migration may not be worth the potential benefit!
2. Complexity of a distributed system
While any service specific implementation gets easier once the scope and any interfaces are defined, any functionality that spans multiple services become more difficult with new processes and guidelines to adhere to, when implementing and extending Microservices.
3. Partial Failures
With services deployed as applications, each service may fail and lead to malfunctioning across other services in the chain. Monitoring and preventing this requires additional effort.
4. Multiple Deployments
Where previously only one major system had to be deployed, there is now a potential multitude of deployments to manage.
5. Memory Overhead
Each Microservice will generate a small amount of overhead in processing power and memory. If the difference is significant
6. Scalability versus agility
We learned above, that Microservices can be independently deployed and developed, speeding up the time-to-market for new features. But while that holds true for mature systems of a certain size, it may have the opposite effect for smaller teams and projects. The agility of Microservices comes with the upfront investment of building an infrastructure, defining a development framework, and optimizing processes to leverage the benefits of the architecture. This added cost may prove as an obstacle however, if a small team in a startup requires a pivot that renders large parts of the landscape obsolete.
Making the decision:
You have looked at the benefits and risks of opting for a Microservices Architecture and are now looking for the next steps to take to finalize the decision. A helpful next step will be to ask yourself questions, to figure out what the root problem for your IT issues:
- Are your development and deployment processes expensive or ineffective?
- Has your current system outgrown is original design?
- Does your organization force heavy processes on your developers, that impact their motivation and engagement or steals their time? Will Microservices really solve this issue or just introduce more overhead in an already heavy process?
Once you find the answers to these questions, quantifying their impact on your future cashflow will likely provide you with a cost ceiling, to determine if the investment in a new architecture will be worth it.