Your developer says the system needs to be rebuilt as microservices. The plan sounds modern, and the quote is large. You need to decide if it is the right call. Or your single system slows down as you add branches, users and features. You wonder if splitting it would help.
This guide explains microservices best practices in plain words. You will learn what microservices are and how to tell if you need them. You will also see the rules that keep a split system healthy. And you will get questions to ask before you approve one.
Key takeaways
- Microservices split one large system into small services, each doing one job and talking over a network.
- Most businesses do not need them at the start. One well-built system, split into clear modules, is usually cheaper and simpler.
- In O'Reilly's 2020 survey of 1,502 people, 56% named complexity as the biggest challenge with microservices.
- If you do split, give each service one job and its own data. Plan for any part to fail.
- Move one part at a time while the old system keeps running. Avoid a big-bang rewrite.
What are microservices?
Microservices are a way to build software as many small services instead of one large system. Each service does one job, such as payments, bookings or stock. The services talk to each other over a network. The opposite is a monolith (one system where every feature lives and is released together).
Think of a booking platform. In a monolith, bookings, payments and customer records sit in one program. In microservices, each of those runs as its own service, released and scaled on its own.
That split brings real benefits. A team can change the payments service without touching bookings. A busy service can get more computing power on its own. But every link between services is a new place where things can go wrong.
If you want the bigger picture first, read our guide to what a distributed system is. Microservices are one way to build one.
Do you need microservices?
You need microservices only when one system has grown too complex for your teams to manage and release safely. Signs include many teams blocking each other and releases that need weeks of testing. Another sign is one busy feature slowing everything down. Without those problems, one well-built system is usually the better choice.
Software writer Martin Fowler made this point in his 2015 essay on the microservice premium. He wrote: "don't even consider microservices unless you have a system that's too complex to manage as a monolith".
In another essay, Monolith First, he noted a pattern. "Almost all the successful microservice stories have started with a monolith that got too big and was broken up". Systems built as microservices from scratch, he wrote, often "ended up in serious trouble".
Teams that do adopt them often find it pays off. IBM's 2021 survey asked more than 1,200 IT and developer staff. Of the users, 87% agreed the effort and expense is or will be worth it. That figure comes only from teams already using them.
Bottom line: start with one system built in clear modules (separate parts with firm edges inside one program). Split a part out only when you have a real reason, such as slow releases.
What are the microservices best practices?
The core microservices best practices are simple to say and hard to do well. Give each service one clear job, and let each one own its data. Plan for any service to fail. Then watch every service, release each on its own and check access at every service.
- One job per service: each service matches one part of the business, such as invoicing. If two services always change together, they should probably be one.
- Each service owns its data: no two services share one database. Others ask for the data through an API (a set of rules for how two systems talk).
- Plan for failure: set time limits on every call between services. If the stock service is down, the shop should still load and show a clear message.
- Watch every service: collect logs and alerts in one place. Your team should see which service failed, and why, within minutes.
- Release each service on its own: one team can update one service without a full system release. Otherwise you carry the cost of microservices without the benefit.
- Check access everywhere: the OWASP security guide says each service must enforce access, including internal calls. A login check at the front door is not enough.
Why are microservices harder than they look?
Splitting a system is harder than it looks because every split adds moving parts. You trade one large program for many small ones, plus the network between them. Each service needs its own releases, monitoring and security. Problems that were simple in one system, like a report across all data, now span several services.
The numbers show it. O'Reilly's 2020 survey had 1,502 respondents. Complexity in one form or another was the biggest challenge, named by 56%. Culture came first as a single challenge, cited by almost 40%. Next, 37% struggled to break requirements into small functions, and about 30% found it hard to connect legacy systems.
Most teams still got value. In the same survey, 92% had at least some success. The lesson is to go in with clear eyes. Budget for the extra running cost, monitoring and skills. Those costs stay for as long as the system runs.
How do you move to microservices safely?
You move to microservices safely by splitting one part at a time while the old system keeps running. Avoid stopping everything for a full rewrite. Pick the part with the clearest reason to split, build it as a service and move users over. Then repeat with the next part.
- Map the parts: list what the current system does and which parts change or load the most.
- Pick one to split: start with a part that has clear edges. It should also have a real reason to move, such as heavy traffic.
- Run old and new side by side: send some work to the new service and compare the results.
- Move users over: switch fully once the new service holds up, and keep a way back.
- Repeat, part by part: stop when the remaining system is simple enough to keep as it is.
Martin Fowler calls this the strangler fig approach. The new system grows around the old one through "a gradual process of modernization". It keeps the business running while the change happens. If your system started as a quick first version, see what to fix before real users arrive.
What to ask your developer before you split
Before you approve a microservices plan, ask your developer what problem it solves and how they will run it. A good answer names a real pain, such as slow releases or one busy feature. It also explains the running cost. A vague answer about being "modern" or "future-proof" is a warning sign.
- What problem does this split solve? Ask for a specific pain you feel today.
- Could clear modules in one system solve it? If yes, that is usually cheaper.
- Which part moves first, and why that one? Expect a step-by-step plan that moves one part first.
- How will we know when a service fails? Ask to see the alerts and the plan for each failure.
- What will it cost to run each month? More services mean more servers, monitoring and skills.
- Who looks after it after launch? Every service needs an owner for as long as it runs.
These answers also shape the quote. Our guide on what sets the price of custom software explains how scope drives cost. If the answers show a real need, plan your custom web app development one part at a time.
Frequently asked questions
Are microservices more expensive than one system?
Usually, yes. Each service needs its own setup, releases, monitoring and security, so running costs go up. You also need staff who can handle that work. The extra cost can pay off for large systems with many teams. For most growing businesses, one well-built system costs less to build and to run.
What is a modular monolith?
A modular monolith is one system split inside into clear parts, such as bookings, payments and reports. Each part has firm edges, but they are all released together as one program. It gives you much of the order of microservices without the network between them. It also makes a later split easier.
How many microservices should we have?
There is no right number. Start with as few as solve your real problems, often none. Add a service only when a part needs to change, grow or fail on its own. If two services always change together, merge them. Too many small services can be harder to run than one large one.
Do small businesses need microservices?
Most do not. A small business with one team and a few thousand users rarely has the problems microservices solve. One well-built system, with clear modules and good backups, is usually enough. Revisit the choice when you have several teams, heavy traffic or parts that must stay up when others fail.
Your next step
Every list of microservices best practices should start with one question: do you need them at all? For most businesses, one system built in clear modules is the better start. If you do split, give each service one job and its own data. Plan for failure, and move one part at a time.
If you are weighing a rebuild, book a free consultation. We can talk through whether to split your system, and where to start.
