4 ms·

I don't see how microservices makes that overhead go away. That overhead is really a matter of proper systems engineering. With well-defined interfaces and pr

I don't see how microservices makes that overhead go away. That overhead is really a matter of proper systems engineering. With well-defined interfaces and properly-sectioned functional components teams can work just as independently on a monolithic application as they can on a microservice application. Similarly, a poorly-sectioned application with bad or nebulous interfaces will be a planning and coordination nightmare regardless of the architecture. What I think the microservice architecture does is force some measure of good systems engineering on a team. You can't design a microservice application without putting effort into deciding how to divide the functionality and defining how those functional blocks will work with each other. You can get away with not doing that (until it's too late) when designing a monolithic application.

optimuspaul 11y ago
I've actually found overhead to increase significantly when using micro-services vs a monolithic codebase. Automated integration testing is far more complex. Ensuring that a change in one micro service doesn't break things in another can be daunting. But when you have a common codebase dependencies are far more clear. Of course if you have tons of cash and resources to throw at it then that isolation could be beneficial. But is it worth it? I have no idea.
- vonmoltke 11y ago
  > Ensuring that a change in one micro service doesn't break things in another can be daunting. That is what I was referring to when I mentioned nebulous APIs. In a properly-designed system, each component (be it a module of a monolithic system or service in a microservice system) should be a black box with known APIs and no side effects. Part of defining the API is defining the acceptable values that can come across the wire. If designed correctly, breaking another service should not be possible without an API change. An API change should be something signed off by systems engineering and communicated to all affected teams before it happens. Done right, this is a fairly heavyweight process and so, as others have said, is only something that should be done when a project reaches a certain level of complexity (both code and team).
  - wvenable 11y ago
    The more your system is broken down into smaller components the more you have to break an API to make a change. Unless all change consists of nothing but bug fixes and performance enhancements, changes to the API is as common as anything else. If your need is respond quickly to changing requirements this setup falls flat.
    - cpitman 11y ago
      Yes, if services are too small than it will be hell. A lot of microservice proponents talk about how services should align to a "bounded context", essentially a domain of the business. That makes it more likely that (1) there are well defined interfaces between business domains and (2) changes will be grouped into a single service as opposed to requiring changes throughout the codebase. Also, if it's being done right, you rarely "break" an API in a single blow. You add new functionality, possibly via a new API. You give your consumers ample time to migrate. Only then do you remove the old API. One of my old teams had a hard requirement that all APIs had to be backwards compatible for 2 versions, which was essentially a year. We got very good at adding functionality without any impact on consumers that had not upgraded yet.
    - lowbloodsugar 11y ago
      We've never had to break an API to make a change. Changes to the API should not break existing consumers. That's just as true for monoliths as it is for microservices.
      - wvenable 11y ago
        A change to an API necessarily, by definition, breaks existing consumers. You can add to an API without breaking consumers but you can't change or remove.
        lowbloodsugar 11y ago
        There are at least two ways to change an API without breaking it: * Adding a new method to the API does not break the API. * In certain language/middleware combinations, adding new properties to a parameter object does not break the API. If we have a method that needs to change, we add a new method. New clients use the new method, and we support old clients until they are retired. When using JAX-RS, we can add new properties to JSON objects provided they are annotated correctly.
- cpitman 11y ago
  In most environments systems are already distributed, it's just that each "component" is a massive monolith. Sometimes, it's the cobol monolith, the .Net monolith that partially replaced it, and the NodeJS monolith that is going to replace everything (for sure, this time we mean it). Integration testing is already complex in these environments, regardless of whether the components are monoliths or microservices. BDD style integration tests should be almost equivalent, regardless of the architecture, since they are driven by the business domain.
tkahnoski 11y ago
Caveat: I have not implemented microservices, but have plenty of experience with monoliths. "With well-defined interfaces and properly-sectioned functional components teams can work just as independently on a monolithic application as they can on a microservice application" Basically if you build a monolith such that it is not a monolith things are ok. This doesn't happen in my experience. Speaking first hand, working with 40 engineers on a 500k+ line codebase. The monolith is as robust as it's weakest component. There are secondary organizational effects that come into play as well with monolith architecture that need to be mitigated. Because there's a single monolithic platform, the org believes it can throw any set of engineers at a problem in the monolith and get the same result. This largely gets down to what philosophies you buy into, but I personally believe long lived teams with long lived missions are better capable to innovate (team builds depth of expertise in a capability vs breadth). There are plenty of ways to do anything wrong of course. More so, as the team scales to more engineers, the monolithic architecture re-enforces the monolithic engineering org which means an increase in communication overhead. My experience is that by creating a monolith you create one way to do things that leaves the organization less adaptable to change to implementing a new technology or pattern.

optimuspaul 11y ago

I've actually found overhead to increase significantly when using micro-services vs a monolithic codebase. Automated integration testing is far more complex. Ensuring that a change in one micro service doesn't break things in another can be daunting. But when you have a common codebase dependencies are far more clear. Of course if you have tons of cash and resources to throw at it then that isolation could be beneficial. But is it worth it? I have no idea.

vonmoltke 11y ago
> Ensuring that a change in one micro service doesn't break things in another can be daunting. That is what I was referring to when I mentioned nebulous APIs. In a properly-designed system, each component (be it a module of a monolithic system or service in a microservice system) should be a black box with known APIs and no side effects. Part of defining the API is defining the acceptable values that can come across the wire. If designed correctly, breaking another service should not be possible without an API change. An API change should be something signed off by systems engineering and communicated to all affected teams before it happens. Done right, this is a fairly heavyweight process and so, as others have said, is only something that should be done when a project reaches a certain level of complexity (both code and team).
- wvenable 11y ago
  The more your system is broken down into smaller components the more you have to break an API to make a change. Unless all change consists of nothing but bug fixes and performance enhancements, changes to the API is as common as anything else. If your need is respond quickly to changing requirements this setup falls flat.
  - cpitman 11y ago
    Yes, if services are too small than it will be hell. A lot of microservice proponents talk about how services should align to a "bounded context", essentially a domain of the business. That makes it more likely that (1) there are well defined interfaces between business domains and (2) changes will be grouped into a single service as opposed to requiring changes throughout the codebase. Also, if it's being done right, you rarely "break" an API in a single blow. You add new functionality, possibly via a new API. You give your consumers ample time to migrate. Only then do you remove the old API. One of my old teams had a hard requirement that all APIs had to be backwards compatible for 2 versions, which was essentially a year. We got very good at adding functionality without any impact on consumers that had not upgraded yet.
  - lowbloodsugar 11y ago
    We've never had to break an API to make a change. Changes to the API should not break existing consumers. That's just as true for monoliths as it is for microservices.
    - wvenable 11y ago
      A change to an API necessarily, by definition, breaks existing consumers. You can add to an API without breaking consumers but you can't change or remove.
      - lowbloodsugar 11y ago
        There are at least two ways to change an API without breaking it: * Adding a new method to the API does not break the API. * In certain language/middleware combinations, adding new properties to a parameter object does not break the API. If we have a method that needs to change, we add a new method. New clients use the new method, and we support old clients until they are retired. When using JAX-RS, we can add new properties to JSON objects provided they are annotated correctly.
cpitman 11y ago
In most environments systems are already distributed, it's just that each "component" is a massive monolith. Sometimes, it's the cobol monolith, the .Net monolith that partially replaced it, and the NodeJS monolith that is going to replace everything (for sure, this time we mean it). Integration testing is already complex in these environments, regardless of whether the components are monoliths or microservices. BDD style integration tests should be almost equivalent, regardless of the architecture, since they are driven by the business domain.

tkahnoski 11y ago

Caveat: I have not implemented microservices, but have plenty of experience with monoliths. "With well-defined interfaces and properly-sectioned functional components teams can work just as independently on a monolithic application as they can on a microservice application" Basically if you build a monolith such that it is not a monolith things are ok. This doesn't happen in my experience. Speaking first hand, working with 40 engineers on a 500k+ line codebase. The monolith is as robust as it's weakest component. There are secondary organizational effects that come into play as well with monolith architecture that need to be mitigated. Because there's a single monolithic platform, the org believes it can throw any set of engineers at a problem in the monolith and get the same result. This largely gets down to what philosophies you buy into, but I personally believe long lived teams with long lived missions are better capable to innovate (team builds depth of expertise in a capability vs breadth). There are plenty of ways to do anything wrong of course. More so, as the team scales to more engineers, the monolithic architecture re-enforces the monolithic engineering org which means an increase in communication overhead. My experience is that by creating a monolith you create one way to do things that leaves the organization less adaptable to change to implementing a new technology or pattern.