Get updates to your emailSubscribe
The two hottest IT trends in the enterprise right now are Microservices and containerization. Both are spreading like wildfire but how closely are they related? I’ve talked to many people who now run their applications in Docker containers and claim they’re “doing Microservices”. In fact, much of the Microservices discussion zeroes in on affinities with the container movement and related operational aspects.
Take the stories of Australian financial firm IOOF and online retailer Gilt. Companies like New Relic equate their container support with Microservices and Microsoft recently announced a container-based “platform for Microservices” that is focused almost exclusively on runtime operations. Based on this, one might assume Microservices architecture is simply about achieving operational agility by splitting monolithic applications into containers.
There are a number of reasons for this. First, Microservices and containers actually do go together well – there are standalone benefits to utilizing them jointly. The second reason is that technologists like new technology – if there’s a new approach to building software, it’s a lot more fun to use new tools to do the building than it is to make new stuff with old tools. This is human nature and relatively harmless.
The last reason is that technologists want technology to be the complete answer. That is, having container-based applications wholly define Microservices is more palatable for us than having to consider factors beyond the zeros and ones. This mindset is where the real risk lies.
Maybe I’m different but when I first started following the Microservices movement, one of the things I found most encouraging was the exhaustive analysis of the areas it touched or required beyond technology – culture, organization, methodologies, architecture – and the acknowledgment of how interrelated these things are with each other and with the technology.
Martin Fowler and James Lewis’s seminal write-up takes care to give an elaborate definition of Microservice architecture. Fowler went further and stated what he saw as the prerequisites for success with Microservices, underlining what’s needed to get started and also to ensure people wouldn’t confuse the benefits of Microservices with the benefits of those prerequisites.
I liked this wide-ranging focus on things like bounded contexts, alignment with business domain, conservation of complexity and Conway’s Law. I found this refreshing in comparison to prior IT architecture movements that became all about the technology – service-oriented architecture (SOA) being a prime example.
SOA started out as a new approach to enterprise integration but over time it became a movement focused on protocols, registries and especially ESBs. I’ve blogged and presented in the past on how SOA went astray by taking this technology-only path and how Web APIs, by contrast, succeeded with a more comprehensive view.
APIs are as important to Microservices as containers, so hopefully the holistic and humanistic elements of their success will rub off on those who are adopting Microservice architectures. As for SOA, there is already a significant amount of literature on how it relates to the Microservices movement.
Recognized proponent Adrian Cockroft has even gone so far as to call Microservices “fine-grained SOA”. In spite of this relationship, I don’t think that Microservices has its deepest roots in SOA, which was an enterprise integration movement. The Microservices movement comes from somewhere else.
At the turn of the millennium, enterprise IT was in the midst of a movement toward centralization, driven by mergers, acquisitions and regulations, and highlighted by increasingly powerful CIOs and enterprise architects. SOA was born in this centralized context. However, in the midst of this, the Agile Manifesto was published, representing a force that would swing the pendulum back towards decentralization over the ensuing decade and a half.
Agile begat continuous integration, which begat continuous delivery – and cloud infrastructure emerged as the chicken to the CI/CD egg. DevOps arose as an organizational and cultural complement to these approaches. In each of these evolutions, it was hard to see where one ended and the new one began.
Perhaps that’s because they never ended but simply blended. Microservices are at a current point on this continuum of Agile evolution. They represent the optimal architecture for a DevOps culture to build continuously deliverable software deployed in the cloud. That this architecture has similarities with the original SOA concept in spite of the two movements’ opposite origins suggests there really is something profound in Microservices.
To tie these themes together, read this 2006 interview with Amazon’s Werner Vogels. He defines Amazon’s approach as “service-oriented architecture” but what he describes sounds more like the current definition of Microservice architecture. This was long before containers were a “thing”, proving that you can get a lot of benefit out of Microservices without containers.
On the other hand, Web APIs were central to Amazon’s approach. Most importantly, Amazon’s success came from an approach that was centered on business benefits rather than technological innovation but which was enabled by the combination of service orientation and continuous delivery – all predating the current hype cycle.
So as you embark on your Microservices journey, take care to understand the progression that led to the movement’s creation. And just as you decompose your monolithic application into a discrete set of container-based Microservices, make sure you decompose the collective benefits you hope to achieve and know where each one is coming from.
Taking this “long view” approach will help you avoid the sins of the past and the whole benefit of your journey should be greater than the sum of its parts.
Matt McLarty is an experienced software architect who leads the API Academy at CA Technologies. He helps organizations with their strategy and architecture for APIs, microservices and enterprise integration. Matt recently co-authored the book Microservice Architecture for O’Reilly, with his API Academy colleagues.
The lack of common concepts and axioms is holding the software engineering industry back. This blog post explores the need for a common distributed systems vocabulary to help with that problem.
Matt McLarty on Aug 10, 2018