The key challenge of Microservices

Microservices are finally gaining formal recognition across the IT industry, having been successfully used for a long time.

The microservices concept has been refined since the first wave of Web Services over a decade ago. While contemporary microservices don't necessarily use an Enterprise Service Bus (ESB) or XML, the concept of discrete specialised dedicated services is the same. The most common examples for any e-commerce site are postcode lookups and card payment services, both of which can be provided externally by commercial providers rather than developed internally. 

This division of labour, as recognised in 1776 by Scottish Enlightenment economist Adam Smith, is highly efficient. A person or machine dedicated to one simple repetitive activity can perform that activity faster and to a higher standard than a generalist. (A point now recognised in the IT industry, with specialist expert consultancies, such as Capacitas, often winning business from more generalist consultancies.)  

On the economic benefits of the division of labour Smith states:

“It is the maxim of every prudent master of a family, never to attempt to make at home what it will cost him more to make than to buy...What is prudence in the conduct of every private family, can scarce be folly in that of a great kingdom.”

 The same is true of software design, hence the rise of microservices. Code modules are usually dedicated to one process so this specialisation, or division of labour, is common in software development. Software design can learn from the discipline of architecture, and frequently has.

Christopher Alexander’s book Notes on the Synthesis of Form has influenced many software architects since its publication in 1964.

In this passage he identifies the fundamental conflicts within design:

“Consider a simple example of a design problem, the choice of the materials to be used in the mass production of any simple household object like a vacuum cleaner. Time and motion studies show that the fewer different kinds of materials there are, the more efficient factory assembly is - and therefore demand a certain simplicity in the variety of materials used. This need for simplicity conflicts with the fact that the form will function better if we choose the best material for each separate purpose separately. But then, on the other hand, functional diversity of materials makes for expensive and complicated joints between components, which is liable to make maintenance less easy. Further still, all three issues, simplicity, performance, and jointing, are at odds with our desire to minimize the cost of the materials. For if we choose the cheapest material for each separate task, we shall not necessarily have simplicity, nor optimum performance, nor materials which can be cleanly jointed.”

Alexander rightly identifies that simplicity, performance and interfacing (or ‘jointing’) are the three key design goals. The creation of multiple dedicated components (e.g. microservices) requires multiple interfaces, and whether these interfaces are unique or shared they still require careful design using standards and protocols.

A shared interface (e.g. an ESB) makes design easier and performance more predictable, whereas unique point-to-point interfaces add complexity and make performance more costly to quantify.

These interfaces, whether shared or unique, are potential weak links in the chain and are just as important as the related components: like all virtual bottlenecks –system or service constraints unrelated to physical hardware – they are single points of failure. They need their performance characteristics analysed, understood and modelled, along with the components they connect.

The methods for measuring the performance characteristics of these microservices and their interfaces is well understood, albeit the importance of this is often dismissed.

However, to understand how a whole service can rapidly degrade, it is only necessary to consider the original microservice of the distributed computing era: DNS. How often and catastrophically have IT services degraded due to a DNS server failure? And yet the enterprise DNS server is often the least understood component within a company’s ecosystem.

The transition to a microservices architecture should be cautious and diligent. The importance of understanding the architecture, its implications and its performance characteristics, both in normal operation and during service degradation, cannot be underestimated.

How resilient is the end-to-end service to a single component degrading? What is the end-to-end service’s throughput capabilities, and what is its limiting component or interface, should the workload need to be increased?

Microservices are rightly here to stay; but, whether using an ESB or point-to-point interface, they need to be diligently understood and planned.

The Seven Pillars of Software Performance define the characteristics that we regard as key to end-to-end system performance. Understanding the pillars can help businesses looking to transition to a microservices architecture. To learn more, download our Agile Performance whitepaper.