In the crowded world of software architecture, yet another new name has emerged in recent years: in the form of microservices.

Microservices architecture is a new approach to developing a single application by using a combination of small services – each with its own process and the ability to communicate using lightweight mechanisms. The idea is that they are built around fully automated deployment machinery and business capabilities. In this guide to microservices we offer some examples of microservices and examine the differences between microservices and SOA.

What exactly are microservices?

There is no direct definition of what makes up microservices architecture but there are a number of philosophies associated with it. Firstly, services should be small and carry a singular business purpose – the idea being to do one thing, and do it well. The culture of the organisation should embrace deployment automation; and design and culture principles should embrace both faults and failure… much like anti-fragile systems.

In addition, there are some key characteristics that are exhibited by nearly all architectures that suit the label. These include:

• Componentization via services: There has been vast progress in the ability to build systems that plug components together. Microservice architecture makes use of libraries but will also break down its software into services. With clear, separate services there is the advantage that the components are independently deployable and you gain from having an explicit component interface. Of course, there are some negatives to this approach too: namely remote calls will be more expensive and if you have to alter responsibilities of components these behavioural movements will be harder to complete as you cross boundaries.
• Business capabilities organisation: With the microservice approach, services are organised around business capabilities. These services will take a broad-stack approach based on an individual business area: supplying a user interface, external collaborations and persistent storage.

Microservices examples

There are many popular examples of microservices architecture being employed. Some of the most famous include:

• Amazon: Amazon has created one of the largest forms of microservices with its idea of the Two Pizza Team: in which the whole team can be fed with two pizzas. This means there should be no more than a dozen people devoted to one service; although conversely, there are also smaller scale versions of microservices available elsewhere in which there is a single person per service.
• Comparethemarket.com: The insurance comparison giant uses cross functional teams that are each responsible for the build and operation of a product: while each product is split across a number of individual services that communicate using a message bus.

Others that have pioneered this architectural style include: The Guardian, Netflix, the UK Government Digital Service and Forward.

What is the difference between microservices and SOA?

While the idea of SOA and microservices both come from the same frustrations with monolithic applications they are certainly not the same.

SOA applications are usually driven by managers and work from the top down: whereas microservices applications are more of a trend among the grassroots developer. There are many reasons why microservices should prove to be more successful in the long term, including:

• Simplicity: Whereas SOA grew from web services defined by Microsoft and IBM as simple object access protocol (SOAP) this has generally been replaced now by Representational State Transfer (REST) which is easier and more lightweight.
• Micro differences: With SOA, services could be any size which often meant that there were lumbering old enterprise apps and several big software vendors even tried to create their own brand of SOA. While there is no strict size limit with microservices, the basic idea is that each service follows a single function making things much easier and simpler to follow.
• Cloud infrastructure: Shared services proved to be a big problem with SOA because enterprises would often look for the “best” services within their organisations which would then be shared among multiple applications. However, when they were pinged across the service at the same time, there were inevitably some timeouts and slowdowns. This problem has been addressed with microservices thanks to auto-scaling functionality.
• New container technology: The open source project Docker could prove to be a vital component in the development of microservices. Decomposing monolithic services means there are a lot of services places overhead: with Docker this can be easily managed and deployed.
• Faster and reliable networks: Whereas SOA services were reliant on a network – which often meant a rise in risk and latency – with microservices, networks are faster and more widely available.
• Reduction in politics: Arguably what really killed SOA is that it relied on serious organisational changes – with the idea being that services should be sliced up based on their business function and, inevitably, this met with resistance. However, with microservices architecture there is a way to speed up development while avoiding unnecessary work just by using a simplistic internet technology rather than a large vendor solution.

So are microservices the future?

There are criticisms of microservices: namely that the services form information barriers and the architecture creates new problems such as latency, load balancing and message formats.

It’s hard to say that microservices are the future but clearly there are many successful examples of this architectural structure. What’s clear is that most experiences have been positive compared to monolithic structures but only time will reveal a full judgement. For now, you may wish to proceed with cautious optimism.