Microservices are a great way to promote cloud vendors' offerings and complicate IT life with over-engineered "standards" like Kubernetes.
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.
I'm working on an internal service that do not benefit being set up on kubernetes (it is basically a cronjob that runs everyday, collect data from every third party software, consolidate it and send it in a s3). It could be run on a small vm, deployed with ansible.
But i understand why, for streamligning purpose, we use kubernetes. It makes the networking "easier", and i feel it integrate better with other CI/CD tools than ansible. It is only a feeling since the ansible version i used to use was quite old, so i might be wrong.
I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.
I'd love to see more of these "you don't need microservices' type of articles be more prescriptive on when you might need them. 20 product scrum teams? 10 different team? Certain functional team separate (like you have a data infra team, search, payment processing)?
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.
I worked on a SOA setup and we hit the inflection point somewhere around 50-100 devs contributing code to the service. Honestly, we should have taken splitting up the service more seriously earlier.
I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”
Most of the real world "microservices" usage outside of FAANG has been to legitimize polyglot development (a net negative for most organizations) and the to create heretofore unseen levels of Conway's law. A microservice per person? Sure, why not?
It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service. Most groups I've talked to don't even have a good answer to "why is this in a separate service from that?" when asked, and I've talked to a lot of them.
That wasn't the argument that was being made. Do you have commentary on the content of the article, or just that you don't like that he had a non-party line opinion?
Yep because it is true. Microservices is just the latest "Silver Bullet" that inexperienced developers think will save themselves from doing bad work. The reality is that microservices is inherently more complex than monoliths. So the more you can discourage developers from making that mistake the better.
Which is a good thing, since microservices were way overhyped from the beginning. Now bashing too hard wouldn't be good either, but fortunately, the organizations that need it will be technologically mature enough to be able to ignore the current hype.
Whereas when microservices were overhyped, they were introduced into orgs/companies that didn't have the brain power/experience to implement these properly or just to be able to say an informed no.
A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X".
And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"
Some people will make an incoherent mess out of anything.
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.
One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads.
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.
Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic.
Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
Firmly disagree. Microservices get you very little in terms of code quality enforcement past what you would get with a well modularized monolith, and they introduce a lot of code quality & architectural pitfalls. I think going microservices to enforce boundaries and decoupling is a very bad idea that will create far more trouble than its worth. I'd be a lot more scared of my junior devs committing code to microservices than to a decently organized monolith.
I would only seriously consider a move to microservices for deployment/perf reasons.
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.
Code quality is only one reason to use microservices; deployment frequency is another (you want people to be able to deploy their service without needing to coordinate with every other service in the system).
Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).
Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.
Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.
I love the idea of "managing junior level programmers who don't know how to make loosely coupling architecture" as describing engineering leadership, regardless of how cynical it is.
I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"
Adding in a machine boundary does not guarantee loose coupling. If a dev does not have the skills to make a loosely coupled monolith, how they can they suddenly have the skills to make a collection of loosely coupled services running on more machines? That same low skilled dev is going to have to deal with a lot of other complexities now...
I would think that junior level developers are usually walking into an architecture put together by leads/seniors? Juniors should be coming into a well-architected monolith that they can be productive in, if they can’t that’s kinda on the senior staff…
I have 15+ years of management experience and I have never ever had a problem managing developers at all skill level. You can't solve management issues with technology. You solve it with people skills. I sincerely hope you are not and have never been a manager. There are already enough arrogant and incompetent managers out there.
That makes a lot of sense when you have real team (and most importantly) process boundaries. Isolate the code and deployment aligned with your team and process boundaries.
But if you're a company of 10-20 people all pretty much working on the same code? Microservices just adds complexity and overhead. Deployment, telemetry, documentation, version synchronization, tracing -- everything becomes more complex when you start creating boundaries between sub parts of your system.
For me, microservices are about boundaries. The question is what benefit that boundary provides for the team. For large companies where there are many discrete teams following different processes and release cadences, microservices might be worth the overhead. For small companies, it is wasted effort.
> 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.
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.
Self-promoting a little utility I wrote that helps guide teams on whether your service boundary is a good idea: https://mulch.dev/service-scorecard/
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.
Why the monolith should remain the default choice for new, small, and medium-sized engineering teams. Considering how we can leverage the monolith to realize the benefits that microservices claim for themselves.
You got to love the balant disregard for alternative architectures where this article has to advocate for monoliths again.
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.
I 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 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!
The problem I find with these plugin serverless is that they rarely work well. Even with a framework produced by Chalice, there are issues that are largely so minor in detail but required to work well with AWS. Often they are not even code related but infrastructure.
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.
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 13 stock exchanges in heavily regulated Asia, trading $bn a day - it kinda has to work day after day and "the risk" of deploying "the whole" think more than once a quarter was terrifying.
Well a few better tests and a bit of bravery and now I just do "the full redeployment" whenever I want. Some teeth are still grinding but what can I say, we still banking lol, and now when we find a bug, we don't wait for months to fix it.
Isn't the devil in the details? Some problems are solved better as Microservices. Some problems are solved better as monoliths. Ultimately it is the lack of maintaining the solution we choose that leads to the "grass is greener" fad chase.
While I agree that there are definitely some cautionary tales regarding microservices, consistent and autonomous delivery across many teams with a complex monolith is equally if not more difficult than some of the cons that come with microservices.
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".
Nope. Each team is responsible for a library. The monolith is composed by combining those libraries into a single application. It gives you all the benefits without the disadvantages (no encode/decode/network latency, easy rollback, easy transactions management etc. etc. etc.)
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.
I don’t know if you will need microservices or not. I can tell you that many developers and teams will do microservices poorly and will not get an advantage out of it and will have an even more complex ball of mud to maintain.
I’m working in a team right now that went through “CV driven development” with no oversight and has Django + micro services. One of them was written in Go, despite only one person knowing that language. The rest are a mess of unreliability - I found recently one of the services polls the main application’s internal API, and the script cuts off after 10 minutes of runtime and a new ECS container is launched. Why cron wasn’t preferable to this I will never know?!
We have something like 19 different components. Insane.
[+] [-] hericium|3 years ago|reply
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.
[+] [-] orwin|3 years ago|reply
But i understand why, for streamligning purpose, we use kubernetes. It makes the networking "easier", and i feel it integrate better with other CI/CD tools than ansible. It is only a feeling since the ansible version i used to use was quite old, so i might be wrong.
[+] [-] DoneWithAllThat|3 years ago|reply
[+] [-] taude|3 years ago|reply
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.
[+] [-] Sevii|3 years ago|reply
[+] [-] blowski|3 years ago|reply
[+] [-] foobiekr|3 years ago|reply
It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service. Most groups I've talked to don't even have a good answer to "why is this in a separate service from that?" when asked, and I've talked to a lot of them.
[+] [-] monksy|3 years ago|reply
[+] [-] tomlin|3 years ago|reply
[+] [-] jnash|3 years ago|reply
[+] [-] atleta|3 years ago|reply
Whereas when microservices were overhyped, they were introduced into orgs/companies that didn't have the brain power/experience to implement these properly or just to be able to say an informed no.
[+] [-] dfbsdfbwe2ef2e|3 years ago|reply
A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X".
And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"
[+] [-] kristopolous|3 years ago|reply
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.
[+] [-] jsargiot|3 years ago|reply
[+] [-] johnthescott|3 years ago|reply
[+] [-] softwarebeware|3 years ago|reply
The power of a concept isn't in the need but in how well it optimizes the process.
[+] [-] api|3 years ago|reply
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.
[+] [-] revskill|3 years ago|reply
Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
[+] [-] tomtheelder|3 years ago|reply
I would only seriously consider a move to microservices for deployment/perf reasons.
[+] [-] vasergen|3 years ago|reply
[+] [-] throwaway894345|3 years ago|reply
Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).
Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.
Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.
[+] [-] msaspence|3 years ago|reply
I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"
[+] [-] ripberge|3 years ago|reply
[+] [-] awinder|3 years ago|reply
[+] [-] jnash|3 years ago|reply
[+] [-] goncalo-r|3 years ago|reply
[+] [-] CharlieDigital|3 years ago|reply
But if you're a company of 10-20 people all pretty much working on the same code? Microservices just adds complexity and overhead. Deployment, telemetry, documentation, version synchronization, tracing -- everything becomes more complex when you start creating boundaries between sub parts of your system.
For me, microservices are about boundaries. The question is what benefit that boundary provides for the team. For large companies where there are many discrete teams following different processes and release cadences, microservices might be worth the overhead. For small companies, it is wasted effort.
[+] [-] goodoldneon|3 years ago|reply
[+] [-] tlonny|3 years ago|reply
Breaking up an app into microservices is total overkill in this instance...
[+] [-] steinuil|3 years ago|reply
> 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.
[+] [-] 40acres|3 years ago|reply
[+] [-] akoumjian|3 years ago|reply
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.
[+] [-] msaspence|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] monksy|3 years ago|reply
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.
[+] [-] seibelj|3 years ago|reply
And this is why micro-services are poor architecture. If you need an entire service for every DB activity you are in for a terrible time.
[+] [-] aarondf|3 years ago|reply
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!
[1] https://github.com/hammerstonedev/sidecar
[+] [-] upupandup|3 years ago|reply
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.
[+] [-] pmelendez|3 years ago|reply
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.
[+] [-] xwolfi|3 years ago|reply
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 13 stock exchanges in heavily regulated Asia, trading $bn a day - it kinda has to work day after day and "the risk" of deploying "the whole" think more than once a quarter was terrifying.
Well a few better tests and a bit of bravery and now I just do "the full redeployment" whenever I want. Some teeth are still grinding but what can I say, we still banking lol, and now when we find a bug, we don't wait for months to fix it.
[+] [-] hatware|3 years ago|reply
[+] [-] jnash|3 years ago|reply
[+] [-] darrmit|3 years ago|reply
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".
[+] [-] jnash|3 years ago|reply
[+] [-] Rochus|3 years ago|reply
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.
[+] [-] lasereyes136|3 years ago|reply
[+] [-] declnz|3 years ago|reply
I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X
[+] [-] physicsguy|3 years ago|reply
We have something like 19 different components. Insane.