4 reasons why microservices resonate
Microservices optimize evolutionary change at a granular level.
Boeing 747-8 wing-fuselage sections during final assembly (source: Jeff McNeill)
We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?
Microservices are the first post-DevOps revolution architecture.
The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.
Learn faster. Dig deeper. See farther.
Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.
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.
The preceding is part of our ongoing exploration into learning how to solve programming problems.