4 ms·

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 rea

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.

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.