There’s a great deal of interest in microservices architecture. Forward thinking tech companies have provided the thought leadership; startups and enterprise IT have taken an interest; and technology vendors, this one included, have all jumped on the bandwagon.
We can understand microservices as a set of architectural principles, with supporting methods and technologies. That’s the “how” part of the equation. But we can’t understand the impact, and evaluate the trade-offs, until we understand the “what” and “why” of microservices.
Agility and Apple Pie
Integration architects and senior IT managers need to understand that microservices are really application-level components, implemented as fine-grained services. It’s an agility play: we want to evolve, optimize and dynamically provision these highly cohesive, single-purpose services, independently of each other. We want to do this with minimal impact on the client or presentation tier – in the best case, with zero impact; in the worst case, with changes isolated to a well-encapsulated part of the client.
This kind of architecture forces loose coupling in the presentation and service tiers, which is never a bad idea, practically speaking. Microservices, as a methodology, also tends to emphasize cross-functional teams, working on the application (including its microservice components) as a business solution. It’s a vertical, full-stack development effort, using functional decomposition as the organizing principle. Each microservice provides a specific function for a business application that provides a cohesive solution for a specific set of users. Nothing wrong with that either.
What’s ‘gov’ got to do with it?
But what you don’t hear in the Microservices narrative is a plan for reusable services, with interoperability across the application boundary. While most microservices practitioners aren’t specifically opposed to reusable services, standardized data definitions and APIs, these are lower priorities, consciously or unconsciously traded off in favor of agility and autonomy.
Service centralization and API governance, the most common methods for achieving standardization and reuse, are anathema to microservices. You can’t do microservices if you’re bound by external dependencies on services controlled by an outside group. And subjecting API evolution to a centralized approval process would seriously compromise agility, which is the driving motivation behind microservices.
So, philosophically, microservices architecture is positioned at the opposite end of the spectrum from Service Oriented Architecture. While SOA emphasizes centralization and governance, microservices pulls towards decentralization, autonomy and agility. Organizations that embrace microservices on a large scale can expect to see a much larger number of services overall, with very limited interoperability and reuse across application boundaries.
Is this a favorable trade-off? Is there a middle ground, or a third option? Are microservices techniques and technologies useful, even if we’re not ready to give up on standardization and reuse? Let’s talk!