Earlier quoted context omitted.
How?
The 'monolith' (which I find a silly term but I'll use it here) can expose different parts of itself as services. As long as those services can be versioned and are backwards compatible, you can deploy the monolith using any schedule or notification mechanism you like. If the monolith is composed of modules with a DAG-like dependency structure (e.g. maven projects), then pieces of the monolith can be deployed alongsi…
Why our team cancelled our move to microservices
91–100 of 243 posts
Re: Why our team cancelled our move to microservices
#92Earlier quoted context omitted.
Doesn't this just mean you picked a bad service boundary? You shouldn't have to join across services, ever. Seems like a straw man.
It will eventually happen even if you manage to create the perfect boundaries, e.g for report & statistics.
Re: Why our team cancelled our move to microservices
#93> We have approximately 12 developers spread across 2 feature teams and a support team. If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard. And as they eventually discovered, a lot of unnecessary overhead for such a s…
Beyond scaling a large development org the primary benefits of micro-services accrue to consultants who bill by the hour.
Re: Why our team cancelled our move to microservices
#94I'm not speaking from experience here, but it seems like rather than "moving to a microservices architecture" it would perhaps be better to think more in terms of "splitting out specific functionality X into an independently deployable and hostable service, which should alleviate the specific problem Y that we've been experiencing due to their being too closely coupled" and if there are no obvious X and Y then maybe…
Man-with-a-hammer syndrome is dangerous.
Re: Why our team cancelled our move to microservices
#95> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
Generally speaking if you're adding another field to a JSON or something, that doesn't really break the parser [1] or affect downstream. While you should still probably let the downstream teams know, it's not necessarily going to break anyone's code. [1] I'm aware that that's not always true (e.g. adding a field that's ridiculously large choking up the parser).
Re: Why our team cancelled our move to microservices
#96I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding out of them. Suddenly huge bugs that no one noticed or cared about are showing up in testing. Old libraries that sat dormant wake from their crypts to harass and torture junior developers. Forgotten binaries whose source code was lost with the changeover from ancient source control software to GIT starts showing up security issues in VeraCode.
Really, a well coded monolith is just a bunch of micro-services on the same server communicating through memory. In reality it's more of a Lich who's eyes shine with the light of the tortured souls of fallen QA testers and developers.
Re: Why our team cancelled our move to microservices
#97Re: Why our team cancelled our move to microservices
#98Why would you consider microservices if you are only 12 developers?
Most of the conversation so far has focused on the development benefits of microservices (decoupling deployments, less coordination between teams, etc). Small teams don't really have this problem, but there are other benefits to microservices. One of the biggest is scaling heterogeneous compute resources. Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming…
Real-world monoliths often do have some supporting services or partner services that they interact with. That doesn't mean you need a "micro-service architecture" in order to scale your workload.
Re: Why our team cancelled our move to microservices
#99The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…
Meh. In order to sound smart on HN it's easiest to point at something and call it "hype".
> Microservices are relatively new and unproven
SOA is old as fuck. Microservices are also fairly old, but especially when you consider they're really just SOA + dogma.
> Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases...
No? Not at all.
> Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it's a sticker shock that you can only stop by going offline.
Alternatively phrased: If you only use one service you only pay for it, not for the whole suite of features you don't need or want.
> We have also seen enough failures and pain points within microservice and even cloud architectures over the past two years alone to raise questions about whether or not it it indeed a better solution.
And plenty of success stories.
> We need to stop disparaging traditional (non-cloud) hosting and solutions that aren't obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.
Microservices work, are secure, and are cost effective.
Honestly your post contains no useful information and is satirically close to a "return to traditional family values!" speech.
Re: Why our team cancelled our move to microservices
#100Going from a monolith to a micro-service setup is essentially my idea of a Christian hell. Swirling depths of pain and uncertainty interspersed with screaming and urgency. There is no rest. No one knows when it will end. I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding…