At what point does a collection of microservices become a monolith that uses http instead of a bus π€
this post was submitted on 30 May 2024
438 points (97.8% liked)
Programmer Humor
32483 readers
166 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
My favorite is seeing developers directly reach out to a DB of another microservice because βitβs just easier to pull the data from thereβ. One of the few times Iβve literally said βbruhβ
Even more often the monolith bits are pulled out but continue to share the same monolithic database. The horizontal scanning is void, because while you can make any number of stateless service instances their operations performance is mostly databound and the (relational) database cannot horizontally scale.
Oh wow, yikes. Yeah, that's misguided.
A properly architected and implemented microservice architecture optimizes work throughput while minimizing risk. In practice its architecting in such a way that no part can take down the whole individually - the very opposite of a monolith where everything is inseparably interdependent at some level.
Problem is, most organizations don't know how to properly architect for and integrate microservice architectures into their environments and work process. Most think that a crew of former sysadmins can just spin up a few saas services, slap some autoscaling on it if they're feeling spicy, segment along traditional monolith "frontend/backend" lines for "security," and call it a day. They then spend time and money learning and/or fighting this system, only to see minimal (if any) improvement in work capacity/quality and instead end up with an outsized cloud bill.
Problem is, most organizations donβt know how to properly architect for and integrate microservice architectures into their environments and work process.
Which is exactly the same thing said about OOP, or structured programming, or Agile, or a number of other paradigms. Organizations aren't doing it right, but it works if it's "properly architected". Yet, this "proper architecture" doesn't seem to exist anywhere in the real world.
In fact, I've argued before that if OOP is fundamentally about objects ending messages to each other, then microarchitectures are just an approach to OOP where the communication channel is over network sockets.
If you understand things like encapsulation and message passing, then the difference doesn't come down to microarchitecture vs monolith. It's self-contained components vs not, and the method of passing messages is only important from a feasibility and performance standpoint.
Laughs in CORBA.
All fair points.
The reality is, that hardly any projects actually need or benefit from micro services.
Most applications would scale just fine as a monolith, micro services seem to be rather an organizational tool to separate modules, because you can't come up with a proper architecture.
The problem is, most organizations don't actually need the very specific benefits that come with microservices and are also in no way equipped to deal with the tremendous increase in complexity that comes along with distributed systems.
Worst of both worlds π
We only have ten logins a day, but what if UserBirthdayEmailer suddenly needs to go Web scale?
100% agreed. But sales people gotta sell so you end up with "solutions" that create the problem they're claiming to solve in the first place
This is why I take my job as sales engineer very seriously. If a customer isn't right for the system they're far more likely to churn, so I'm going to come out and say it regardless of how it makes sales feel.
INSTANTLY
Developers tend to think in extremes.
This practice is bad sometimes? Avoid it at all costs!
This practice is good sometimes? Use it all the time without question!
Yeah, you need to have experiences with the intermediate architecture sizes and need enough information about the concrete use-case, to be able to deliberate something that's not an extreme. Both of those are a rarity with programming...
I do microclouds in the service.
BaaS (Bong as a Service).
Neither will the trendy new language, distro, or standard
perl 5.10 for life!
Python, which I hate the syntax of with an actual passion, legit offers more library support though, so is this a lost cause at this point? Especially with junior devs, who to the extent they think they know how to program at all, do so in (well, JavaScript mainly iirc, but afa back-end specifically) Python?:-(
As a Perl dev, I wouldn't recommend it at all at this point.
20 years ago, it had the best publicly available repository of libraries with CPAN. That's been long surpassed now.
10 years ago, it still had a fantastic community of highly concentrated competence. A lot of those people are gone, and the ones left behind are some of the more toxic ones.
It's going to stay a long tail language like COBOL where it never really dies. If you have experience in it, you can make a lot of money at it, and will for a long time to come, but it's hard to break into.
My company is moving towards Elixir, which I like a lot. Realistically, I'm at least 20 years from retirement, and I expect the Perl platform to be around in some capacity by then. I might even be the one to shut the final lights off on it as I walk out the door.
The syntax of Perl seems superior to me, though partly b/c I just like the style of semi-colons and braces as in C++, and also so that you can edit it in any text editor you choose, not just those IDEs or ones that will show you the difference between a tab and some spaces.
But mostly perhaps b/c I have not invested any efforts into actually learning Python the same way that I did Perl - that O'Reily book that explained, from the perspective of the literal creator, why things work in Perl as they do, was a fantastic read!
The Grim Perl Reaper?
Sure they do. They just come with exciting, new problems
Sometimes a change is as good as a rest
'Nailing down the definition of a story point to "1 developer day" oughta do it '
Tbh mostly microservices solves two issues for me:
- You can scale resource-heavy operations without an impact of scaling everything else.
- You kind of βforceβ people to keep things contained, instead of making everything interdependant. Which helps containing issues with updates to certain functionality to only have an impact on that functionality.
You could do #2 in a βmonolithicβ setup as well (by doing modules or libraries or something), it just never works out that way in practice
Let's say there is a user lmicroservice. I'm on a UI team. I don't get to tell the user service team what, or when, to implement any features.
I'm tasked with making a page displaying all the users who have a birthday this month.
User API service can only search by user id, email, display name, or nickname.
Now instead of just querying the goddamn database, a one line fucking SQL statement, I have to deal with the user team, getting them to first off even admit that my use case is valid, convince them to work on the feature, coordinate with them to make sure the query works, sorts the data the way I need, etc, et. al, blah blah blah.
They already have the next 3 sprints full so I'm sitting on my ass for the next month before I can test.
Meanwhile they decide they're gonna implement a super generic thing, and so despite me working on code that we talked about using an interface we talked about, they implement something else so i have to throw out half my work anyway.
Then when I finally start using it I find, oh, it doesn't support a sort, only returns 100 results max with no pagination, so if there's 200 this month with a birthday fuck the 2nd hundred they don't show up because they're implementing bare minimum and the rest is slated for another sprint.
And it was then, your Honor, I grabbed the lead dev for the user microservice and tossed him off the 9th story of the building.
/sarcasm
Now instead of just querying the goddamn database, a one line fucking SQL statement, I have to deal with the user team
Exactly, you understand very well the purpose of microservices. You can submit a patch if you need that feature now.
Funnily enough I'm the technical lead of the team that handles the user service in an insurance company.
Due to direct access to our data without consulting us, we're getting legal issues as people were using addresses to guess where people lived instead of using our endpoints.
I guess some people really hate the validation that service layers have.
I know you wrote /s, but this has basically nothing to do with the tech of microservices, and more to do with internal politics.
Switch the βuser microserviceβ to βbirth date is not indexed in the database and i have to reach out to the database handling teamβ and you are in the same situation
True, but the microservice concept was introduced to perform a kind of reverse-Conway Manoeuvre and make the architecture fit the team topology. Whether this has ever worked is still unclear to me, but Iβve seen it not work a few times now.
In a lot of cases microservices will add to your development problems.
Imo they do not add problems, but they do exchange some problems for other problems.
In some cases it is just a net negative, especially if you have a bunch of services are using the same db tables which act as the global state.
Neither will the YAML
DEFINITELY not YAML.
Yelling at my laptop
XML: Xtremely Masochistic Language
Another scroll of truth:
Without all of these stupid fads, which are designed first and foremost to market enterprise crapware and consultancy, we'd have far less work to do and far fewer employment opportunities.
Nyeeeh!
Neither will containers
The real win is encapsulation. Whether that's many modules running on the same server or many is not where the juice is
B-b-but the salesperson said that i-i-it...
Fax