Hacker News Reader

Comment by GrumpyNl | Hacker News Reader

There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.

View on HN

Can you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications

If a monolith has routes /a and /b, you can deploy the whole service to 2 servers with a proxy where all of the requests for /a goes to server 1 and all the requests for /b go to server 2. Server 1 has all the code to respond to /b but will never see that request.

Feature flagging comes to mind, just don't expose the pieces that don't work or are in-progress? or .exclude or something.

How?

The 'monolith' (which I find a silly term but I'll use it here) can expose different parts of itself as services. As long as those services can be versioned and are backwards compatible, you can deploy the monolith using any schedule or notification mechanism you like.

If the monolith is composed of modules with a DAG-like dependency structure (e.g. maven projects), then pieces of the monolith can be deployed alongside the dependencies they need.

I think the problem is there's no popular framework that makes this easy (or is there?)

Depends on the eco system, I've found this straightforward with maven / sbt + GRPC / Akka / Thrift, and then more difficult in environments that don't have baked in concepts of packages and module deployables, but from experience the mention of any of those technologies can start a flamewar of good and bad experiences therein :).

Reply on news.ycombinator.com