4 ms·

I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.

by eej71 10y ago

falcolas 10y ago
I'd counter that they also force a lot of additional networked API boilerplate, and all new code is a potential source of bugs. Perhaps it's better to break it into libraries with well defined APIs, and then break those libraries out into services when necessary. Jumping straight to the latter is going to create more room for problems than it solves.
- dsmithatx 10y ago
  Well we are rebuilding from scratch into micro services as we have the man power and money to do it. Why not just go with libraries? Here are the top five reasons off of the top my head. The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Deployments and scaling will be much faster. If one endpoint goes down it wont affect others. We are working to ensure one endpoint is not dependent on another. When change is required in a certain part of the application, only the related service can be modified and redeployed. No long-term commitment to a single technology stack
  - tekklloneer 10y ago
    This is like looking into a mirror.
  - acdha 10y ago
    That sounds like most of the benefits you're describing simply due to redesigning the system with the benefit of experience and the much deeper knowledge about the problem which you learned building it the first time. Almost every point on your list could be restated in the opposite direction: > The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. The decision to require use has nothing to do with microservice/monolith and you'd get the same consistency benefits if you deployed a large single application in a container as well, plus you'd have the added simplicity and debugging benefits from not needing to run additional applications for things like orchestration or service discovery. > This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Easier to understand is an aesthetic choice but it generally means things like a clean design, organization, good documentation, etc. which can be done in a monolith as well. Smaller services can encourage that but they don't necessarily – I've seen plenty of gnarly interdependencies and under-documented schemas – and they have a hard up-front cost that now all of your new developers will need to be able to start, reload, and debug many separate services and understand any interdependencies. If your culture and tooling can manage that well, it almost certainly could maintain a clean larger codebase following the same principles. > Deployments and scaling will be much faster. If one endpoint goes down it won't affect others. We are working to ensure one endpoint is not dependent on another. This is certainly the appeal but many places find that the scaling benefits are less than predicted because the business logic requires things which are harder than expected to separate or scale independently, and there's a cost to separation if that means that you're now forced to implement something like distributed transactions or locking on top of your own custom services. Again, I think a team with the experience and support which can do this well in one model is also likely to have similar results with the other. > When change is required in a certain part of the application, only the related service can be modified and redeployed. If you have a well-defined automated deployment process, this is a relatively minor benefit in either case. Assuming you weren't just running a single instance of the previous app, you need a way to handle things like blue-green deployment, managing schema updates, etc. no matter which design philosophy you pick. > No long-term commitment to a single technology stack This is one of the strongest arguments, but there is also a cost involved to having to learn and support multiple stacks. Again, I think that's more a function of culture and resources — I've seen places which were too conservative until they couldn't find developers at any price as well as places which had severe “Oooh, shiny” problems where every module was written in the latest thing the "lead" developer had seen that week. Again, I'm not saying one approach is right or wrong but rather that it's too narrow a view to look at one practice in isolation. The microservice idea has been around for decades but it hasn't become universal because quality of implementation matters a lot and it's not optimal for all problems — I'm pretty sure the team at Oracle which built the deeply horrible business application I had to support about a decade ago used many of the same arguments to pitch the benefit of their enterprise Java web service architecture, which turned simple database queries into thousands of calls to services on a dozen servers. It's not that the concept was right or wrong but that it wasn't a silver bullet.
- Chyzwar 10y ago
  But your networked API is language agnostic, your library is not. It depends but microservices are in many cases better where your application is large. Examples: AWS, Uber. Monolith is better if your application smaller and cover just single problem. Examples: Slack, Trello, Jira
  - mhluongo 10y ago
    I'm skeptical that Slack is in the "better as a monolith" category considering the message volume they must process
    - flukus 10y ago
      Microservices don't solve the volume problem, a monolith can have multiple to deployments to handle volume.
- flukus 10y ago
  I've also seen them be he source of some awful n+1 bugs where network boundaries were being crossed thousands of times to fetch some relatively simple data. The wall time might be tiny on it's own but it can add up. I've also worked on an app where we removed/combined the api layer into the main web process for an instant 30% performance boost. Crossing the network boundary, serializing, etc was taking up a full third of the wall time that included server side html rendering and database access.
acdha 10y ago
I think those issues are orthogonal: if the environment wouldn't discourage a hasty library API, it seems unlikely that it would discourage a similarly-poor network service. The part I would try to focus on is the culture for things like review and what your threshold is for treating something as a reusable service rather than an internal detail for one app.
maxxxxx 10y ago
I think if you are not capable of designing a decent API you won't be able to design good microservices either. Both require some level of competence and discipline.

I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.

by eej71 10y ago

I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.

falcolas 10y ago

I'd counter that they also force a lot of additional networked API boilerplate, and all new code is a potential source of bugs. Perhaps it's better to break it into libraries with well defined APIs, and then break those libraries out into services when necessary. Jumping straight to the latter is going to create more room for problems than it solves.

dsmithatx 10y ago
Well we are rebuilding from scratch into micro services as we have the man power and money to do it. Why not just go with libraries? Here are the top five reasons off of the top my head. The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Deployments and scaling will be much faster. If one endpoint goes down it wont affect others. We are working to ensure one endpoint is not dependent on another. When change is required in a certain part of the application, only the related service can be modified and redeployed. No long-term commitment to a single technology stack
- tekklloneer 10y ago
  This is like looking into a mirror.
- acdha 10y ago
  That sounds like most of the benefits you're describing simply due to redesigning the system with the benefit of experience and the much deeper knowledge about the problem which you learned building it the first time. Almost every point on your list could be restated in the opposite direction: > The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. The decision to require use has nothing to do with microservice/monolith and you'd get the same consistency benefits if you deployed a large single application in a container as well, plus you'd have the added simplicity and debugging benefits from not needing to run additional applications for things like orchestration or service discovery. > This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Easier to understand is an aesthetic choice but it generally means things like a clean design, organization, good documentation, etc. which can be done in a monolith as well. Smaller services can encourage that but they don't necessarily – I've seen plenty of gnarly interdependencies and under-documented schemas – and they have a hard up-front cost that now all of your new developers will need to be able to start, reload, and debug many separate services and understand any interdependencies. If your culture and tooling can manage that well, it almost certainly could maintain a clean larger codebase following the same principles. > Deployments and scaling will be much faster. If one endpoint goes down it won't affect others. We are working to ensure one endpoint is not dependent on another. This is certainly the appeal but many places find that the scaling benefits are less than predicted because the business logic requires things which are harder than expected to separate or scale independently, and there's a cost to separation if that means that you're now forced to implement something like distributed transactions or locking on top of your own custom services. Again, I think a team with the experience and support which can do this well in one model is also likely to have similar results with the other. > When change is required in a certain part of the application, only the related service can be modified and redeployed. If you have a well-defined automated deployment process, this is a relatively minor benefit in either case. Assuming you weren't just running a single instance of the previous app, you need a way to handle things like blue-green deployment, managing schema updates, etc. no matter which design philosophy you pick. > No long-term commitment to a single technology stack This is one of the strongest arguments, but there is also a cost involved to having to learn and support multiple stacks. Again, I think that's more a function of culture and resources — I've seen places which were too conservative until they couldn't find developers at any price as well as places which had severe “Oooh, shiny” problems where every module was written in the latest thing the "lead" developer had seen that week. Again, I'm not saying one approach is right or wrong but rather that it's too narrow a view to look at one practice in isolation. The microservice idea has been around for decades but it hasn't become universal because quality of implementation matters a lot and it's not optimal for all problems — I'm pretty sure the team at Oracle which built the deeply horrible business application I had to support about a decade ago used many of the same arguments to pitch the benefit of their enterprise Java web service architecture, which turned simple database queries into thousands of calls to services on a dozen servers. It's not that the concept was right or wrong but that it wasn't a silver bullet.
Chyzwar 10y ago
But your networked API is language agnostic, your library is not. It depends but microservices are in many cases better where your application is large. Examples: AWS, Uber. Monolith is better if your application smaller and cover just single problem. Examples: Slack, Trello, Jira
- mhluongo 10y ago
  I'm skeptical that Slack is in the "better as a monolith" category considering the message volume they must process
  - flukus 10y ago
    Microservices don't solve the volume problem, a monolith can have multiple to deployments to handle volume.
flukus 10y ago
I've also seen them be he source of some awful n+1 bugs where network boundaries were being crossed thousands of times to fetch some relatively simple data. The wall time might be tiny on it's own but it can add up. I've also worked on an app where we removed/combined the api layer into the main web process for an instant 30% performance boost. Crossing the network boundary, serializing, etc was taking up a full third of the wall time that included server side html rendering and database access.

acdha 10y ago

I think those issues are orthogonal: if the environment wouldn't discourage a hasty library API, it seems unlikely that it would discourage a similarly-poor network service. The part I would try to focus on is the culture for things like review and what your threshold is for treating something as a reusable service rather than an internal detail for one app.

maxxxxx 10y ago

I think if you are not capable of designing a decent API you won't be able to design good microservices either. Both require some level of competence and discipline.