4 ms·

Remember there's a trade-off to everything and that systems naturally move towards being distributed as they scale. Not just technical systems but all systems i

by chuhnk 9y ago

Remember there's a trade-off to everything and that systems naturally move towards being distributed as they scale. Not just technical systems but all systems in nature. There's always a singular starting point and the move to distributed systems is one where trade-offs are being made to solve specific problems. Taking this approach pragmatically leads to the adoption of microservices and functions at the right time. This library solves a specific problem at the query layer. It's definitely time we had something like this across microservices and functions. There have been other attempts but in unstructured ways. It's likely in the long term systems architectures are multilayered. Monoliths, microservices and functions along with graphql or other query models all within the same environment.

friendly_chap 9y ago
Very nicely put. I agree it's an evolution, but I see a lot of companies waste a lot of time on the monolith -> services transition phase. Usually what happens is that they try a complete rewrite which turns out to be rather expensive (especially in opportunity cost). They should ideally just move the pain points (ie. performance problems) to services and optimize that, but the enthusiasm towards the shiny new way of doing things that will fix their problems is so high that they opt for the riskier move of rewriting all the things. That scenario is simply so dangerous and expensive that companies will be better off starting with a proper distributed framework - which doesn't really exists yet, but we are slowly getting there. Anyway, this is just my 2c but I have seen this pattern of full blown rewrite at a lot of places.
- chuhnk 9y ago
  The rewrite approach is definitely painful but that can at times also stem from failures in previous attempts at moving from monolith to services. The problem usually arises because there's no real definitive structure or architectural choices around the breakdown. It's a very ad-hoc thing that results in building an even more brittle system. When you start to breakdown the monolith you may end up with 10 services all using different databases, message queues and message formats. Going the whole rewrite approach usually involves defining an architecture and single uniform approach to development which eventually leads to higher productivity since it eliminates choice and lets you focus on the important tasks. I do however agree that not everyone who does it needs to.

by chuhnk 9y ago

friendly_chap 9y ago

Very nicely put. I agree it's an evolution, but I see a lot of companies waste a lot of time on the monolith -> services transition phase. Usually what happens is that they try a complete rewrite which turns out to be rather expensive (especially in opportunity cost). They should ideally just move the pain points (ie. performance problems) to services and optimize that, but the enthusiasm towards the shiny new way of doing things that will fix their problems is so high that they opt for the riskier move of rewriting all the things. That scenario is simply so dangerous and expensive that companies will be better off starting with a proper distributed framework - which doesn't really exists yet, but we are slowly getting there. Anyway, this is just my 2c but I have seen this pattern of full blown rewrite at a lot of places.

chuhnk 9y ago
The rewrite approach is definitely painful but that can at times also stem from failures in previous attempts at moving from monolith to services. The problem usually arises because there's no real definitive structure or architectural choices around the breakdown. It's a very ad-hoc thing that results in building an even more brittle system. When you start to breakdown the monolith you may end up with 10 services all using different databases, message queues and message formats. Going the whole rewrite approach usually involves defining an architecture and single uniform approach to development which eventually leads to higher productivity since it eliminates choice and lets you focus on the important tasks. I do however agree that not everyone who does it needs to.