Microservices explained - is this just tweaked SOA or something much bigger?

John E Dunn |
April 18, 2016

Netflix, Google, Microsoft, Facebook. Everybody is using microservices on the quiet.

It's not clear when the term microservices was invented or by whom but over the last decade it has slowly gained currency to describe an architecture in which web and cloud applications are built from lots of smaller services rather than as 'monolithic' blocks. Today, while it remains a term best known within development circles the influence of projects built on its principles is there for all to see - firms using the model include Netflix, Amazon, eBay, Google, Facebook, Microsoft's Azure, Twitter, SoundCloud, The Guardian online, comparethemarket.com and the UK Government's GOV.UK service.

It's an impressive list but in truth it could extend for several paragraphs. Indeed, it would be easier to say who is definitely not using microservices that who is, some without particularly seeing this as a special innovation. It's just programming in a world adjusted to the idea of constant conceptual innovation and change. People started doing this a while ago but now it has a name.

Microservices v monolithic applications

Every microservices FAQ states somewhere that it is an alternative to the monolithic approach to building applications that has until recently been the predominant development model. In this approach, applications are built as single entities, with the client (e.g. the browser) a server and a relational database cooperating using a flurry of HTTP requests output through HTML. This is still how the majority of applications are built today but it has issues. The linearity of monolithic applications scales quite well - just add more processes in parallel and then load balance. But such applications can be incredibly complex to change with small adjustments affecting the entire application in unexpected ways. Things break, development slows and expense rises.

The microservices alternative

Conceptually, microservices are a simply way of doing the job of a single application using a series of smaller specialised ones communicating over agreed interfaces. It's not an entirely new idea and is an evolution of mostly proprietary component models that have gained traction over the last 20 years including bearing a passing resemblance to the bare bones of Service Oriented Architecture (SOA). However, it is not an agreed architecture with a defined set of frameworks and it better thought of as a new conceptual approach to building and deploying applications to deliver specific advantages.

Despite sounding similar, a microservice is not a software component, a model in which a program is broken down into logical units performing functions and accessing shared libraries. Microservices are complete, autonomous, independent services that work as standalone units and can be programmed in any language and managed separately. Put these units together and you have a microservices application in which the different pieces communicate through APIs and REST interfaces such as HTTP.