11–20 of 130 posts
So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.
It seems to me the problem with the microservice concept does not come from the decomposition of a monolith into well defined stateful/stateless services but indeed the lack of further principles and tools for doing so in an optimal way.
Imagine a decision process that would ingest some quantitative details (including a topology of dependencies) and volumes of information flow and computation etc and spitting out an architecture. In many cases the outcome might be "monolith".
While fads and bandwagons promising utopia are prevalent in tech as in almost all other domain, there usually is a core truth that activates them.
> Services are defined as units of software with well-defined API interfaces, called endpoints ( in Figure 1). Each service satisfies a specific business use case (e.g., cachinga photo feed). There is significant room for interpretation in defining the scope of a business use case... It seems to me the problem with the microservice concept does not come from the decomposition of a monolith into well defined stateful/…
Microservices are organized by business use-case in order to isolate a team so they can focus in deeply understanding the requirements of this specific domain. This is fundamentally a fuzzy and human division of concerns, and has little to do with the performance factors you state, which seems to be a secondary priority. Mantainability and code-quality are related concepts, but they don't seem to be the top priority either, for them it seems that it is more important to enable a team to attain deep knowledge of the problem-space assigned to them, rather than ease in implementing solutions.
Sure microservices are supposed to handle scale, but are we talking about computational scale or organizational scale? It is ambiguous, but I think it's more of the latter. That's probably why so many technical issues have surfaced surrounding this architecture after the initial hype, it was not about technical efficiency to begin with, and it only makes sense for very large teams of engineers, if at that.
Just my interpretation, I don't claim to be more qualified than any other professional here to have an opinion on it.
Earlier quoted context omitted.
Indeed, but I think we are too late for that. It's not like the usage of GOTO: someone who mattered wrote that its usage should be considered harmful, and hence nowadays GOTO has practically a niche usage. If only someone that mattered would have written on time an essay titled "Microservices Architecture Considered Harmful".
> hence nowadays GOTO has practically a niche usage. Except where it was rebranded as throw/catch. There, goto remains quite popular. All while bridled (C-style) gotos were considered acceptable by Dijstrka, but are now looked upon with disdain. Amazing what a little marketing can do.
So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.
So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.
No. microservice vs monolith is not the deciding factor of the developer speed or bugs. It wouldn't even be top 5 factor for good developers. Difference between microservices and monolith technically is just network rpc rather than function call. In itself, it doesn't make much of a difference. If a developer finds themselves stuck because of microservice architecture, they are probably very bad developer in first place
Earlier quoted context omitted.
Indeed, but I think we are too late for that. It's not like the usage of GOTO: someone who mattered wrote that its usage should be considered harmful, and hence nowadays GOTO has practically a niche usage. If only someone that mattered would have written on time an essay titled "Microservices Architecture Considered Harmful".
> hence nowadays GOTO has practically a niche usage. Except where it was rebranded as throw/catch. There, goto remains quite popular. All while bridled (C-style) gotos were considered acceptable by Dijstrka, but are now looked upon with disdain. Amazing what a little marketing can do.
Doesn't mean that Dijkstra was wrong, or that they are the same as goto.
Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located.
Sure you can simulate some use cases of try/catch with goto, but implementing the general case is much harder.
throw/catch is exactly the kind of good goto-replacement provided by "higher level" programming languages that Dijkstra is talking about in his paper.