On SOA, microservices, and neologisms

I had the opportunity to present on microservices and Node.js at NodeSummit a few weeks ago. The funny thing is, so did Joyent CTO, Bryan Cantrill. He very graciously tweeted my slide deck to his 5,400+ followers here. It was all very flattering, considering that Bryan is a seriously great presenter.

We ended up doing an ad hoc discussion panel in which he asked, why does the term "microservice" seem to rub some people the wrong way?

I can understand the natural inclination to object to introducing new "buzzwords" for old ideas. The objection is basically that there is already a term for describing a system design pattern in which components provide services to other components over some type of communication protocol: service-oriented architecture (SOA).

That's a fairly generic and abstract definition, so one could say that microservice architecture is SOA, but in fact it's a bit more nuanced than that.

For more than a decade, the term SOA has come to have a strong association with web services, SOAP, WSDL, WS-* standards, and everything else that implies, including generated SOAP stubs and proxies, application servers, service buses, and cumbersome deployment environments. This Gartner Report noted the mutually influential relationship of SOA and web services back in 2003.

Of course, using SOAP-based web services is just one way to build service-oriented architecture. You can implement SOA with REST services as well, but the shared history of SOA and SOAP-based web services since the last decade has practically tethered the two in the mental model that comes to mind.

Before the ascendancy of REST APIs, SOAP-based implementations dominated SOA discussion (see this 2004 Microsoft Journal article for example). Unfortunately, this long association is hard to ignore.

While the Oasis Reference Architecture Foundation for Service Oriented Architecture Version doesn't specifically mention SOAP-based web services, it certainly does nothing to help dispel the notion of cumbersome complexity associated with SOA.

There's a good reason why REST APIs have become so prevalent. REST is the foundation of modern web architecture at Internet scale — and REST services are so easy to reason about.

"Fine grain SOA"

— Adrian Cockroft, former Netflix architect

So far I've avoided actually trying to define a microservice. Like service-oriented architecture, you would be hard pressed to find a strict, canonical definition everyone agrees on. There's no official standards body definition to refer to. Fowler and Lewis of ThoughtWorks published an article describing common characteristics of microservice architectural style in March 2014, but the term has continued to evolve and be refined since then.

Terms enter into a professional vocabulary at some point when it becomes easier to use them for efficiency than to explain what you mean. Fowler defends his trait of introducing neologisms here, quoting from The Gang of Four to rationalize that domain-specific jargon allows us to communicate at a higher level of abstraction.

When "cloud computing" entered into the vocabulary, there were those who dismissed it as new buzzword for an old idea. The objection was something to the effect that we've been doing cloud computing all along. But the term stuck because it's easier to use a single term than to elaborate on the specifics of a nebulous concept each time it comes up in discussion.

When someone mentions the Cloud, I immediately understand that they're talking about self-service, on-demand provisioning of elastic and virtualized compute and storage resources from a massive online shared pool. If you say public, private, or hybrid cloud, I get a sense of whose infrastructure you're referring to. I don't think about timesharing on a mainframe, or any of the other things people say we were doing online before we called it the Cloud. I definitely think of Amazon-type cloud computing.

So when someone mentions microservices, I definitely don't think of SOA the way we have thought about it for at least the past decade, and I don't think of any of the previous generations of component technologies with their proprietary binary communication protocols. In my mental model, I think of self-contained (as in containers) lightweight processes communicating over HTTP, created and deployed with relatively small effort and ceremony, providing narrowly-focused APIs to their consumers.

At some point, a neologism becomes a profession's term of art. Microservice might not yet have an established, specific meaning, but as a practical matter when I hear the term I think Node.js and Docker. In my next blog post I'll explain why microservice architecture is ideally suited by the convergence of these two technologies and how it benefits your team.

I originally published this article on Codefresh.