If you have spoken to a developer or agency about a new website, booking system or customer portal recently, there is a fair chance the word "microservices" came up. It is often presented as the modern, grown-up way to build software. Sometimes it is. Quite often, for a small business, it is an expensive answer to a question nobody asked.
As a solution architect, I spend a lot of my time helping organisations pick the simplest design that will do the job well. This article explains what microservices are in plain terms, how they compare with the alternative, and how to tell whether they are right for you.
What are microservices?
Most software does several jobs at once. An online shop, for example, shows product pages, takes orders, handles payments and manages customer accounts.
There are two broad ways to build that:
- A monolith is one application that does all of those jobs. It is built, tested and deployed as a single unit, and usually talks to a single database.
- Microservices split those jobs into separate, small applications ("services"). Orders is one service, payments another, accounts another. Each can be built, deployed and scaled on its own, often with its own data store, and they talk to each other over the network.
A simple way to picture it: a monolith is one well-organised shop with several departments under one roof. Microservices are a row of independent shops, each with its own staff, keys and stockroom, that phone each other to get things done.
Where microservices genuinely help
Microservices were popularised by large technology organisations, and the benefits are real in the right setting:
- Many teams working in parallel. When dozens of developers work on one product, separate services let teams release their part without waiting for everyone else.
- Very uneven load. If one part of the system (say, search or video processing) needs far more computing power than the rest, it can be scaled on its own.
- Different technical needs. One part might suit a particular language or database that would be awkward for the rest.
- Isolating failure. Done well, a problem in one service need not take the whole system down.
Notice the pattern: most of these benefits are about organisational scale. They solve the problems of large teams and large, busy systems.
Where they are overkill
For most small businesses, honestly, microservices are the wrong starting point. A brochure site, an online shop, a booking system or a modest customer portal rarely has the team size or traffic that makes splitting things up pay off.
What you take on instead is real cost and complexity:
- More moving parts. Every service needs its own hosting, deployment pipeline, configuration, security and monitoring. Five services means five of everything.
- The network becomes part of your application. Calls that used to happen inside one program now travel between services and can be slow, fail or arrive out of order. Your developers have to design for that.
- Data gets harder. When orders and payments live in separate databases, keeping them consistent takes deliberate effort. Simple reports can turn into integration projects.
- Troubleshooting takes longer. Tracing one customer's problem across several services needs proper logging and tracing tools, and people who know how to use them.
- Higher running and support costs. More infrastructure, more specialist skills, and more for your supplier to maintain. If your developer moves on, the next one has more to learn.
None of this is a reason to avoid microservices forever. It is a reason not to pay for them before you need them.
What usually works better: modular monolith or simple serverless pieces
There is a sensible middle ground, and it is where I steer most small-business clients.
A modular monolith is one application, deployed as one unit, but organised internally into clear, well-separated modules (orders, payments, accounts) with tidy boundaries between them. You keep the simplicity of one deployment and one database, while the code stays organised enough that a module could be split out later if there is ever a good reason.
Simple serverless pieces are small functions or edge scripts that run on a cloud provider's platform only when needed, without you managing servers. They are well suited to specific jobs such as handling a contact form, sending an email or processing a webhook. Used sparingly, they add capability without a sprawling architecture.
The aim is the fewest moving parts that meet your needs today, with room to grow tomorrow.
A real example: how Quorum Digital is built
I apply the same thinking to my own business. The Quorum Digital setup is deliberately simple:
- The marketing website runs as a Cloudflare Worker, so pages are served quickly from Cloudflare's network with very little to maintain.
- A small Azure Functions API handles the few things that need server-side logic, such as enquiries.
- Azure Cosmos DB stores the data that API needs.
That is three pieces, each with a clear job. There is no fleet of services, no message bus and no container cluster, because nothing about the business needs them. It is cheap to run, easy to reason about, and if one area grows, it can be separated out at that point, based on evidence rather than guesswork.
Checklist: do you need microservices?
Microservices may be worth considering if you can honestly answer "yes" to several of these:
If you ticked one or two, or none, a well-structured monolith or a handful of serverless functions is very likely the better and cheaper choice. That is not a compromise; it is good architecture.
Thinking about your own systems?
If you are planning a new build, inheriting a system that feels more complicated than it should be, or weighing up a supplier's proposal, an independent second opinion can save a great deal of time and money.
Quorum Digital offers practical architecture reviews for small businesses: a plain-English look at what you have or what is proposed, what it will cost to run, and where it could be simpler. No jargon and no pressure. If that sounds useful, get in touch and we can have a short, informal chat.