Being deliberate about the desired outcomes of the architecture helps put into context the decisions to be made both technically and organizationally. This entry in the blog series begins to explore why microservices, and why now.
From steam trains to high speed rails
In retrospect, the tracks of microservices were laid by the likes of Netflix, Amazon, Thoughtworks, and others. Although their products are very different, we can find at least one commonality in their businesses: they all move fast. Together, they helped the industry understand how to repackage and apply the best tech and learnings from SOA, DevOps and containerization principles.
When aligned to business outcomes, technology is never chosen for technology’s sake. Containers, for example, aren’t a dependency to doing microservices, but in many cases they can accelerate speed of delivery of services by offering abstraction, isolation, and consistency across the deployment landscape. Further, containers, when married with a unifying platform, deliver on non-functional service requirements and mitigate the inherent stability and efficiency risks of a hybrid distributed architecture.
In that light, the link between a low-level tech to a business outcome is clear.
How many cars can this engine pull?
There are a lot of definitions of what a microservice “service” needs to be. We can certainly go by Martin Fowler’s “what” to start the discussion, but the service is more interesting when we first look at it in the context of the surrounding ecosystem of the “why” and “how” of microservices.
Velocity is a function of friction. The more friction you impose on development, the slower the train will be. Friction can be the result of cross-cutting organizational controls (budget, approvals, governance), IT controls (change and release management, incident and problem resolution, etc.), or within the development process itself (technology standards, fiefdoms of control, talent scarcity). Microservices were born out of resistance to that friction.
There is no shortage of solutions to the friction problem; whether they be process (going Agile, for example) or technical (DevOps, etc). I’ll argue, however, that technology is second in importance to developer organizational structures that replicate the desired technical outcomes as described by Conway and exemplified by 2-pizza teams.
2-pizza teams are the foundation underneath the rails and helps the train move fast. Removing friction by creating specific accountability and independence is the catalyst to acceleration.
The club car
By giving service creators control over the introduction and deprecation of new value, whiteboard wars (such as how “micro” microservices are, or what verbs are used, or where a domain context map lives, for example) become less paralyzing. In Stevey’s Google Platforms Rant we’ll see that service independence, not size, for example, was what allowed Amazon to outpace everyone else. A service should first and foremost focus on being an independently deployable asset with total accountability to the service creator. And, with that, 2-pizza teams begin to answer Fowler’s “what” of microservices.
Because 2-pizza teams have bounded scope, they build well-defined interfaces. When they build well-defined interfaces, they may become independently deployable (possibly through message and event based systems, as will be described later). When they become independently deployable, they become inherently evolvable (versioning thoughts, also later). When 2-pizza teams achieve those “what’s,” they become a highly automated factory.
As those attributes and others like it become easier to deliver on, the team’s focus can shift to optimizing their designs for re-composability, as reuse and refactoring are also outcomes of microservices and enablers to agility. I’ll describe some of MuleSoft’s assets around that later, but generally, the granularity in design should be as coarse as needed when closer to the systems of record, and become intentionally more constrained as innovation is democratized and moves closer to the edge. As each service is introduced, business KPIs should be measurable both within and across boundaries, domains, and vocabularies.
“By failing to prepare, you are preparing to fail.” – Benjamin Franklin
Microservices initiatives don’t fail because they are too disruptive to an organization; failure of microservices initiatives is more often the result of a failure to prepare the dependencies of the initiative.
Do not compromise on the prerequisites, both technically or organizationally, it’ll cost you a pretty Franklin banknote. The next post in this blog series will explore exactly what preparation an organization needs to do to make them most successful on their microservice train, and how MuleSoft can help them do it.
Matt McLarty contributed to this post.
