Is microservices better than monolithic? Not for a small team

For a company with 1 to 10 people, microservices are usually not better. Martin Fowler put it plainly: "many, indeed most, situations would do better with a monolith."^[5] Neither style wins in every case, but a monolith is the best way to start a young business, because a lean team can build one at a reasonable cost.^[1]

Fowler is a software author and the Chief Scientist at Thoughtworks, a software delivery company.^[12] He has written seven books on software development, including Refactoring and Patterns of Enterprise Application Architecture.^[11] His job is to learn what his colleagues have found works when delivering software for clients, and to pass it on to the wider software industry.^[11] His team has written about microservices since they first appeared.^[6] That is why his view carries weight: it rests on what many delivery teams have seen, not on one team's taste.

Here is the difference. A monolith is one application that your developers build and release as a single piece. Microservices split the application into many small programs. Each runs on its own and talks to the others over a network.^[1]

What microservices cost a small business

The extra cost has a name, the "microservice premium." It is the cost of managing a suite of programs instead of one. It slows a team down, and it pays off only when the software is complex.^[6] It shows up in four places.

• Developer pay. Microservices call for developers with proven experience, and usually several of them.^[2] Developers like that cost more. If you want software that cheaper developers can maintain, one codebase is the easier path.
• More that can break. With many programs talking over a network, there are many more links that can fail. Developers have to write extra code to cope when one does.^[8] Finding the cause of a bug takes longer and costs more labor.^[1]
• The hosting bill. Replacing one application with many services usually needs more server capacity at first. The extra spending is usually worth it for large applications that will run for years.^[9] Whether yours is one of those is the first question to answer.
• Running it day to day. Many small programs need automated releases and monitoring that warns people when something fails. Building that takes heavy investment.^[3]

The complexity does not go away. It moves somewhere else, and you pay to manage it either way.^[8]

A rescue that cost more

One case study describes a team that used microservices on a system that was not complex enough to justify the premium. The project got into trouble, and the company put many more developers on it. The design let the team absorb them, and the work sped up. It still used more developer hours than a monolith would have.^[4]

The design helped the company spend more on people. It did not lower the bill.

If your software keeps breaking

Unstable software is often blamed on the monolith. A monolith can have clean lines between its parts, but it takes discipline to keep them, and many end up tangled. That frustration has pushed several teams to microservices.^[4]

A split does not untangle code, though. Most systems have too many links between their parts to be separated sensibly, and plenty of attempts to split one have ended in a mess.^[6] When a weak team builds a system, it is hard to tell whether microservices reduce the mess or make it worse.^[10]

So the first step is the same either way: find the tangled parts and give the code clear lines between them. A monolith designed carefully, with its parts kept separate, makes a later move to microservices relatively simple.^[6]

Signs you do need microservices

Three signs point that way:

• A small change in one part often makes the whole release fail. Difficulty releasing large monoliths is what pushed several teams to move.^[4]
• One feature needs far more server capacity than the rest, and you pay to scale the whole application. Microservices let you scale only the part under load.^[3]
• The team has grown so large that developers no longer keep to the lines between parts. Discipline gets harder as a team grows, just as those lines matter more.^[4]

Even with those signs, a team needs certain baseline skills before it tries the style.^[5] Ask your developers to work through a readiness checklist for the team and the servers before any split.^[7]

No published source can give you a price or a timeline for either path, because both depend on the state of your code. If you can't tell which description fits your software, that is a good question to bring to a direct conversation with Moosara.