My last microservices post welcomed the opportunity to further the conversation about service oriented architectures, because frankly the SOA job isn’t done yet. But I didn’t actually talk about what microservices are. Here I write down a simple definition.

Well, actually there isn’t one. Microservices are a little like duck-typing, they have characteristics. Since microservices are rapidly ascending the hype curve there is naturally a lot being written about them (this post notwithstanding), so where to start? Undoubtedly the “go to” place is the article written by Martin Fowler and James Lewis in March this year (hereafter MFJL). That article, which characterizes the microservices architecture, triggered a backlash about the introduction of a new term when perhaps SOA could suffice. MFJL subsequently added a few sidebars to address these objections and in particular to articulate how microservices are different from traditional SOA.

MFJL aims to give a shape and a name to an application architecture style that was already out there. As James Lewis says in his 2013 talk at “Agile on the Beach”—“None of this is new, it’s all just standing on the shoulders of giants”. The term “microservices” was discussed and eventually agreed by a group of practitioners at a series of meetings through 2011-12 based on what they saw was becoming a common architecture.

Fred George has a great presentation on microservices architecture, subtitled “A Personal Journey of Discovery” detailing his architectural journey from 2004 onwards (also on YouTube). Udi Dahan provides an erudite description of the bounded context and doesn’t mention the “m” word once in his 2011 talk on “Domain Models & Composite Applications”. Adrian Cockroft’s Netflix architecture is cited as an influence which of course is SOA constrained by the demands of an ephemeral infrastructure.

Indeed, it seems that microservices spring from a collection of handy tools and techniques, enabled by new technologies and brought together to address application architecture, something which hasn’t changed substantially since the three-tier architecture emerged twenty years ago. Some of the ingredients in this pudding include: agile, SOA, domain-driven design, polyglot languages, REST, continuous delivery, events and devops.

All of these talks and articles provide good information on microservices and you should read them. But perhaps for the impatient, I’ll attempt here to summarize their characteristics described by MFJL and other sources.

First, on the negative side, many people define microservices by what they are not! Microservices are not monoliths. They are fundamentally a rejection of big monolithic application architectures—the “Big Ball of Mud”.

On the positive side, microservices are characterized by:

• Services with uniform interfaces as the primary form of encapsulation.
• Small with a single responsibility—small enough to throw away and write again.
• Containerless and installed as well-behaved Unix services.
• Organized “vertically” along business capabilities (or bounded contexts) rather than “horizontally” along technology boundaries.
• Products that have a lifecycle and end-to-end management by a single team, multiple concurrent versions are allowed/encouraged.
• Loose coupling, favouring choreography over orchestration, MFJL refer to this as “smart endpoints and dumb pipes”.
• Decentralized governance where only the interfaces are agreed, implementation details and languages are nobody else’s business, code is located in different VCS roots.
• Decentralized data management means that domain models and database persistence belong solely to each individual microservice.
• Infrastructure is automated to support the complex management challenges of many “moving” microservices and enable rapid deployment of new service versions. Microservices themselves are status aware and autoscaled.
• Design for failure is again a necessary consequence of having many moving parts.
• Evolutionary design like a “living system” the application is long-lived but the individual services are short-lived, continuously changing and upgrading.

MFJL finish their article on a note of “cautious optimism”. They recognize that microservices are yet to overcome a lot of questions and unknowns. Picking the right component boundaries can be hard and recovering from poor choices may be difficult. Versioning, integration, testing and deployment of large numbers of independent services is challenging. And James Lewis says “eventual consitency can be tricky for people to get their head around”. I hope to discuss some of these downsides in a later article on this subject.

So there’s no definition. But I do like the reference that James Lewis makes to the Unix philosophy: