In the end, I wonder how many companies really need microservices. What if boundaries between apps were actually enforced?
In the end, I wonder how many companies really need microservices. What if boundaries between apps were actually enforced?
Previous discussion: https://news.ycombinator.com/item?id=24571423
This is WRONG. I was in a team that somehow think that could make a decent software without using postgresql as-is. Is wrong: How many devs know how implement, CORRECTLY, ACID?
ALL OF ACID?
Then if "remove" for "efficiency" the single piece of software that ACTUALLY implement it, CORRECTLY, what exactly them expect?
Well, them were running in circles, avoiding ACID, being very efficient running 12 docker images (!) and not implementing actual features. I left because I point to this and was deemed not good fit.
With relation to microservices and all their past selves (n-tiers variations) the best advice is:
Use a rdbms, properly
Maybe, add a cache as redis.
End.
This is all you need for the vast majority of apps. And it will scale, and will perform very well. If it NOT scale and not perform very well, then is MORE likely that the app code is wrong than PostgreSQL/Redis to be wrong.
MORE.
100K LOC is hard to work with, but 10K is manageable.
I do think that's why developers idealize the microservices architecture; they don't want to have to keep 100K LOC in their head, or work with 10 other developers; they want to tend to their own 10K LOC garden, they want to isolate a problem space and focus on that, instead of the big picture which is too much for any one person to deal with.
Adding runtime networking and server management complexity to that is a completely different things though!
The book is a bit old, about process not fad technology and the age has affected it not at all.
It's describes the accurate and correct process to fix the problem you describe.