31–40 of 243 posts
This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.
The 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…
If you are noname rapper you start dissing bigger guys so they diss you back and you get notoriety because someone noticed you.
As a politician you have to say others are the worst and broke everything but you have plan to fix everything that is broken now.
In the end all the swearing is posturing and all "great plans" turn out not possible in reality.
While yes you can do nice stuff with microservices, it is not a silver bullet.
> Microservices allow your team to have control over the full stack they require to deliver a feature. This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.
Seems like an organizational decision
There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.
> 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?
They have multiple versions of calls. The older one function as before and never change. Want different behavior - here is your_interface_v1(), your_interface_v2(), etc.
You still alert team about new functionality but they're free to consume it at their own pace. This of course involves a boatload of design and planning.
I am in general against microservices and consider those as the last resort when nothing else works. To me a microservice is mostly my monolith interacting with another monolith.
When monolith becomes big enough that it needs 2 teams I usually handle it by each team releasing their part as a library that still gets linked into the same monolith. That is my version of "microservice" when the only reason for it to exist is to have two or more "independent" teams.
That being said, the biggest hurdle in a re-architecture project like this is usually in the "n=1 -> n=2" stage, and "n=2 -> n=5" is a lot easier: once you add service #2, you learn how to set up telemetry, permissions, billing/chargeback, alerting, etc. The next few are just repeating the same process.
It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop…
I think the catch is that "Services" are typically the scope at which encapsulation should stop. They don't need to be "Micro".
> 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?
Do you not version APIs you design? When engineering an API meant for consumption by disparate services it’s imperative to provide back words compatibility. This is pretty basic stuff anyone designing a serious API should be taking into account.
The 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…
> Microservices are relatively new and unproven. They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
What I think he is saying is that Microservices people pitch their service against monolith as better, but monolith hasn't been in vogue for 20 years. I saw the same tactic with scrum people pitching against waterfall which hadn't been in vogue for quite a while either.