by msaspence on 7/27/22, 2:22 PM with 165 comments
by hericium on 7/27/22, 2:54 PM
Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.
by DoneWithAllThat on 7/27/22, 3:26 PM
by taude on 7/27/22, 3:11 PM
I always can't help but to think most of these articles are written by engineers working at 30 people startups or something. And there's definitely a lot of org-size and structure between the startup and a faang-sized tech giant.
by blowski on 7/27/22, 3:29 PM
by kristopolous on 7/27/22, 4:18 PM
A garbled knot of interdependent microservices with timing issues, bad extensibility, and unpredictable flow.
An ornate matroyshka set of wrapper functions calling each other spreading over multiple directories making any modification a large error prone effort.
Event systems, probably multiple, without any real difference between just a function call other than your debugger getting very confused by it.
Database schemas with table names that exude the narcissism of small differences with nitpicky rules that make it explode if any flexibility is demanded
Aws bill that's 10x more than any reasonable expectation given the problem set.
An object oriented design that looks like some kind of fetishized exercise of every feature possible, where defects cascade to action at a distance and unintended consequences with tight coupling that can't be extricated leading to a rewrite, just like it did last time
They are the people who create the waterfall of dozens of levels of div tags for no functional reason other than to accommodate their incompetency
They are the ones that want to pollute your entire day with needless meetings over irrelevant things that will not be acted upon.
Of course there's no useful comments or tests or documentation. The git comment messages are single words like "fix" and "rewrite". There's no versions in the deploy or a reasonable approach to logging that allows a successful audit and the thing is too state dependent to reproduce bugs.
Then there's dependencies, loads of them just picked seemingly at random, written by people who think like them with the same disregard for documentation, compatibility or testing. But they have very pretty websites which says they're painless, simple and easy, so I guess it's all ok right?
The problem with microservices is the same problem with anything else and changing paradigms won't fix it. The approach needs to change, not the technique. It's a different kind of budo.
by softwarebeware on 7/27/22, 3:19 PM
The power of a concept isn't in the need but in how well it optimizes the process.
by api on 7/27/22, 3:03 PM
Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad.
Other major classes of fads are: consultant self promotion fads, re-invention fads of all kinds in which devs speed run the history of some aspect of computing to arrive at the same place, magic pixie dust fads where sprinkling some buzzword on things makes everything better, management "methodology" panacea fads, etc.
Avoiding fads is a superpower. It tends to save a whole lot of money and wasted time.
The test of whether something is a fad is whether it reduces incidental complexity, enables something categorically new, or genuinely boosts developer velocity.
Incidental complexity is the complexity that creeps into our designs that is not essential to the problem but an artifact of how we got there or some prior limitation in how things are done. A genuine innovation will make incidental complexity actually go away, but not by pretending that essential complexity doesn't exist.
A categorically new thing would be e.g. deep learning or an actually practical and useful provably-safe language (Rust).
Boosting developer velocity means actually speeding up time to ship without doing so by adding a ton of technical debt or making the product suck.
If something doesn't do at least one of those things well, it's a fad.
by revskill on 7/27/22, 2:57 PM
Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
by goncalo-r on 7/27/22, 2:44 PM
by akoumjian on 7/27/22, 3:35 PM
The service scorecard asks a bunch of reflective questions about the ramifications of making some set of functions a unique service and points its benefits or lack thereof on a scale.
by msaspence on 7/27/22, 2:22 PM
by monksy on 7/27/22, 3:40 PM
You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to it.
Think about streaming data systems. These allow for multiple components connecting to durable queues (with maintence polices) that will process data and pass it along. This is more for data that may take longer, and shouldn't be done in the same request.
Slight personal rant: The crap that I've seen people expect of microservices to do in a request is excessive. (If you're doing more than taking a request, reading+writting into a database.. you're doing too much and your performance is terrible) Additionally there is very little consideration about what happens when a microservice performs badly.
by aarondf on 7/27/22, 2:53 PM
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 to own.
So if you need a single Node, Python, or Ruby function you can put just that part on Lambda and still call it from Laravel as if it were a native PHP function. No API gateway or anything to muck about with, either.
Is it a true microservice? Not really, although who knows what that actually means. It does allow you to take advantage of some parts of microservices without the pain though!
by pmelendez on 7/27/22, 2:51 PM
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.
by hatware on 7/27/22, 3:10 PM
by darrmit on 7/27/22, 2:49 PM
I don't think the answer is as easy as "you don't need microservices". I think the answer is "you can effectively use both".
by Rochus on 7/27/22, 2:55 PM
Monolith is an unfortunate term by which everyone seems to mean something different. So is any application whose parts do not communicate via network interfaces a "monolith"? Is an application where the majority of the function calls are not realized as a series of network transactions (like CORBA at that time) a less good application than one where different classes and modules on the same machine communicate directly with each other?
We should stop using the term, nor assigning blanket value attributes to it. "Monolyth" is not the antonym to "Microservices", as suggested by the article. From a certain distance, every system looks like a monolith; that has more to do with the viewer than the system.
by lasereyes136 on 7/28/22, 12:54 AM
by declnz on 7/27/22, 5:39 PM
I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X
by physicsguy on 7/28/22, 5:36 AM
We have something like 19 different components. Insane.
by mbrodersen on 7/28/22, 1:26 AM
by chaoz_ on 7/27/22, 3:03 PM
Yes, but it also comes with a cost. Microservices might still fail in a cascade manner and bringing such system up under significant load is even more challenging.
by JLuterek on 7/27/22, 3:31 PM
by ReflectedImage on 7/28/22, 12:22 AM
You can just shoot a couple of the offending microservices dead and replace them with better implemented versions.
[Assuming there are at least 6 developers]
by jmartrican on 7/27/22, 3:09 PM
by threesquared on 7/28/22, 4:03 AM
by drewcoo on 7/27/22, 3:33 PM
by wintorez on 7/27/22, 2:54 PM
by NHQ on 7/27/22, 3:47 PM
by EGreg on 7/27/22, 3:39 PM
The main problem isn't microservices, it's control and interoperability. Facebook decides it wants to turn into TikTok? Too bad for all its users, it'll happen. "Relax, breathe, we hear you" is what Zuck said to all his outraged users after the first big rollout of newsfeed. Then a lot of scandals later (beacon, etc.) they are still at it. Google sunset Reader just like that. People are HOPING that Elon Musk adds a feature to Twitter. This is crazy.
Host stuff yourself, and not in the cloud. And for that, we need people to be able to "just install" something, like a Wordpress 5 min install on a hosting company.
I don't want to make this comment long, so anyone who wants to read the full thesis can see it here: https://qbix.com/blog/2021/01/15/open-source-communities/
by ehutch79 on 7/27/22, 5:57 PM
by RickJWagner on 7/28/22, 11:48 AM
by mesozoic on 7/27/22, 8:44 PM
by mountainriver on 7/27/22, 7:49 PM