3 Reasons Why Microservices Architecture IS your Answer

Everybody loves high availability. Everything needs to be available all the time – ‘always on’ – whenever and wherever you want it and need it. It’s nothing new and frequently a critical element of system design (think spacecraft, aeroplanes and GPS, for example). However, a rash decision to slap “high availability” on your systems can have seriously detrimental effects on the success of your IT estate operation. Let’s explore what you can do about that. In a previous blog, we looked at a number of fundamental aspects of good system architecture: operational excellence, security, reliability, performance efficiency, and cost optimisation. In this article, we talk about:

• Reliability, Availability, or both?
• A brief introduction to microservices
• 5 reasons to use microservices

Let’s dive straight in. 

Being available does not mean being reliable – say what!?

(High-)availability is sadly often confused with the reliability of the system. Most of the time, both are required in a well-architected software solution. So, how do reliability and availability interplay and interact?  There are many definitions of availability, but the one which applies the most here is operational availability as ‘[…] a measure of the real average availability over a period of time and includes all experienced sources of downtime, such as administrative downtime, logistic downtime, etc.’ Operational availability is in that sense, not a technical KPI, but one firmly placed in the customer experience domain of your business strategy: Operational availability is the availability of your system the customer actually experiences from the outside. Availability is mainly driven by measuring time loss, where ‘time’ is a critical factor in the loss of business and therefore revenue. Reliability, on the other hand, is defined as ‘the ability of an item to perform as required, without failure, for a given time interval, under given conditions’. Reliability therefore primarily deals with the frequency of failures (e.g. MTBF, Mean Time Between Failures), time to repair or remediate failures (MTTR, Mean Time To Repair), or changes in system conditions that can render the system unavailable (e.g. unresponsive because of saturated system resources). In essence, Availability is, therefore, a function of Reliability of a system: A system can be available (within limits) whilst being unreliable and/or not particularly maintainable. Reasons for (reduced) reliability are manifold, ranging from a bad infrastructure architecture, unforeseen failures of underpinning components, bad resource requirements to bad software architecture. 

A Microservices Architecture will Dramatically Improve System Reliability

To be very clear upfront, microservices are not the silver bullet of software and system architecture – a monolithic architecture for services and components is still a very valid choice in many situations, frequently in the early or start-up phases of services. However, as soon as systems grow more complex (this appears to be an axiom of system and enterprise architectures) a monolithic architecture invariably reaches its limits, and the resulting system then begins to also be complicated, which reduces team productivity, increases testing times, and therefore also increases the time until the system is recovered.  The answer, in this case, can be to adopt a microservices architecture. In principle, microservices are (very) small system components which are scoped around single business functions that are loosely coupled and communicate with each other through clearly defined exposed APIs. In most cases, microservices also make use of messaging systems to connect with each other. 

Microservices do one thing, and one thing only. But they do it very, very well.

Microservices radically simplify the complexity of code and codebases (if done well), and therefore greatly enhance maintainability, and testability, dramatically reducing the time to deploy patches to fix failures in your system. Without going too much into detail, the simplification and decomposition potential of microservices is reflected in the evolution of cloud computing. Having started with virtual machines (a monolithic architecture artefact) cloud computing is now unthinkable without containers and even ‘serverless’ – both key ingredients for a microservices architecture using Docker or Kubernetes to manage dynamic demand loads. Therefore, infrastructure components of a microservices-based service such as network, storage, databases etc, are far less monolithic as well and therefore much easier to manage, and are far more capable to positively contribute to the overall operational availability of your IT system, service, and estate in general. This was quite a ‘mouthful’ of technical information, so let’s condense this into the most important reasons why you should seriously consider adopting a microservices architecture: 

Reason 1: Microservices help reduce component complexity, thus improving team productivity. Microservices radically decompose complex business requirements into small, bite-sized elements of functionality that loosely communicate with each other based on need. Small components dramatically improve scalability and therefore fault tolerance. Changes to the code base are far more frequently very isolated in their impact (i.e. only on the affected microservice) and therefore can be rolled out – and rolled back if necessary – on a much higher frequency. Microservices are essentially a must for agile and DevOps oriented ICT systems and teams. 

Reason 2: Microservices are almost always most effective when deployed in the cloud. Especially when looking at hyperscaling cloud services – AWS, Azure, Google – their service portfolios are growing with amazing speed. The sheer variety of similar services (AWS offers 9 different database services) speaks volumes of support for microservices. They are designed to be easily included in your microservices – and each and every individual service they offer is easily connected to service monitoring, auditing and configuration management components crucial for fault tolerance, fault detection and change management procedures. On your digital transformation journey, you will inevitably encounter cloud computing and therefore invariably also microservices to make the most of cloud computing if you decide to go down that route. 

Reason 3: Service management becomes more clear. On a rather philosophical level, microservices are radically implementing separation of concerns. But this has very specific and concrete consequences for you: It makes it actually easier to manage the technical aspects of well-defined underpinning services and platforms.  

But one question remains, do you have the capacity to do it well? And do you have the capabilities to do that in a way that satisfies security requirements? Are you able to do that in line with the highest standards of efficiency, effectiveness, and quality? And what about all the regulations in place such as data protection and privacy (Data Protection Act 2018), data retention and safety? For more information join us at /services/cloud/professional-services/ Call the Craftsmen team on 020 3745 7706 or email us at [email protected] to find out more about our services consultancy, verified ISO27001 and Cyber Essentials Plus accreditations.