Use One Big Server (2022)

Microservices vs not is (almost) orthogonal to N servers vs one. You can make 10 microservices and rent a huge server and run all 10 services. It's more an organizational thing than a deployment thing. You can't do the opposite though, make a monolith and spread it out on 10 servers.

> You can't do the opposite though, make a monolith and spread it out on 10 servers.

You absolutely can, and it has been the most common practice for scaling them for decades.

> You can't do the opposite though, make a monolith and spread it out on 10 servers.

Yes you can. Its called having multiple applications servers. They all run the same application, just more of them. Maybe they connect to the same DB, maybe not, maybe you shard the DB.

That’s just _duplicating_ the nodes horizontally which wasnt what I meant.

That’s obviously possible snd common.

What I meant was actually butchering the monolith into separate pieces and deploying it, which is - by the definition of monolith - impossible.

That’s obviously not what I meant. I meant running different aspects of the monolith on different servers.

> I meant running different aspects of the monolith on different servers.

Of course you can. I've done it.

Identical binary on multiple servers with the load balancer/reverse proxy routing specific requests to specific instances.

The practical result is indeed "running different aspects of the monolith on different servers".

What would be the point of actually butchering the monolith?

There is no limit or cost to deploying 10000 lines over 1000 lines.

That's not a problem in a well designed ASP.NET project. Just create a new web API project, move a controller into it and copy/paste the necessary boilerplate into Program.cs, set up config etc for it and configure cicd to deploy it separately, there you go. Less than a days work.

You can also publish libraries as nuget packages (privately if necessary) to share code across repos if you want the new app in it's own repo.

I've worked on projects with multiple frontends, multiple backbends, lots of separately deployed Azure functions etc, it's no problem at all to make significant structural changes as long as the code isn't a big ball of mud.

I always start with a monolith, we can easily make these changes when necessary. No point complicating things until you actually have a reason to.

I meant in the sense of ”machine A only manages thing authentication” and ”machine B only manages orders”.

If that’s possible (regardless of what was deployed to the two machines) then the app just isn’t a true monolith.