3 ms·

I would like to argue that a microservice architecture is frequently a response to the scalability limits of traditional databases. Decomposing a monolith into

I would like to argue that a microservice architecture is frequently a response to the scalability limits of traditional databases. Decomposing a monolith into multiple services (with each service interacting with only its own database) is essentially a form of vertical partitioning. It's a way to delay sharding. Microservices are nice, but they seem like a heavyweight way to "force" module boundaries to exist. Potentially, if database technologies improve, there might not be a need to split up a monolith until much later on.

mtkd 10y ago
the danger in my view is that it is seen as a binary choice - which, if you go all in on microservices, just shifts from one problem to another - they need to be seen as just another tool for architecting and scaling there is nothing wrong with building a monolith so long as you gave some thought to how it might get partitioned later once you've built a few I think you start to see where those pressure points will be and microservices are a good pattern for scaling the functions that get all the traffic once it's working I hear people talking about using only microservices to underpin a big app but I just can't imagine that is an efficient or sustainable approach for an app with any complexity if the core function spans across all those services - at the very least I can see macro changes becoming disproportionately more challenging and risky over time
- dragonwriter 10y ago
  > I hear people talking about using only microservices to underpin a big app but I just can't imagine that is an efficient or sustainable approach for an app with any complexity Not having some coherent analytical approach probably isn't efficiently sustainable for complex systems, but if you have one, microservices for the whole system probably aren't a problem, since most system analysis approaches end up describing/modeling systems in a way that has a natural corresponds to a set of microservices wired together with a messaging bus.

mtkd 10y ago

the danger in my view is that it is seen as a binary choice - which, if you go all in on microservices, just shifts from one problem to another - they need to be seen as just another tool for architecting and scaling there is nothing wrong with building a monolith so long as you gave some thought to how it might get partitioned later once you've built a few I think you start to see where those pressure points will be and microservices are a good pattern for scaling the functions that get all the traffic once it's working I hear people talking about using only microservices to underpin a big app but I just can't imagine that is an efficient or sustainable approach for an app with any complexity if the core function spans across all those services - at the very least I can see macro changes becoming disproportionately more challenging and risky over time

dragonwriter 10y ago
> I hear people talking about using only microservices to underpin a big app but I just can't imagine that is an efficient or sustainable approach for an app with any complexity Not having some coherent analytical approach probably isn't efficiently sustainable for complex systems, but if you have one, microservices for the whole system probably aren't a problem, since most system analysis approaches end up describing/modeling systems in a way that has a natural corresponds to a set of microservices wired together with a messaging bus.