In 2012 I saw industry veteran Fred George give a talk titled “Programmer Anarchy” at the YOW! conference in Brisbane. In this he discussed some pretty radical ideas for running software organisations and developing software. Here’s a chat with him from that conference where he runs through some of the concepts:

https://channel9.msdn.com/posts/YOW-2012-Fred-George-Programmer-Anarchy

One of the concepts he espoused was the idea of developing very small, independent applications, “less than a hundred lines of code”, that would be created, updated, replaced or discarded in extremely rapid release cycles. In the Q&A session of Fred’s talk I asked how these concepts would be applied in enterprise software development and I recall his response was something like “That’s not something I’m really interested in”. Around this time I’d been hearing the early rumblings of the coming microservices hype explosion and Fred’s talk strongly bolstered my initial impression of the idea; that it was a fad and totally impractical for most commercial software development. This attitude stayed with me for many years, and I know many developers had a similar opinion.

Jump forward seven years and I’ve recently worked on enterprise software for large companies, built from the ground up with microservices architectures. Somewhere along that timeline my opinion on microservices went from “radical fad” to “mature architecture”. So what’s changed? Has the technology grown up? Or was I too quick to dismiss it in the first place? I think the answer is a bit of both.

I was prompted to reflect on the evolution of my microservices stance after attending a session by Damian Mclennan titled “The most important things you need to know about Microservices”. Damian’s talk was largely centered on domain driven design practices and identifying bounded contexts as fundamental principles of microservices design; practical, proven principles that are a far cry from the “programmer anarchy” of the talk I saw in 2012. After seeing Damian’s talk I put together a session for a group of developers to go through his talking points with them and take a look at how their microservices applications aligned with them. It very quickly turned into a session on domain driven design. While the architects of that system weren’t reading directly from the “Blue Book” (they used some different terminology) they clearly adhered to the principles of DDD in their architecture. This session really solidified my thinking that microservices should be a natural extension of proven software design principles that have been around for a long time, rather than some radical new paradigm.

So it seems like the maturity of microservices architectures must have come a long way in the last 7 years, right? Well, perhaps not as much as you’d think; in hindsight it looks like my (and many other developer’s) initial impressions of microservices back then wasn’t getting the whole picture.

In the same year I saw Fred George talk on Programmer Anarchy, he gave this talk on Micro-Service Architecture at Barcelona Ruby Conference. Here he discussed some of the history of his work that developed his thinking towards what become microservices architecture, and you can see that there is more method to his madness than his “programmer anarchy” suggested. For example, here he discusses breaking up services and their databases in something like bounded contexts.

Around the same time, Netflix was just hitting its stride with a microservices-based platform that would come to transform and dominate the video streaming industry over the coming years, and Soundcloud likewise followed soon after with a similar impact on online music. Talks and articles on the design processes from Netflix and Soundcloud at the time clearly shows that even back then they were applying principles very much in line with the domain driven design that Damian Mclennan talks about now, and that is widely accepted as a core principle of microservices design.

So it appears that it isn’t so much that the concept of microservices has matured, but more that the industry’s understanding of them has. The skeptical impression I had of microservices in 2012 was common in the industry, but perhaps born from a shallow understanding of how they were being implemented (at least by people who were doing them well). While it is always healthy to be skeptical of the latest hype cycle in software development, the evolution of my thinking on microservices has taught me to at least always do my due diligence.