The difference between microservices and web services is that they are different kinds of thing. A web service is an interface: a way for one program to exchange data with another over a network. Microservices are an architecture: a way of building one application as a set of small, separately deployed services. The first describes how software communicates and the second how it is divided up. Microservices nearly always talk to each other through web services, but a system that has web services is not necessarily built from microservices, and most are not.
What a web service is
A web service lets one program ask another for something over a network, using the same protocols as the web. Your accounts package offering a way to create an invoice from another system is a web service. So is a courier’s tracking lookup, or a payment provider’s interface for taking a card payment.
There are two broad styles.
- SOAP services exchange XML messages that follow a formal, published contract. They were the standard in the 2000s and are still common in older business systems, banks and government gateways.
- REST services exchange lighter messages, usually in a format called JSON. Most interfaces built in the last decade work this way.
In everyday use the word API, short for application programming interface, has largely replaced “web service”. When a supplier says a product “has an API”, they nearly always mean it offers web services.
For a business, web services are how systems are joined together. If the same order is typed into two systems, the fix is usually for one to call the other’s web service. Our system integration package does that at a fixed price.
What microservices are
Microservices are a way of structuring a single application. Instead of one program that handles ordering, stock, billing and customer accounts, each of those becomes a small service of its own. Each service is built, released and run separately, often by a different team, and ideally keeps its own database. The services cooperate by calling each other’s web services or by exchanging messages, as described in our article on event-driven architecture.
The alternative is usually called a monolith: one application, released as a unit, normally with one database. The word sounds like a criticism and should not be read as one. A monolith with clear internal boundaries between its parts, sometimes called a modular monolith, is a sound design for most business systems.
Microservices and web services side by side
| Web service | Microservices | |
|---|---|---|
| What it is | An interface between programs | An architecture for one application |
| The question it answers | How do two systems talk? | How is this system divided and deployed? |
| Needs the other? | No. Any application, large or small, can offer one | Yes. The services communicate through web services or messages |
| Typical example | An accounts package that lets other systems create invoices | A large online retailer running ordering, stock and payments as separate services |
| Who needs it | Anyone connecting two systems | Organisations with several development teams working on one product |
When microservices are worth it
Microservices solve a real problem. When dozens of developers work on one application, they get in each other’s way: every release has to be coordinated, and a fault in one corner can hold up everyone. Splitting the application lets each team release on its own schedule. It also allows one busy part to be given more servers without scaling the rest, and keeps a failure in one service from taking down the others.
Those benefits are paid for.
- Every call between services crosses a network, so it can be slow or fail, and the code has to cope with both.
- Data is spread across several databases. A report that was one query becomes a small project, and keeping two services consistent when an operation spans both takes careful design.
- The system needs automated releases, central logging and tracing across services before it is safe to run. That is more hosting and more specialist skill.
- Finding a fault means following a request through several services.
Our view is that microservices mainly solve an organisational problem, and a business with one small development team or a single supplier seldom has that problem. For a company of 10 to 500 staff, a well-structured single application is usually cheaper to build, host and maintain, and easier for a new supplier to take over.
There is a middle route. Keep the application whole, and split off one component where there is a specific reason: a document generator that needs a lot of processing power, or a public interface that must stay up while the back office is being updated.
What this means if you have inherited a system
Older SOAP services. Many older .NET systems offer or use SOAP services built with a Microsoft technology called WCF. They continue to work on .NET Framework 4.8, which is still supported. They matter when you modernise, because the server side of WCF was not carried into modern .NET. The usual routes are CoreWCF, a community project that Microsoft supports, or rewriting the services as REST interfaces. Our .NET Framework page covers the wider decision, and our article on moving a .NET Framework application to .NET 10 covers the work.
Other systems that call yours. Before changing or retiring any web service, find out who uses it. Customers, suppliers and other internal systems may depend on its exact format, and they will not all be documented.
Microservices built by a small team. An application is sometimes split into many services without the organisation that would justify it. The signs are that one change means releasing several services together, nobody can run the whole system on a single machine, and the hosting bill is out of proportion to the number of users. Merging services back together is a legitimate piece of modernisation.
Questions to ask when microservices are proposed
If a supplier proposes microservices for a new build or a rewrite, ask:
- How many developers will work on this, and in how many teams?
- Which specific parts need to be released or scaled separately, and why?
- How will an operation that spans two services be kept consistent if one of them fails?
- What will hosting and monitoring cost compared with a single application?
- Could it start as one application with clear internal modules, and be split later if the need appears?
A supplier who has thought it through will have a plain answer to each, and will often agree that the last option is the right starting point. Our list of questions to ask a software supplier covers the wider conversation.