3 ms·

> 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 an

> 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
> "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." I actually think the opposite is true. Having the developers on a single team manage N different service-specific projects is far simpler and lower overhead, because the infrastructure overhead of N different projects is the trivial part, compared with the complexity of managing the internal state of a single project responsible for too many things. It's like separating a software implementation into multiple different functional units, either different classes or modules or functions, to decouple them and keep them cleanly separated for testing. The "overhead" of N different specific classes is not actually a legitimate concern compared with the overhead of a single class trying to do N overlapping things (or functional units if using a different programming paradigm). It's no different for microservices. Plus it's fairly simple to run your own container orchestration layer that allows efficiently mapping different microservices onto heterogeneous hardware resources, whether in your own data center or with a cloud provider. For example, my team operates different web services for different machine learning applications. One service might do nothing but predict the age of a person in a photo. Another web service might do nothing by predict the gender. From experience, I can tell you that muddying these two things together into a single web service, just because the two endpoints are separate concepts, is a bad idea. It complicates testing, the organization of acceptance test data sets, the ability to scale out the resource needs of the different models separately, to control how they are deployed. You superficially feel like you are "saving effort" on the tiny boilerplate code that is repeated between the two to expose endpoints, sanitize inputs, etc. (most of which can be factored into an internal software package anyway, to have good code reuse), but really you are not at all, because the growth of the testing code, single-project deployment and build code, etc., dwarfs whatever tiny amount of repeat web framework stuff there might have been. They are just different logical units of concern, even if they are components of the same broader API of machine learning services we provide. I think it would represent a classic example of what you are describing as a case when you'd prefer not to organize it as microservices, and yet experience has conclusively shown my team at least that there is much greater boilerplate and mangled overhead involved with putting them into the same web service than with keeping them separate and duplicating an utterly tiny amount of work on the web service wrapper part. And this is all with the same team members maintaining and extended all of the services in a small company. It just streamlines and reduces our work to do it with microservices. > "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" I actually disagree with this, and also it is an incorrect use of "Conway's Law" (which is about software organizational structure taking on the same organizational structure of the social and communication patterns of the company, and being limited to repeat those structures as the communication process limits the design). None of that affects sets of services differently whether they are bundles or separated as microservices. Conway's Law would affect the design limitation the same way in either case, and the organization as separate or coupled services would be a totally different thing, happening at a metaorganizational level to the level where Conway's law can be applicable to software. It's also actually quite nice and easy to write extremely simple tooling with e.g. docker-compose and a trivial Makefile to control local development that has effects spanning multiple microservices. And in fact this creates really nice, version controlled artifacts that indicate how that local testing and organization works, which is often severely lacking inside the internals of a more monolithic multi-service single project, where you might be able to run it locally with superficially simpler looking commands or resources, but then the internal operation is overly coupled between services and you cannot easily see which things you can modify or change without impacting other things in unintended ways. Lastly, I think you missed the point of my comment on impedance mismatch. The problem would be taking someone who is a specialized engineer in X but then expecting them to "be a problem solver" by spending time on Y, where the person's value add is huge if you let them work on X, but is tiny if you ask them to work on Y, even after accounting for whether the business needs X or Y at the moment. For example, taking one of your best front-end engineers and requiring them to fix some broken database normalization problem, or write a stored procedure, instead of having pre-arranged for the team to contain the necessary expertise such that the front-end person can delegate that task to someone whose comparative value add is all on the data engineering side, meanwhile the front-end person goes back to work on more front-end tasks, where their comparative value add is high. The impedance mismatch comes from recognizing that if you keep a specialist in X busy with work in X, it is more optimal for the company (and more morale building for the worker), than if you ask them to be preemptible to stop doing X and instead do Y or Z which ostensibly should be things farmed out to specialists in Y or Z. It can be this way with a backend engineer, a front-end engineer, a scientific computing expert, a database expert, whatever. You are taking the classic impedance mismatch example of an ORM too literally, because the general idea is that you are restricting the valuable flow of something (the specialized skill of the worker) instead of fundamentally reorganizing resources so as to not need to restrict it (by cleanly separating responsibilities into different silos of specialization).

mlthoughts2018 8y ago

> "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." I actually think the opposite is true. Having the developers on a single team manage N different service-specific projects is far simpler and lower overhead, because the infrastructure overhead of N different projects is the trivial part, compared with the complexity of managing the internal state of a single project responsible for too many things. It's like separating a software implementation into multiple different functional units, either different classes or modules or functions, to decouple them and keep them cleanly separated for testing. The "overhead" of N different specific classes is not actually a legitimate concern compared with the overhead of a single class trying to do N overlapping things (or functional units if using a different programming paradigm). It's no different for microservices. Plus it's fairly simple to run your own container orchestration layer that allows efficiently mapping different microservices onto heterogeneous hardware resources, whether in your own data center or with a cloud provider. For example, my team operates different web services for different machine learning applications. One service might do nothing but predict the age of a person in a photo. Another web service might do nothing by predict the gender. From experience, I can tell you that muddying these two things together into a single web service, just because the two endpoints are separate concepts, is a bad idea. It complicates testing, the organization of acceptance test data sets, the ability to scale out the resource needs of the different models separately, to control how they are deployed. You superficially feel like you are "saving effort" on the tiny boilerplate code that is repeated between the two to expose endpoints, sanitize inputs, etc. (most of which can be factored into an internal software package anyway, to have good code reuse), but really you are not at all, because the growth of the testing code, single-project deployment and build code, etc., dwarfs whatever tiny amount of repeat web framework stuff there might have been. They are just different logical units of concern, even if they are components of the same broader API of machine learning services we provide. I think it would represent a classic example of what you are describing as a case when you'd prefer not to organize it as microservices, and yet experience has conclusively shown my team at least that there is much greater boilerplate and mangled overhead involved with putting them into the same web service than with keeping them separate and duplicating an utterly tiny amount of work on the web service wrapper part. And this is all with the same team members maintaining and extended all of the services in a small company. It just streamlines and reduces our work to do it with microservices. > "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" I actually disagree with this, and also it is an incorrect use of "Conway's Law" (which is about software organizational structure taking on the same organizational structure of the social and communication patterns of the company, and being limited to repeat those structures as the communication process limits the design). None of that affects sets of services differently whether they are bundles or separated as microservices. Conway's Law would affect the design limitation the same way in either case, and the organization as separate or coupled services would be a totally different thing, happening at a metaorganizational level to the level where Conway's law can be applicable to software. It's also actually quite nice and easy to write extremely simple tooling with e.g. docker-compose and a trivial Makefile to control local development that has effects spanning multiple microservices. And in fact this creates really nice, version controlled artifacts that indicate how that local testing and organization works, which is often severely lacking inside the internals of a more monolithic multi-service single project, where you might be able to run it locally with superficially simpler looking commands or resources, but then the internal operation is overly coupled between services and you cannot easily see which things you can modify or change without impacting other things in unintended ways. Lastly, I think you missed the point of my comment on impedance mismatch. The problem would be taking someone who is a specialized engineer in X but then expecting them to "be a problem solver" by spending time on Y, where the person's value add is huge if you let them work on X, but is tiny if you ask them to work on Y, even after accounting for whether the business needs X or Y at the moment. For example, taking one of your best front-end engineers and requiring them to fix some broken database normalization problem, or write a stored procedure, instead of having pre-arranged for the team to contain the necessary expertise such that the front-end person can delegate that task to someone whose comparative value add is all on the data engineering side, meanwhile the front-end person goes back to work on more front-end tasks, where their comparative value add is high. The impedance mismatch comes from recognizing that if you keep a specialist in X busy with work in X, it is more optimal for the company (and more morale building for the worker), than if you ask them to be preemptible to stop doing X and instead do Y or Z which ostensibly should be things farmed out to specialists in Y or Z. It can be this way with a backend engineer, a front-end engineer, a scientific computing expert, a database expert, whatever. You are taking the classic impedance mismatch example of an ORM too literally, because the general idea is that you are restricting the valuable flow of something (the specialized skill of the worker) instead of fundamentally reorganizing resources so as to not need to restrict it (by cleanly separating responsibilities into different silos of specialization).