4 reasons why microservices resonate

Microservices optimize evolutionary change at a granular level.



Microservices are the first post-DevOps revolution architecture.



Microservices make change less expensive.

Because each service is operationally encapsulated, it frees development teams to change implementation details without worrying about inadvertent side effects that affect other services because of shared infrastructure. If each element in your architecture is decoupled, having fine-grained elements allows you to make small, evolutionary changes.

One of the reasons we talk about “microservices” instead of just “services” is the unit of change. Traditional service-oriented architectures are typically designed to maximally leverage shared resources. The side effect of a shared resources design is a lot of physical coupling, where each service shares a monolithic database, an object-relational mapping layer, and lots of shared implementation elements. Architects are also drawn to single sources of truth to eliminate duplication, which encourages “smart” architectural elements like Enterprise Service Buses to handle chores like transformation and orchestration. If you look at SOA architectural goals, the desire is to encapsulate behavior and secondarily share resources. However, traditional SOA architectures make isolated change hard: when everything is highly coupled at the implementation level to share resources effectively, that coupling hinders isolated change.

Microservices strive for integration coupling but no physical coupling. The goal is both encapsulated behavior and ease of operational change.

Microservices are complex.

One of the best attended talks at the O’Reilly Software Architecture Conference was the Rachel Laycock and Molly Dishman talk Microservices: An Entertaining Debate, which highlighted some of the common pitfalls and looming complexity of microservice architectures. Another popular speaker, Simon Brown, famously notes that “If you can’t build a monolith, what makes you think microservices are the answer?” Microservices have many coordinating moving parts. While the tools are getting better, it is still a highly complex architecture with lots of moving parts. You master good engineering practices before attempting this architectural style.

Microservices enable unique opportunities.

Microservice architectures make change less expensive, freeing your business to weaponize architecture. The terrific podcast RadioLab had a story just before the conference on the surprising effect subtle changes in wording on the Facebook photo violations page eventually encouraged people to admit that they just didn’t like the photo. One of the key findings was the difference between “embarrassing” and “it’s embarrassing” —the implication being that the photo is embarrassing, not you. The key enabler for this research? The ability to easily put out subtle changes and measure results, to create multiple versions of behaviors that differ in measurable ways. Facebook eventually saved untold amounts of money in manpower to sort through pictures because their architecture supported incremental, controlled change.

Microservices optimize evolutionary change at a granular level. It isn’t for everyone —many companies will constrast the complexity against the benefits and decide to remain with monolithic or traditional SOA architectures. Which is fine until one of your competitors starts using their super powers against you.

Editor’s note: If you’re interested in learning more about microservices or just want to stay current with emerging technologies, check out the recently released O’Reilly Software Architecture Conference 2015 Complete Video Compilation. Start streaming this video compilation for free.


Public domain beehive image courtesy of Internet Archive.

tags: , , , ,