Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
Strong agree. The need to transition to microservices will sneak up on an organization -- and that's okay. It's surprising how much life you can squeeze out of a monolith.
You Don't Need Microservices
31–40 of 169 posts
Re: You Don't Need Microservices
#32Earlier quoted context omitted.
Micro-services also good when an organization has a numbers of teams with different domains and release cycles, at some point it would be easier to spit code in some ways and have a boundaries. In this case splitting to services/micro-services creates those boundaries on a network level.
Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."
Re: You Don't Need Microservices
#33Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...
Re: You Don't Need Microservices
#34Re: You Don't Need Microservices
#35Earlier quoted context omitted.
Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."
I know you are referring to something else, but it actually means that the battle is won.
Re: You Don't Need Microservices
#36>Modularize Your Monolith It is true that probably any monolith can be break down into components, that won't prevent the full redeployment (and all the risks that it brings) though. I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.
Or do the whole redeployment all the time and you'll see the "risk" of doing so was psychological or a few better tests away. I work in a 150+ yo company where change is ... well not welcome. When we said we could try to release without schedule, several times a week, whenever we want just because we finished one thing at a time, you should have seen their looks. We have 100 microservices doing low latency trading in…
YMMV but I do have personal experience where the risks weren't psychological. Teams stepping into each other shoes and broken each other features are a real problem, solved by communication but that overhead has real costs.
Re: You Don't Need Microservices
#37Re: You Don't Need Microservices
#38I wrote a library [1] for Laravel that lets you put a kind of "microservice" inside of your monolith. It lets you develop, deploy, and execute AWS Lambda functions from your Laravel application. The theory here is that sometimes you need some other language/infrastructure beyond what you're comfortable devops-ing yourself, and Lambda is actually quite good at providing you with an entire stack of stuff you don't have…
IMHO, AWS Chalice remains the goto method to generate REST API serverless manner but also curious how yours also differ from the paid Laravel solution that lets you deploy your stack serverless.
Re: You Don't Need Microservices
#39Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.