Just After Midnight’s guide to microservices

by Ned Hallett
As Digital Marketing Manager and JAM’s primary pair of lungs, I provide the JAM-y take on the ever-evolving worlds of DevOps, SaaS, MACH - and acronyms yet to be coined.
Published on January 2022

Microservices have become a staple of the cloud-native diet.

They offer more flexibility, faster time-to-market, and dispense with a host of issues and limitations foisted upon teams by the now-spectral figure of the monolith.

But it’s not all sunshine, roses and microservices.

In this piece, we cover the core tenants of microservices, the nitty-gritty of the architecture, and which microservices myths we could all do without.

The basics of microservices (and monoliths) in plain, white-bread English

An opening analogy or two to explain microservices (skip if you know this)

‘Microservice’ and ‘monolithic’ are both styles of programme architecture. 

In a monolithic application, all processes are tightly coupled and often connected to a single relational database. 

if an application’s job is getting people from A to B, then the monolithic version would be a bus.

Microservice applications are made up of smaller, autonomous processes running independently of each other, often communicating via APIs. 

So the microservices version might be…a convoy of bicycles.

This gets a little more complicated when we consider the services in a microservices app won’t all be doing the same thing. So it might be even more prudent to imagine the differences between a tree and a garden.

Each is a whole made up of interdependent parts doing different jobs. Leaves collect sun, bark protects; flowers attract pollinators, grass tills the soil. The difference is, the parts of the tree are inseparable; the parts of the garden are not.

What this actually means 

What’s useful about these analogies is that  they help point to a few microservices’ key strengths:

  • Smaller, discrete services can be worked on and changed without affecting the others 
  • They can also be scaled independently
  • And they can even be entirely replaced without causing problems for the rest of the app

For example

Imagine an e-commerce page running a cart, search bar and payment processing service. 

With microservices:

  • The cart function can be scaled independently of the search service
  •  The search function can get a nice new design without changing the lovely-looking cart;  
  • And while all this is going on, the payment processing service has been replaced!

How widespread are microservices?

As we said at the beginning, microservices have become a staple of cloud-native.

The MACH alliance – champions of the future – has given microservices first place in their own acronym (Microservices, A C H)

And according to Statistica, 37% of organizations globally have adopted a microservices or partial microservices architecture.

So – with the basics covered, it’s time to get into the nitty-gritty.

Microservices architecture 

a diagram

Source: microsoft.com

The basics of a microservice architecture of a generic microservices application are simple enough to grasp. 

When the user connects, an API calls the relevant services into action.

The services – each with their own codebase and data – are orchestrated by another service such as Kubernetes (each microservice usually being deployed as a container).

This is not an exhaustive analysis, but it’s a good-enough snapshot of the basic idea.

Pros and cons of microservices architecture


Fault isolation 

For obvious reasons, it’s easier to isolate faults within dozens of discrete services. And depending on the fault, the application can often carry on running as intended – especially if using a circuit breaker pattern (more on this later).

Faster time-to-market (mostly)

When it comes to adding new features or making changes, the modular nature of microservices absolutely means faster time to market. However, when it comes to a greenfield, a microservices architecture will take longer to architect. 

Diverse, specialised teams and technological freedom 

Splitting up teams by service allows developers to take complete ownership of their service, experimenting and refining with the technology as they see fit (although there are limits which we’ll touch on below).


In a sense, this point is a function of the two above: smaller, discrete services with specialised teams can react faster to change, release new features quicker, and handle rollbacks, updates and bugs much more easily.


Microservices are smaller (micro) and usually packaged inside containers, so that’s one reason they’re more scalable. 

Another is they can be scaled independently of each other – as we saw in the example.


Complexity and governance  

This is a two-pronged point but each shares the same…fork-handle.

  1. Operationally, microservices are harder to govern because they’re distributed.
  2. Organisationally, microservices teams are harder to manage because they’re distributed (more on this below).

Cost (initially) 

A microservices-based app will cost more than a monolith. There’s simply a lot more to it. However, once it’s built, it’s generally cheaper.

Data integrity 

With each service storing its own data, integrity and consistency become an issue.

Patterns of microservice architecture   

The next stage in understanding microservices architecture is understanding what microservices patterns are.

We’re not going to list every pattern, that’s for a different post, but we will explain the theory and provide two examples.

What is a microservices pattern?

In development, a pattern is more or a less an architectural template. It’s a standardised way of doing things that solves a particular problem.

These patterns are generally sortable into a few categories, each aimed at solving a different problem.

There are far too many to list here, but we’ll give you a flavour by picking two examples.

Example of microservices pattern one: circuit breaker, a cross-cutting concern pattern 

What category of microservices pattern does a circuit breaker belong to?

A cross-cutting concern pattern is an architectural style geared toward preventing problems occurring between services, which, with microservices, can become a problem – especially when the app is complex. 

The problem this design pattern solves 

a diagram

Source: medium.com

In a distributed, microservices network, services are always calling one another. 

However, there’s a possibility that one service might be experiencing too high a latency to reply – or may be temporarily unavailable. 

The problem is, the caller service will keep calling, eventually exhausting resources, and becoming unable to handle other requests.

As you can imagine – this can lead to a chain reaction.

The solution

A remote service is used to monitor calls between services, if a call fails for a certain duration, the circuit breaker ‘trips,’ intervening by prompting an automatic failure on the part of the called service, thus preventing the calling service from wasting time and resource waiting and calling.

Example of microservices pattern two: decomposition by business function 

What category of microservices design pattern does decomposition by business function belong to?

Decomposition by business function is…wait for it…a decomposition pattern. 

Decomposition patterns are geared toward setting out architectures along the lines of the particular decomposition – in this case, business function.

The problem this design pattern solves

When designing a microservices architecture, or refactoring a monolith, one of the biggest challenges is deciding how you want to split the app into different services.

The solution 

A decomposition by business function creates services corresponding to a specific business capacity.  

For example, a Fintech app might be split into services that deal with customers, like web pages and chatbots, and services that deal with transactions.

A closing note on microservices patterns 

An app can be designed using multiple patterns. So you could have a fintech app, split by business function, wherein the services are monitored by a circuit breaker.

There’s a lot more to say on this topic.

But we just wanted to explain the concept of microservices patterns with a few examples.

So, now that we’ve covered the basics and the nitty-gritty – it’s time to move on to the bigger picture.

The big picture: three ways the adoption of microservices have changed the industry.

1 – Service management overheads, headaches  and the support partner

Support partners are a new-ish breed of MSP who arrived on the scene circa ‘when everything started to get too complex.’

As applications grew more and more distributed, combining the work of multiple providers, APIs and other next-gen doodahs, traditional support stopped being viable.

And this is especially the case with microservices, where support means supporting every single service.

Support partners – like yours truly – made a career out of stepping up to meet that support need (which itself feeds into the broader trend of outsourcing).

Essentially, microservices have made tech more like microservices – or is it the other way around?

Modular, distributed nodes combining and recombining according to some unknowable machine logic – it warms your heart.

2 – Standardisation and the microservices myths

 While it’s true that microservice architecture is more scalable and flexible than monolithic architecture, some people have taken this concept a bit too far. 

Around the internet, claims abound that microservices mean an unfettered release of dev creativity, with everyone using whatever programming language, database and X, Y Z that takes their fancy.

The reality is that standardisation is key to an efficient microservices app. 

Any programming language could be used, but in practice, this creates a bloat of additional work. Rather, things like tooling and language should be standardised where the value of idiosyncrasy is low.

3 – Microservices culture

A lot like DevOps, microservices can produce a powerful shift in organisations that adopt them.

But much as you’ll find quite vague endorsements of ‘giving autonomy’, ‘enabling collaboration’ and ‘unleashing creativity’ – many of the more advisable microservice culture recommendations look to constrain an excess of these (wonderful) things, as they arise naturally from a microservices app.

For one, the separation of teams into autonomous units, each responsible for their own service or set of services, throws up an immediate need to bring them together again.  

Regular sync-up meetings, documentation and sharing are all advised to prevent people from losing the thread. 

Similarly, the increased division of teams necessitates informed, business-conscious oversight, as the priorities of each team may clash.

The takeaways: 

  • Monoliths are like trees and microservices are like gardens, both contain interdependent processes, but one is more modular and customisable.
  • Microservices generally allow faster time to market, combining best-of-breed services and independent scaling. 
  • Microservices present some problems in support and complexity
  • Microservices architectures can be designed around different patterns, each aimed at solving a specific problem 

How we can help

As pioneering support partner and next-gen MSP, we can help you with pretty much anything microservice-or-monolith related. So for 24/7 application support, refactoring a monolith, cloud management or solution architecture, just get in touch.




With partners across the USA, Europe and APAC, we provide a truly global service. So wherever you or your clients are based, contact us today to find out what we can do.