4 ms·
There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.
by GrumpyNl 5y ago
There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.
- pc86 5y agoHow?
- lemmsjid 5y agoThe '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.
- Graffur 5y agoI think the problem is there's no popular framework that makes this easy (or is there?)
- lemmsjid 5y agoDepends 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 :).
- Softcadbury 5y agoCan you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications
- atwebb 5y agoFeature flagging comes to mind, just don't expose the pieces that don't work or are in-progress? or .exclude or something.
- henryfjordan 5y agoIf 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.