Maybe I'm just not up on the startup or smaller company scene, but isn't it still pretty important to acquire those customers before you worry about whether or not they'll take your systems down? I'd expect that to give you plenty of time to build the monolith, figure out if it's too brittle, too unscaleable, etc, and maybe ground-up rewrite at low cost before you solidify too much by breaking things up

Even so, let's say you need to scale very very quickly right away, it's so much easier to profile and optimize a single process. I've been successful in optimizing e.g. a Go library from 100 KB/s to 700MB/s, with about two weeks of work (`pprof` and `go bench` are amazing tools), which then handled 20k tps in an application, and could have scaled out but didn't actually need to. I've also gotten millions of rows in a postgres database to be full-text searchable in under 10ms, also with maybe only a week of work. I can't readily think of a time (and I've had plenty of opportunity these days) where I've successfully diagnosed and optimized underperforming distributed systems, despite having spent months discussing and attempting to measure performance issues and trying various "yeah maybe that could work" fixes.

Granted, It's almost certainly always been the case of microservices for the sake of microservices, but I always come back to the lack of tooling (no compiler to tell you that you broke some contract), the siren call of polyglot microservices that makes it a lot harder to build common tooling, and the temptation to prematurely send microservices to different teams (further adding to the lack of agility), as really solid reasons to stay smaller as long as possible.

Yeah I'd agree that for most startups a monolith makes more sense. It's usually easier to add microservices later if they're needed than to go the other way.

Your point about the Go binary reminds me of a related problem. We so often come up with solutions (like microservices) to performance problems that just add more complexity, when often the performance problems can be solved by reducing complexity. Then as you say it becomes so complex that it's more difficult to fix later problems.

Dangerous statement... Is it because the 'problem solvers' in question don't in fact know how to solve the complexity in code?

Possibly somewhat, but I think more often its that reducing complexity isn’t valued in many organisations. It’s usually faster to apply a patch over solution than to go and reduce complexity in the existing system. Also the larger the system, the less willingness there is to risk changing something that already exists - technically and politically.

As an example, imagine that you have a very slow service. You could dig in and find the bottlenecks, and rewrite the service to remove those bottlenecks. Or you could just add a caching layer on top. The cache layer likely solves the problem quickly, but it adds more complexity to the system overall.

You don't need microservices to do this.

Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances.

We did this at an old job. We had a data-intensive app which had a web UI for users, an admin UI, and an API for data export. They all had lots of common code for persistence, querying, aggregation, etc. Because of the common code, the simplest way to implement the three interfaces was in a single codebase. But because API requests could sometimes crash the app (we didn't do a great job here!), we segregated the API into its own pool of instances. We didn't segregate the admin UI, but could have done that if necessary.

As well as simplicity, another advantage of this approach is that the decision about how to split up traffic is very dynamic: you can change it just by adding or removing instances and changing load balancer config, without having to make any code changes. if you split the traffic up into separate microservices, you have to make that decision upfront, and changing it is a lot of work.

> Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances.

Don't you now have "microservices" bundled together in a single binary - and deployed together? If each of your component exposes different APIs and each instance only handles certain endpoints, then you kind of have microservices - not literally, but it seems the idea is the same.

Simplicity being a benefit, I don't really see how the dynamic traffic routing is a huge benefit vs microservices - you can dynamically scale up/down microservices too.

I am not saying this is a bad approach, by the way, but just that it isn't much different from microservices.

I think you can use such an architecture without almost zero or minimal code change. You don't have to split the shared endpoints using some remote API calls since they are all available inside your monolith.

Agreed. Which is why I mentioned simplicity being a benefit - if you already have a monolith that you are seeing issues with. But the parent said "You don't need microservices to do this."; this solution isn't much different from microservices.

The GP solution has very little in common with microservices - it’s just a load balanced architecture with specific pools for different workloads. Just like we could do in the 90s.

Microservices are only microservices if they have both narrow focus and radical independence. If they have narrow focus without the independence then you probably have a monolith with 25 executables to deploy.

Are all "web servers" connecting to the same database (cluster or instance), without application specific database partitioning ?

In our case, they did. If you have a clustered database, they could perhaps use different nodes in the cluster. If you have read replicas, they could have separate pools of read replicas.