4 ms·

> Going on the assumption that you do spec out the interface to your microservices with some care I reckon this is hardly ever done. Microservices, like many o

> Going on the assumption that you do spec out the interface to your microservices with some care I reckon this is hardly ever done. Microservices, like many other abstractions, usually just proliferate and quickly become a maintenance nightmare.

parasubvert 12y ago
Microservices are (generally) developed and owned by different teams. In that sense, they proliferate to the number of teams you have. I've also found that multi-team organizations with a strong architecture core will constrain "how" interfaces are designed pretty well (leaving the specifics to the teams). This also requires fast feedback and continuous integration. The old saying "team = product" applies: if your business requires lots of parts independently evolving, you're going to find ways to make them cooperate at the boundaries, or you will be in a mess. Companies like Amazon have made this approach work at speed and scale. Others might fail out of incompetence. Mostly I think people are just looking for ways to operate at better speed and scale than the current enterprise practices.
- jacques_chester 12y ago
  > The old saying "team = product" applies This is usually introduced as "Conway's Law". We think about it a lot at Pivotal, because we are frequently starting, shuffling, merging and splitting teams while we work on Cloud Foundry.
  - parasubvert 12y ago
    And I am newly in the Pivotal field looking to help people adopt Cloud Foundry and microservices :)
lgas 12y ago
I don't disagree but I suspect that proliferation of components within a monolithic app is roughly comparable and leads to similar maintence burdens. If I'm right then the microservice model has one major advantage over the monolithic app model, which is that if things stop depending on a microservice you generally can tell because eg logs are empty or instance utilization is zero or whatever. With components in a monolithic app there are tools in most languages to find dead code but I've not seen them used regularly in many teams (especially startups) and they are often less helpful in that they can tell if code is no longer referred to at all but not if its just in a code path that is no longer executed. My gut feeling is that this leads to dead microservices being garbage collected more reliably than dead code.

parasubvert 12y ago

Microservices are (generally) developed and owned by different teams. In that sense, they proliferate to the number of teams you have. I've also found that multi-team organizations with a strong architecture core will constrain "how" interfaces are designed pretty well (leaving the specifics to the teams). This also requires fast feedback and continuous integration. The old saying "team = product" applies: if your business requires lots of parts independently evolving, you're going to find ways to make them cooperate at the boundaries, or you will be in a mess. Companies like Amazon have made this approach work at speed and scale. Others might fail out of incompetence. Mostly I think people are just looking for ways to operate at better speed and scale than the current enterprise practices.

jacques_chester 12y ago
> The old saying "team = product" applies This is usually introduced as "Conway's Law". We think about it a lot at Pivotal, because we are frequently starting, shuffling, merging and splitting teams while we work on Cloud Foundry.
- parasubvert 12y ago
  And I am newly in the Pivotal field looking to help people adopt Cloud Foundry and microservices :)

lgas 12y ago

I don't disagree but I suspect that proliferation of components within a monolithic app is roughly comparable and leads to similar maintence burdens. If I'm right then the microservice model has one major advantage over the monolithic app model, which is that if things stop depending on a microservice you generally can tell because eg logs are empty or instance utilization is zero or whatever. With components in a monolithic app there are tools in most languages to find dead code but I've not seen them used regularly in many teams (especially startups) and they are often less helpful in that they can tell if code is no longer referred to at all but not if its just in a code path that is no longer executed. My gut feeling is that this leads to dead microservices being garbage collected more reliably than dead code.