The origin of the term 'microservices' may not be that easy to pin down, but over the past decade the approach to application development and management has reached near ubiquity in the enterprise, with everyone from Spotify to the BBC shifting from monolithic architectures to embrace microservices.
So, what is a microservice?
In short a microservices architecture is a term used to describe the practice of breaking up an application into a series of smaller, more specialised parts, each of which communicate with one another across common interfaces such as APIs and REST interfaces like HTTP.
Each microservice tends to manage its own database, generate its own logs and handle user authentication. This also usually means that containers are involved at the management and operations level.
This is a stark contrast to the old monolithic model of building applications as a single entity on a server underpinned by a single relational database.
Moving to the more modern approach also tends to bring with it a change in culture for engineering teams, with highly specialised teams giving way to mixed product teams, generally running some flavour of devops/agile/continuous delivery.
Who is using microservices?
The microservices approach has gained popularity in the age of cloud and web-scale applications. Its most vocal exponents tend to be companies that were born in this world: Netflix, Spotify, ASOS and Expedia, to name just a few.
The approach has also managed to infiltrate more traditional organisations too, with organisations breaking down their legacy code monoliths into microservices.
The drivers to change are often broadly the same for organisations: having to coordinate releases amongst teams, long feature cycles, database dependencies, single points of failure, changes negatively impacting other product teams and not being able to expose functionality for partners through APIs.
Take the BBC for example. The legacy broadcaster turned to Amazon Web Services (AWS) when it decided to move its iPlayer on-demand video platform to the cloud.
During the AWS re:Invent conference in 2017, lead architect Stephen Goodwin explained how iPlayer was ported to the AWS public cloud infrastructure in 2012, and how the organisation shifted to microservices.
"In reality the system is made up of 30 separate microservices, with messages passing along a daisy chain of services to go through the workflow," Goodwin said.
Another example is insurance price comparison site Comparethemarket.com. During the MongoDB World conference in 2016 Matt Collinge, associate director of technology and architecture at the company, ran through the pros and cons of microservices as they had experienced them.
He said: "Big services tend fail in a big way. If your monolithic application isn't working you aren't making money. In a microservice world if a service stops working it doesn't take down the entire businesses ability to make money. It drives innovation and shortens the build, measure, learn cycle so people feel more empowered to experiment and it is freeing to build things that don't have to last ten years."
It also gives teams more flexibility, they "can have their own backlog of change and scale and release independently which allows the organisation as a whole to move faster," explained Collinge.
Downsides of microservices
That's not to say that microservices are perfect. The complex web of dependencies created by a microservices architecture can lead to some serious headaches.
In a critical blog post from 2014, Martin Fowler - who has some credit with helping to formalise the concept of microservices - wrote: "The biggest issue in changing a monolith into microservices lies in changing the communication pattern."
“Another issue is if the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components," he added. "Not just does this just move complexity around, it moves it to a place that's less explicit and harder to control."
Things have moved on since then, but that doesn't mean that microservices are right for every organisation.
As Collinge at Comparethemarket.com said: "You have to put some effort into design upfront. Just taking a monolith and breaking it into microservices won't cut it if those bits were tightly coupled to start with, you will just end up with tightly coupled microservices, which is a distributed monolith, which is the worst of all worlds."
Engineers from the customer data specialists Segment told Computerworld UK that its move to microservices created new types of event queues formed for each individual partner API destination and service, meaning developers quickly found themselves drowning in complexity.
Alex Noonan, the software engineer who led the project. told Computerworld UK: "Maintenance started to become a pretty big headache for developers. If we did want to suck it up and make the change to every single one of those services, we had to spend multiple days, multiple developers testing and deploying every single one of those services - it became a huge burden, so we ended up opting for not making changes that we'd desperately need."
Segment eventually went back to a monolithic architecture, rolling everything into a single event delivery system the company was building called the Centrifuge infrastructure project.