Comment by friendly_chap | Hacker News Reader

Comment by friendly_chap | Hacker News Reader

Parent Full thread

It seems like slowly but surely the industry is realizing the incredible productivity penalty of microservices/fas etc, and just generally any model compared to your good old ORM in a monolithic codebase approach.

I still feel like we are way ahead with the concepts in (shameless plug alert) https://github.com/1backend/1backend when it comes to the big picture of building microservices that actually build on each other, although it's statistically very likely this is just a personal opinion :)).

Anyway, I'm generally happy that this space is advancing, as someone who spent most of his recent career in this space I almost gave up hope: simply there was not even a common vocabulary to properly discuss ideas, everybody just wanted microservices because that was the next cool thing, and looked absolutely perplexed when explained the pitfalls.

GraphQL, this, and all the different kind of faas platforms popping up nowadays all help as a point of reference.

I truly think we are on the verge of radically changing how we build applications soon - I think these technologies can be viewed as a new breed of web frameworks, a breed which has the distributed principles in its core.

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.

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.

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.

Reply on news.ycombinator.com