3 ms·

From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potenti

From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potentially affecting your application as a whole. "Do one thing and do it well." can also be an argument for using microservices. However, your application has to be of a certain size in order for that to be a valid point. If your application merely has a few endpoints, most of which are rarely - if ever - used as each other's inputs, then using microservices only adds development overhead without yielding considerable benefit. This is also why I'm critical of the surprisingly common one-size-fits-all "Use microservices for everything" approach. Microservices are just another design pattern. They're not a cure-all for every software development problem. I, for one, am doubtful about the front-end / back-end developer dichotomy because it tends to create new silos. I don't particularly like "full-stack developer" either because I think engineers should aim to be problem solvers rather than people who merely turn someone else's solution into code. Solving a particular problem in some cases might just involve the back-end or the front-end but in most cases it not only involves both but other areas such as requirements engineering or design as well.

mlthoughts2018 8y ago
> “From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potentially affecting your application as a whole.” I think this is the same reason why “do one thing and do it well” is useful in software components or shell utilities too. Basically, what you said about microservices is just a restatement of Single Responsibility Principle / decoupling, in general, and it’s not unique to microservices. In this sense, I’d say microservices are not a design pattern. Rather, it is an organizational strategy for minimizing the risks of coupling in other design patterns, which is also why microservices are explicitly a good idea in cases when a service might only have a few independent endpoints. I don’t buy the argument that it adds overhead. In fact I’d say it explicitly reduces overhead, because the boilerplate of wrapping it in a web service is just too tiny to care about compared with the overhead required to manage the complexity when a system tries to be responsible for too many things. In other words, I think good hygiene would say defaulting to microservices is the right idea, and consolidating should require evidence that it provides the expected benefits. Personally I am reminded of the funny Andrew Gelman quote, “Just because something is counter-intuitive doesn’t make it true.” I think it’s fashionable to criticize microservice designs and people jump on the bandwagon of pretending like criticizing microservice designs is somehow more well-rounded or more nuanced, but really it’s not. It’s just an attempt to make something fashionable via contrarianism. > “I think engineers should aim to be problem solvers” I agree with this very much and it is why I think cross-silo / cross-functional engineering is junk. The best way to organize a team of problem solvers is to clearly delineate the boundaries between what the problem solving responsibilities are. If people use the term “problem solver” to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to “just solve the problem” no matter what the impedance mismatch between their skill area and the problem area, then it renders the term “problem solver” meaningless, and will just lead to a big mess of dysfunction. As an engineering manager, one of my most important jobs is to empower engineers to say “no.” To reject inappropriately allocated work or inappropriate cross-functional pivoting driven by ineffective short term business thinking. The engineers have to be empowered to say, “Hey, that work should not be assigned to us” because it signals whether the business overall has structured itself and staffed itself appropriately to actually respond to the business problems sent by Mother Nature at us. If we are structured wrongly, yet try to paper over it by pressuring engineers to be HR-approved “problem solvers” in the sense of more just doing what they are told instead of doing what would actually work, it will be medium-term detrimental and counter-productive. In this sense, I think “silo” is a good word, and indicates a good engineering culture where different silos have the power to say “no” and where specializations are respected and planned for by the management. Yes, of course that can be subverted into an anti-pattern in poorly run businesses, but that’s a property of bad management, not of “silos” in and of themselves.
- BjoernKW 8y ago
  > I don’t buy the argument that it adds overhead. In fact I’d say it explicitly reduces overhead At the very least microservices add infrastructure overhead and network latency. In terms of everyday development complexity, instead of 1 project for a monolithic application you now have n projects, one for each microservice, which is fine if your organization is large enough and sufficiently well-organised to adhere to a "One team is responsible for each microservice." organisational pattern. If, however, your developers find themselves juggling multiple projects at a time and having to run several microservices on their local machine in order to make a change this might indicate that either there's an impedance mismatch between the communication structure of your organization and the design of your product (https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law) or that your application simply isn't sufficiently complex yet to warrant the use of microservice patterns. > In other words, I think good hygiene would say defaulting to microservices is the right idea Good hygiene is possible without microservices, too, just as microservices can be used to build the worst kind of monolith: The distributed monolith. > If people use the term “problem solver” to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to “just solve the problem” no matter what the impedance mismatch between their skill area and the problem area, then it renders the term “problem solver” meaningless, and will just lead to a big mess of dysfunction. I suppose it depends on how an organisation manages and breaks down tasks. If for example you work on a user story level a single developer can indeed be responsible for implementing a complete story including all aspects that might be involved. "Responsible for" doesn't mean "You have to do it all by yourself.". If you have a particular problem ask a specialist and ideally everyone involved will even learn something new in the process. When viewed from an impedance mismatch perspective the front-end / back-end distinction in some ways is quite arbitrary. The prototypical example of impedance mismatch is the one between object-oriented programming and relational data. However, most would expect back-end developers to be both skilled in - say - Java and a relevant SQL dialect. The impedance mismatch between a front-end technology such as Angular and a back-end technology such as Spring (both of which make use of similar patterns) is much less pronounced than that between SQL and an object-oriented language.
  - mlthoughts2018 8y ago

mlthoughts2018 8y ago

> “From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potentially affecting your application as a whole.” I think this is the same reason why “do one thing and do it well” is useful in software components or shell utilities too. Basically, what you said about microservices is just a restatement of Single Responsibility Principle / decoupling, in general, and it’s not unique to microservices. In this sense, I’d say microservices are not a design pattern. Rather, it is an organizational strategy for minimizing the risks of coupling in other design patterns, which is also why microservices are explicitly a good idea in cases when a service might only have a few independent endpoints. I don’t buy the argument that it adds overhead. In fact I’d say it explicitly reduces overhead, because the boilerplate of wrapping it in a web service is just too tiny to care about compared with the overhead required to manage the complexity when a system tries to be responsible for too many things. In other words, I think good hygiene would say defaulting to microservices is the right idea, and consolidating should require evidence that it provides the expected benefits. Personally I am reminded of the funny Andrew Gelman quote, “Just because something is counter-intuitive doesn’t make it true.” I think it’s fashionable to criticize microservice designs and people jump on the bandwagon of pretending like criticizing microservice designs is somehow more well-rounded or more nuanced, but really it’s not. It’s just an attempt to make something fashionable via contrarianism. > “I think engineers should aim to be problem solvers” I agree with this very much and it is why I think cross-silo / cross-functional engineering is junk. The best way to organize a team of problem solvers is to clearly delineate the boundaries between what the problem solving responsibilities are. If people use the term “problem solver” to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to “just solve the problem” no matter what the impedance mismatch between their skill area and the problem area, then it renders the term “problem solver” meaningless, and will just lead to a big mess of dysfunction. As an engineering manager, one of my most important jobs is to empower engineers to say “no.” To reject inappropriately allocated work or inappropriate cross-functional pivoting driven by ineffective short term business thinking. The engineers have to be empowered to say, “Hey, that work should not be assigned to us” because it signals whether the business overall has structured itself and staffed itself appropriately to actually respond to the business problems sent by Mother Nature at us. If we are structured wrongly, yet try to paper over it by pressuring engineers to be HR-approved “problem solvers” in the sense of more just doing what they are told instead of doing what would actually work, it will be medium-term detrimental and counter-productive. In this sense, I think “silo” is a good word, and indicates a good engineering culture where different silos have the power to say “no” and where specializations are respected and planned for by the management. Yes, of course that can be subverted into an anti-pattern in poorly run businesses, but that’s a property of bad management, not of “silos” in and of themselves.

BjoernKW 8y ago
> I don’t buy the argument that it adds overhead. In fact I’d say it explicitly reduces overhead At the very least microservices add infrastructure overhead and network latency. In terms of everyday development complexity, instead of 1 project for a monolithic application you now have n projects, one for each microservice, which is fine if your organization is large enough and sufficiently well-organised to adhere to a "One team is responsible for each microservice." organisational pattern. If, however, your developers find themselves juggling multiple projects at a time and having to run several microservices on their local machine in order to make a change this might indicate that either there's an impedance mismatch between the communication structure of your organization and the design of your product (https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law) or that your application simply isn't sufficiently complex yet to warrant the use of microservice patterns. > In other words, I think good hygiene would say defaulting to microservices is the right idea Good hygiene is possible without microservices, too, just as microservices can be used to build the worst kind of monolith: The distributed monolith. > If people use the term “problem solver” to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to “just solve the problem” no matter what the impedance mismatch between their skill area and the problem area, then it renders the term “problem solver” meaningless, and will just lead to a big mess of dysfunction. I suppose it depends on how an organisation manages and breaks down tasks. If for example you work on a user story level a single developer can indeed be responsible for implementing a complete story including all aspects that might be involved. "Responsible for" doesn't mean "You have to do it all by yourself.". If you have a particular problem ask a specialist and ideally everyone involved will even learn something new in the process. When viewed from an impedance mismatch perspective the front-end / back-end distinction in some ways is quite arbitrary. The prototypical example of impedance mismatch is the one between object-oriented programming and relational data. However, most would expect back-end developers to be both skilled in - say - Java and a relevant SQL dialect. The impedance mismatch between a front-end technology such as Angular and a back-end technology such as Spring (both of which make use of similar patterns) is much less pronounced than that between SQL and an object-oriented language.
- mlthoughts2018 8y ago