Introduction to Microservices Architecture

I recently returned from the O'Reilly Software Architecture conference where I presented/facilitated a workshop on Rapid Software Architecture Exploration. My workshop went great. According to the reviews it was among the better presentations at the conference -- which is awesome! But that's not what this blog post is about.

Microservices architecture was a significant part of the conference with well over 50% of the sessions dedicated to the topic. And I'm being really nice in saying it was only 50% - I think it was closer to 90% and perhaps could have been called the O'Reilly Microservices Conference. Anyway, so there's a ton of hype on this topic.  And since we're looking closely at the (loosely defined) microservices architectural style for an upcoming project at work, this was a great learning opportunity. I am currently reading the book Building Microservices by Sam Newman but I thought it would be useful to share some of the insights I gleaned from the conference now rather than waiting until I've finished the book.

"And you are now an anointed solider in the microservices army..."

What are Microservices?

Adrian Cockcroft (of Netflix fame) defines microservices as the following.

Microservices are a loosely coupled Service-Oriented Architecture (SOA) with bounded contexts.

This definition has a couple of parts that are worth further exploration.

• Loosely Coupled implies that services are independently updateable units. Ultimately this means that updating or deploying one service should not require any modifications to other services in the architecture. When multiple updates are required this could mean that the partitioning is not quite right and that perhaps services should be refactored to removing coupling or perhaps even combined.
• SOA has been around for more than a decade and many people have commented that microservices architecture is really just "SOA done right". Many of the ideas you may already be familiar with from traditional SOA still apply -- for example, when dealing with data and distributed web-based systems. Some lessons are also out of date, probably the most obvious being that SOAP has gone out of style in favor of lighter and simpler transport mechanisms. To me much of it just seems a matter of technology fashion.
• Bounded contexts comes from Domain Driven Design by Eric Evans. Bounded context requires that a domain model is internally consistent within the context of an explicitly established boundary. In microservices architecture, the boundary for the domain becomes the public API through which all external entities communicate with the microservice. With these explicit boundaries then each microservice represents a partitioning of the whole domain model. The image below from Martin Fowler captures the idea of bounded context fairly well.

Bounded context partitions a model into multiple contexts, each with clearly defined boundaries.
Within the context, the model is self-consistent.

This idea that each microservice embodies a bounded context is actually pretty important and a key to what makes microservices architecture work.

• When the domain model is properly understood and partitioned, this enables the loose coupling among services.
• APIs are derived from boundaries within the whole model.
• Each service focuses on only one (or very few) ideas. Even the example above could potentially be considered too big by some.
• Smaller models are easier to understand, design, code, and test. As a rule of thumb, the context for a service (and the code that implements that context) should easily fit into 1 or 2 developer's memory. An alternative rule of thumb is that a microservice can be completed, tested, and shippable ("done done") in 1-2 weeks time.

Perhaps the most interesting implication of bounded context from the perspective of microservices is that it enables self-organization which is essential for any microservices architecture to succeed. As long as explicit boundaries exist among the domain model, and as long as partitions of the model are self-consistent, an organization can self-organize around domain concepts, which in turn allows software systems that organization builds to evolve to match the current understanding of the domain. Microservices proponents call this "Reversing Conway's Law" and the concept was observed by Fred Brooks in the Mythical Man Month years ago.

[Conway's Law states that] Organizations that design systems are constrained to produce copies of the communication structures of these organizations [...] the organization chart will initially reflect the first system design, which is almost surely not the right one [...] as one learns, he changes the design [...]. Management structures also need to be changed as the system changes...

Therefore, individuals must be allowed to self-organize so that they can evolve the architecture design as necessary. Within this loosely coupled world of bounded contexts in which only one or two people represent the entirety of a single shippable unit, individuals need to be empowered to take initiative and do what is right. The gist is that if you want a loosely coupled system with bounded context then these ideals must be embodied in the teams teams that build such systems.

Blah blah microservices blah blah bounded context blah blah Conway's law.  After a while that's all it sounds like.

There is a ton of hype around this topic almost to the point of absurdity. My gut reaction to all of this is that it's interesting and great to see people talking about modeling, organizational structure, agility, modular design, and useful-but-seemingly-forgotten software engineering fundamentals again -- but I can't help but see microservices as just really excellent packaging for the same old ideas so the consultants and tool vendors can have something new to sell.

After really digging into the literature, I'm not willing to cynically dismiss microservices, but I do hold a healthy bit of skepticism as I get my hands dirty building my first fine-grained, distributed, service-oriented components. Let's say, I'm optimistically hopeful for now and it all seems very interesting but I need to gain more first hand experience.