On the philosophical ramifications of microservice architectures
Underlying the current hype of ‘Microservices’ lies an important shift in thinking, similar to the sort of deeper cultural changes that we’ve seen with DevOps.
Microservices represent the liberation and integration of software architecture into agile, decentralized, and distributed software development.
DevArcs, if you will.
Roughly, I consider microservices a collection of principles and properties, including, but not necessarily limited to:
Componentization via Services
Independently deployable
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Martin Fowler — Microservices
As an aside, I will note that ‘Microservices’ is, of course, a ridiculous term, implying size as the most notable characteristic of this architecture, but that is another rant for another day.
Where was I? Microservices. Right. Distributed components via services.
From a purely technological perspective, we’ve been here before. Services, even distributed services, are not new and are not in themselves remotely interesting except to those who cannot remember the past and are condemned to repeat it (J2EE, anyone?).
It is all too easy to be distracted by the technology that enable microservice architectures — containers, infrastructure automation, lightweight frameworks in every color of the polyglot rainbow —but again, we’ve had flavors of most of these technologies for a long time as well.
So what is so different this time around?
Culture. Philosophy. Vibe.
Microservices are really about a set of philosophical shifts in software development, bringing many of the same principles and qualities we’ve adopted in DevOps into the land of Architecture (with a capital A).
Microservices drive architecture as an emergent property of the system. One of the crucial insights of the new generation of services is that good design evolves from working code and small pieces, loosely connected.
High-level abstract hand-waving and big up-front design are the enemy of good architecture and functional teams.
Microservices can be extracted from existing monolithic code bases, without requiring a wholesale adoption of some mythical and idealistic service-oriented platform. Microservices foster small cross-functional teams and enable ownership and responsibility, cutting with the grain of the code, evolving the system architecture as both the organizational and software structures emerge.
Microservices pull software architecture from the high-level and abstract to a concrete and emergent concern of a truly cross-functional development team.
