Microservices
Is it the right approach?
Software systems are complex. Business needs are in constant change. Making the right system design choices allows teams to manage complexity and deliver great products.
Microservices is a software architecture style that can be leveraged to tackle specific challenges in software systems. It promotes the decomposition of applications into loosely coupled services, each one handling a specific part of a system. It can be a great choice to increase agility, resiliency, and scalability of software systems, but is it worth the overhead? This architecture can be complex and challenging to manage, and it might not be the right approach for many teams.
Simplicity is probably one of the most valuable yet overlooked attributes of a good design. System design decisions should make simplicity a top priority. If a microservice architecture makes your system more complex and harder to manage, you should look at other alternatives.
In some cases, though, microservices bring simplicity to an otherwise convoluted and hard-to-maintain single codebase. Microservices can also make deployments simpler in some cases. Deploying a large monolith, especially with intertwined components, can be complex. Every small change might require rebuilding and redeploying the entire application, which can introduce risks and complicate the deployment process.
Software systems are not homogeneous. You could have certain components in your systems that require more computing resources than others. Scaling services individually is more cost-efficient than scaling everything at once. Allocating the computing resources only where they are needed can reduce operational costs.
The key to any organization’s long-term success has always been in its ability to get ideas executed and into users’ hands as quickly as possible and reacting quickly to their feedback[1]. Companies, and the people behind them, need the right system design that can provide the flexibility to iterate faster with minimal cost and risk. Microservices can potentially provide this.
However, keep in mind that the nature of microservices and its network-based communication has important limitations. Bandwidth is not infinite, latency is not zero, and networks are not reliable. These and other fallacies can lead you to make the wrong assumptions.
What factors should be considered before implementing microservices?
Every system design decision requires careful evaluation of its tradeoffs. Microservices may solve some problems but also introduce new challenges. This type of architecture has implications on many levels, from development, deployment, observability, performance, team skillset, and the list goes on.
Goals
The starting point should be defining the goals. Get a clear picture of what your team is trying to accomplish with microservices. In many cases, the same outcomes can be achieved without the overhead that microservices require. Make sure to consider alternatives. A well-designed monolith is a perfectly good approach in many cases.
Project Complexity
Understanding the project complexity comes next. What are the main components of the system? Identify the boundaries, dependencies, relationships, and interactions between them. Domain-Driven Design (DDD) can come in handy. This task is challenging in itself, but it can get particularly difficult if your starting point is a legacy system with poor documentation, low test coverage, spaghetti code, or everything at once.
Throughput
Another important factor is how many requests per minute your system will handle. If you are revamping an existing project, you may be able to use existing metrics.
Scalability needs
There could be some parts of the system, like services or API endpoints, that need to handle more traffic than others. A push notification or an email sent to your users can trigger traffic spikes, and some areas of the system will suffer. How can the system adapt to these abrupt changes in traffic? Which services will take higher loads, and which ones will remain unchanged?
Change frequency
Now, another factor to consider is how much of the project changes and how often. Software projects are living entities that need maintenance, bug fixes, security patches, optimization, and new features. There might be some parts of the system that require more work than others, with faster and more frequent updates.
Skills
Building great products requires a team. How mature is your team when it comes to developing, iterating, testing, and deploying to production? Determine how much effort is required from the team in order to release a new version of your software. Microservice architecture requires a continuous delivery approach, cross-functional collaboration, and the right mix of skills.
Tools available
Managing a system that follows the microservice architecture will most likely require the adoption of certain tools that facilitate the overall process. Maintaining all the services adds a lot of work to the team and, depending on the complexity, it can become unmanageable. Automation becomes essential. Make sure you have the tools to create and maintain robust CI/CD pipelines, monitor communication between services, generate quality reports, diagnose failures, orchestrate services and deployments, network resources, databases, volumes, etc.
Conclusion
Microservice architecture has important benefits, but it is not a silver bullet, and it has many implications on the entire software development lifecycle. Most of the benefits are only tangible in the long term. For many projects, it can be costly and not worth the effort, especially if it’s a short-lived application or you are just starting or building a proof of concept. It can also be an overhead for small teams or applications that are serving just a few thousand users. As with any system design decision, analyzing the tradeoffs is essential. Laying out a plan and looking at the big picture will give you the right perspective to make the right system design choices.
References.
- [1] Winters, T., Manshreck, T., & Wright, H. (2020). Software Engineering at Google: Lessons Learned from Programming Over Time. O’Reilly Media.
- Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O’Reilly Media.
- Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press
- Splitting the monolith
https://www.youtube.com/watch?v=oyY3Iec5IAc
