4 ms·

It's sad to see this approach being pushed so hard these days. I believe AWS recommends these things so your app becomes so deeply entrenched in all of their se

It's sad to see this approach being pushed so hard these days. I believe AWS recommends these things so your app becomes so deeply entrenched in all of their services that you've locked yourself into them forever. Unfortunately I see a lot of mid and senior devs try to propose these architectures during interviews and when asked questions on integration testing, local environment testing, enforcing contracts, breaking changes, logical refactoring a lot of it falls apart. There's a lot of pressure for those guys to deliver these sort of highly complex systems and all the DevOps that surround it when they enter a new company or project. Rarely is the project scope or team size considered and huge amounts of time are wasted implementing the bones since they skip the whole monolith stage. Precious few companies are at the size where they can keep an entire Dev team working on a shopping cart component in perpetuity. For most it's just something that gets worked on for a sprint or two. AWS made a fundamental assumption in this that monoliths and big balls of mud are the same thing. Monoliths can and should be architected with internal logical separation of concerns and loose coupling. Domain driven design helps achieve that. The other assumption that microservices is a fix to this isn't, because the same poor design can be written but now with a network in between everything. I think this advice is worth a read, but it's not law. The most pragmatic approach to microservices is to start with a monolith and shave off the intensive parts to separate services as you need to.

mattbillenstein 7y ago
Yes! Been preaching this for years! I've untangled more than a couple small eng teams (~ < 20 devs) that were trying to do microservices using this recipe on aws and just horrendously failing at it. A well-architeched monolith will really go a long way - generally perhaps easily up to 100 or more devs before thinking about microservices.
- shantly 7y ago
  - If it doesn't have very different scaling needs from the rest of the application, probably don't make it a microservice. - If it isn't something you could plausibly imagine using as a 3rd party service (emailer/sms/push messages, authentication/authorization, payments, image processing, et c.) probably don't make it a microservice. - If you don't have at least two applications at least in development that need the same service/functionality, probably don't make a microservice. - If the rest of your app will completely fall over if this service fails, probably don't make it a microservice. - Do write anything that resembles the above, but that you don't actually need to make a microservice yet, as a library with totally decoupled deps from the rest of your program.
twblalock 7y ago
> The most pragmatic approach to microservices is to start with a monolith and shave off the intensive parts to separate services as you need to. I've seen that attempted several times but I've never seen it succeed even after several years of shaving things off here and there. The problem with this approach is the same problem that causes all technical debt -- cleaning up technical debt takes time away from developing new features, which is the company's highest priority. Adding more engineers to the team to help tackle debt won't help because management will see that as an opportunity to get more new features. Now that the dust has settled, it's become clear that the real advantage of microservices is to decouple teams. Shared codebases become harder to work with as the number of engineers increases, and that hurts developer productivity. Don't build a monolithic service for the whole company -- have every team manage their own services, on their own development and release schedule, and their own production scale. Their dependencies on other teams should be based on APIs, not code sharing. Whether an individual team chooses a monolith or microservices doesn't really matter.
cle 7y ago
It isn’t as black and white as you are portraying it. You can go too far in the microservices direction, and you can go too far towards a monolith. There’s a sweet spot. I currently think that this sweet spot is around one service per “team” (around no more than 10 people). This lets teams operate and deploy their services independently, while still retaining some of the cohesiveness of a monolith. It also lets the company “refactor” engineering teams by moving service ownership around. There are definitely legitimate reasons for a team to own multiple services though (organizational changes, differences in scale, security constraints, etc.). Monoliths shared across dozens of people are operational nightmares because there’s not a strong sense of operational ownership, so you often end up with a bunch of process and bureaucratic overhead to compensate. Your advice to start with a monolith is too simplistic. If you know how your service will scale and your engineering teams will grow, then you have enough information a priori to avoid the waste of attempting to split apart a monolith later.
ris 7y ago
Yes, it's awfully fun that they're using the term "Modern" applications to describe applications which I wouldn't touch with a bargepole. Guess I'm just not "Modern". Then again, I was chuckling in the a similar way a few years ago when not using mongodb et al made me not "web scale".

mattbillenstein 7y ago

Yes! Been preaching this for years! I've untangled more than a couple small eng teams (~ < 20 devs) that were trying to do microservices using this recipe on aws and just horrendously failing at it. A well-architeched monolith will really go a long way - generally perhaps easily up to 100 or more devs before thinking about microservices.

shantly 7y ago
- If it doesn't have very different scaling needs from the rest of the application, probably don't make it a microservice. - If it isn't something you could plausibly imagine using as a 3rd party service (emailer/sms/push messages, authentication/authorization, payments, image processing, et c.) probably don't make it a microservice. - If you don't have at least two applications at least in development that need the same service/functionality, probably don't make a microservice. - If the rest of your app will completely fall over if this service fails, probably don't make it a microservice. - Do write anything that resembles the above, but that you don't actually need to make a microservice yet, as a library with totally decoupled deps from the rest of your program.

twblalock 7y ago

> The most pragmatic approach to microservices is to start with a monolith and shave off the intensive parts to separate services as you need to. I've seen that attempted several times but I've never seen it succeed even after several years of shaving things off here and there. The problem with this approach is the same problem that causes all technical debt -- cleaning up technical debt takes time away from developing new features, which is the company's highest priority. Adding more engineers to the team to help tackle debt won't help because management will see that as an opportunity to get more new features. Now that the dust has settled, it's become clear that the real advantage of microservices is to decouple teams. Shared codebases become harder to work with as the number of engineers increases, and that hurts developer productivity. Don't build a monolithic service for the whole company -- have every team manage their own services, on their own development and release schedule, and their own production scale. Their dependencies on other teams should be based on APIs, not code sharing. Whether an individual team chooses a monolith or microservices doesn't really matter.

cle 7y ago

It isn’t as black and white as you are portraying it. You can go too far in the microservices direction, and you can go too far towards a monolith. There’s a sweet spot. I currently think that this sweet spot is around one service per “team” (around no more than 10 people). This lets teams operate and deploy their services independently, while still retaining some of the cohesiveness of a monolith. It also lets the company “refactor” engineering teams by moving service ownership around. There are definitely legitimate reasons for a team to own multiple services though (organizational changes, differences in scale, security constraints, etc.). Monoliths shared across dozens of people are operational nightmares because there’s not a strong sense of operational ownership, so you often end up with a bunch of process and bureaucratic overhead to compensate. Your advice to start with a monolith is too simplistic. If you know how your service will scale and your engineering teams will grow, then you have enough information a priori to avoid the waste of attempting to split apart a monolith later.

ris 7y ago

Yes, it's awfully fun that they're using the term "Modern" applications to describe applications which I wouldn't touch with a bargepole. Guess I'm just not "Modern". Then again, I was chuckling in the a similar way a few years ago when not using mongodb et al made me not "web scale".