3 ms·
That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a modu
by plmpsu 1mo ago
That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.
- taberiand 1mo agoThat's my belief as well: modular architecture and separation of concerns is orthogonal to monolith <-> microservice infrastructure axis. And Service Oriented Architecture is the nice middle ground of that infrastructure axis
- derriz 1mo agoI don’t agree. The technical device we use for creating clear boundaries, useful abstractions and managing dependencies in monolithic code is the function/method/procedure call. The history of distributed software is littered with the corpses of attempts to make the RPC look like a function/method call (I worked for a CORBA vendor decades ago). But these two techniques are so different on a fundamental level they are not substitutable except in the most trivial cases. The compute and elapsed time RPC overhead which makes perfectly good local abstractions completely impractical across a network. And then there are the differences in terms of failure modes, concurrency and synchronicity. So even a beautifully designed and layered piece of “monolithic” software with a code base costing of coherent and clean abstractions will not be easy to port to a microservices/distributed architecture.
- onion2k 1mo agoIf you can manage that then there's no real benefit to microservices though. The reason for splitting is to solve the problem of failing to separate concerns, so a team that can't do that well is better off building microservices from the start because the alternative for them is building a monolith that will be hard to split.