Microservices Benefit: Improving Software Engineers’ Productivity
Microservices have become popular in large part because they simplify application deployment and management. At a higher level, however, they also can help your team work more efficiently. Here’s how.
Microservices are an approach to application architecture that involves breaking a complex application into a number of distinct services.
Ask most people to describe the advantages of a microservices architecture, and you’ll get a list like this:
- More agility because the application is modular.
- Cleaner, easier-to-manage code because each microservice is a discrete chunk of code.
- Easier, more reliable application updates because updates can be pushed to individual microservices without impacting other ones.
- Faster performance because (in theory) microservices architectures encourage programmers to design more efficient applications. (This point is debatable, but we’ll save that for a future blog post.)
Microservices and Organizational Design
There is another benefit to microservices that can be easy to overlook. It involves not software itself, but the team that produces software.
The benefit is this: Microservices enable more agile and efficient software delivery teams. They do that by allowing groups of developers and admins to be broken down into subgroups, with each subgroup responsible for certain microservices.
This mode of team organization offers important advantages over more traditional workflows, in which a large team of developers and admins are all assigned to the same monolithic application. Under this latter approach, the productivity of the team can suffer. A development problem that impacts any part of the monolith prevents the whole thing from working, and requires the entire team to switch gears from innovation mode to repair mode before work can proceed. That’s not efficient.
In addition, orchestrating tasks across a large team when developing and managing a monolithic app is challenging. All team members have to familiarize themselves with all of the application’s code, even if they only work with part of it. It’s hard to identify which parts of the application need more engineers assigned to them, and which need fewer.
In contrast, when an application is developed according to a microservices model, individual engineers or small groups of engineers can be assigned to each microservice. A problem with one microservice won’t prevent other teams from proceeding with their work (unless there are dependency issues at play, but this is only sometimes the case).
Engineers need to master the code only for the microservices that they are assigned to; they don’t need to learn the entire application. If development of one microservice is lagging, it’s a sign that the team assigned to it should be increased in size.
In short, microservices architectures allow software delivery teams to organize labor and orchestrate labor more efficiently—which is exactly what a DevOps-minded organization should want to do.
Conclusion
If you’re considering a switch to microservices architectures, think not just about the benefit of how microservices can make your application better in a technical sense. Consider also the ways in which a microservices architecture can improve the way your team works and increase engineers’ productivity.
