An old monolithic PHP application I worked on for over a decade wasn't set up with independent modules and the average deploy probably took a couple seconds, because it was an svn up which only updated changed files.

I frequently think about this when I watch my current workplace's node application go through a huge build process, spitting out a 70mb artifact which is then copied multiple times around the entire universe as a whole chonk before finally ending up where it needs to be several tens of minutes later.

Even watching how php applications get deployed these days, where it goes through this huge thing and takes about the same amount of time to replace all the docker containers.

I avoid Docker for precisely that reason! I have one system running on Docker across our whole org - Stirling-PDF providing some basic PDF services for internal use. Each time I update it I have to watch it download 700mb of Docker stuff, instead of just doing an in-place upgrade of a few files.

I get that there are advantages in shipping stuff like this. But having seen PHP stuff work for decades with in-place deploys and no build process I am just continually disappointed with how much worse the experience has become.

One approach I've seen rather successfully is to have a container that just contains the files to deploy, and another one for the runtime. You only need to update the runtime container ~ once a week or so (to get OS security updates), and the files container is literally just a COPY command to a volume.

I've only seen that in one place, ever. Most people just do the insane 40 minute docker build -- though I've also seen some that take over 4 hours...

That makes a lot of sense to me!

> which only updated changed files

You pay for this with the inability to maintain instance state (even caches) and a glacially slow runtime. It's a tradeoff.

Not sure what you mean about either of those two things? Never had any issues with instance state in our primary production environments, which were several instances of load balanced web servers. No idea what you're referring to as "slow"?

Yeah, if something even simpler works, that's of course even better.

I'd argue the difference between that PHP app and the Node app wasn't the lack of modularity, you could have a modulith with the same fast deploy.

(But of course modulith is too just extra complexity if you don't need it)

> I think this was the meme before moduliths[1][2] where people conflated the operational and code change aspects of microservices.

People conflate the operational and code change aspects of microservices just like people conflate that the sky is blue and water is wet. It's a statement of fact that doesn't go away with buzzwords.

> IOW you can do as many deploys without microservices if you organize your monolithic app as independent modules, while keeping out the main disadvantages of the microservice (infra/cicd/etc complexity, and turning your app's function calls into a unreliable distributed system communication problem).

This personal opinion is deep within "not even false" territory. You can also deploy as many times as you'd like with any monolith, regardless of what buzzwords you tack on that.

What you're completely missing from your remark is the loosely coupled nature of running things on a separate service, how trivial it is to do blue-green deployments, and how you can do gradual rollouts that you absolutely cannot do with a patch to a monolith, no matter what buzzwords you tack on it. That is the whole point of mentioning microservices: you can do all that without a single meeting.

I seem to have struck a nerve!

While there may be some things that can come for free with microservices (and not moduliths), your mentioned ones don't sound convincing. Blue-green deployments and gradual rollouts can be done with modulith and can't think of any reason that would be harder than with microservices (part of your running instances can run with a different version of module X). The coupling can be just as loose as with microservices.

Blue-green deployments is a buzzword no matter what color you tack on it.