The microservices development approach involves creating independently deployable, modular services to build distributed software systems, and this approach is being increasingly adopted in modern businesses. In this article on ACM Queue, Tom Killalea admits they aren’t right for every company, but discusses eight hidden dividends of adopting them.
Firstly, they offer permissionless innovation where third-parties can easily develop new applications on top of existing systems, often seeing potential not identified by the original creators. As microservices systems grow, failures are inevitable, and these concerns can increase with microservices. But, by enabling failure, especially across services, microservices encourage open conversations around state persistence, resilience, dependency management and more in a way that should limit the cascading effects of future failures.
Engineers building on small code bases have a sense of belief and trust in what they are doing since they have overseen every aspect of its development. Migrating to microservices disrupts trust by placing services behind APIs, forcing consumers to relinquish influence over design in return for autonomy and accountability delivered through SLAs. For the creators of each service, this concept supports a “you build it, you own it” model that encourages practices like continuous deployment and automated elasticity to enable greater automation and a lower operational overhead.
Where monoliths make the safe deprecation of anything difficult, microservices accelerate deprecation by allowing engineers to identify services that haven’t meaningfully caught on in supporting innovation. They can then easily stand up competing versions, or build entirely new services that offer more potential. On the backend, microservices end centralized metadata, protecting service consumers from knowing how data is persisted while allowing persistence mechanisms to be swapped out without consumers even being aware.
The microservices approach also concentrates the pain of security and compliance in a very small number of services, supporting a higher rate of innovation in the remaining unburdened services. Furthermore, engineering teams begin to change the testing approach by considering testing earlier in the design phase. This gives teams a clear definition of scope and ownership to encourage the adoption of deployment practices that lead to tests with higher fidelity and a lower time-to-repair for production issues.