Hacker News new | ask | show | jobs
by gluczywo 3266 days ago
even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are

This line of thought reaches two decades ago and was expressed in a wonderful essay "Big Ball of Mud" http://www.laputan.org/mud/

EDIT: updated with the quote

2 comments

A lot of people don't have the discipline to write decent libraries so they need the overhead of microservices to force them to structure their code reasonably. It seems to me you can have exactly the same boundaries between components that you get through microservices by just having a good compenent separation.
I feel 100% like you. Most developers won't think about clear interfaces between components unless they are forced to do so by an RPC layer. I think at some point we are going to realise this and step back on our footprints , ending up with a monolithic architecture with clearly defined boundaries between components enforced by expressive type systems.
> Most developers won't think about clear interfaces between components unless they are forced to do so by an RPC layer.

The developers I know who can't think about clear interfaces are also the ones that won't know how to write clear RPC, and won't be able to create clean microservices.

But they will have "microservices architecture" which looks better on your resume than monolith.
This is exactly true. And so is the reverse: competently written code can be segmented out into a SOA by replacing your internal procedure calls with a network call.
Caveat: If it's acceptable to have significant latency or the interaction is asynchronous.
Sure, but if it's not acceptable to have significant latency then they're probably the same logical service, yeah?
if you have component separation, you have microservices
I think it's more nuanced than that and one can consistently hold both viewpoints at the same time. You just need to have the experience that a soa-first approach is even worse than the ball of mud.