3 ms·

> Services are defined as units of software with well-defined API interfaces, called endpoints ( in Figure 1). Each service satisfies a specific business use ca

> 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/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.

oersted 3y ago
As I understand it, the concept of microservices mainly originated to solve organisational bottlenecks, rather than to improve the quality of the software itself. 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.

oersted 3y ago

As I understand it, the concept of microservices mainly originated to solve organisational bottlenecks, rather than to improve the quality of the software itself. 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.