13 ms·

You Don't Need Microservices

113 points by msaspence 4y ago

msaspence 4y ago
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.
- deleted 4y ago
  [deleted]
goncalo-r 4y ago
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
- goodoldneon 4y ago
  Yea. IMO, microservices are usually more of an organizational solution than a technical solution
  - __alexs 4y ago
    IMO software is usually more of an organisational solution than a technical solution.
  - jnash 4y ago
    Libraries can do the exact same thing. And it is a less complex solution.
- CharlieDigital 4y ago
  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.
  - __alexs 4y ago
    Sometimes boundaries are good. Not all things should be easy. The question is which things need to be easy, and which things need to be hard? Often the answer is "we don't know" but there is still an optimal answer to the question.
- 40acres 4y ago
  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.
  - jacquesm 4y ago
    For the bulk of the smaller companies the monolith is an excellent choice. For a smaller number of them decomposition of that monolith into a few (< 10 and usually < 5) services makes good sense. Typically the kind of project you are working on will suggest nice 'cut here' lines and if it does not then you're going to have to be a bit more creative. You could try going by entities or by processes or by large chunks of the project accessed by different people. And then there are projects that grow way beyond the point where even that will keep them manageable, in which case microservices may well make sense. But the number of companies faced with challenges at that level is quite small relative to the total and the chances that you find yourself in one of those if you don't have a few hundred co-workers as developer is very small.
- tlonny 4y ago
  This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...
  - foobarian 4y ago
    When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?
    - XorNot 4y ago
      In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much. You're not Google, you don't have this problem.
      - foobarian 4y ago
        Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
  - kkapelon 4y ago
    This doesn't cover independent deployments. Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.
    - tlonny 4y ago
      I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app. One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices. Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...
- steinuil 4y ago
  This reminds me a lot of Conway's law: > 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.
darrmit 4y ago
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".
- jnash 4y ago
  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.)
pmelendez 4y ago
>Modularize Your Monolith 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 4y ago
  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.
  - pmelendez 4y ago
    >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. YMMV but I do have personal experience where the risks weren't psychological. Teams stepping into each other shoes and broken each other features are a real problem, solved by communication but that overhead has real costs.
  - jnash 4y ago
    Jane Street using monoliths to manage $bn of trades a day and millions of transactions per second. So nothing you say makes microservices necessary.
aarondf 4y ago
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! [1] https://github.com/hammerstonedev/sidecar https://github.com/hammerstonedev/sidecar
- upupandup 4y ago
  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.
  - aarondf 4y ago
    > IMHO, AWS Chalice remains the goto method to generate REST API serverless manner Sidecar (my library) provides no REST API. You just... call the function from PHP. So you'd call it like <?php MyNeatServerlessFunction::execute(['foo' => 'bar']); And that would run the function _on Lambda._ Whether that function is JS, Ruby, Python, whatever. With Sidecar, you never have to configure anything in the AWS console, besides the initial IAM configuration. You give Sidecar admin keys, it configures all the permissions, roles, etc, and then self-destructs the admin keys. So you don't have to muck around with anything at all. > also curious how yours also differ from the paid Laravel solution that lets you deploy your stack serverless. Sidecar deploys and executes _non-PHP_ functions from your Laravel app. So it's completely different. Vapor deploys your whole app and runs it on Lambda, I just deploy single functions at a time.
hericium 4y ago
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.
- orwin 4y ago
  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.
  - hericium 4y ago
    Sounds reasonable. Personally, I just try to stay away from k8s until it becomes a requirement. Until then simplest tools are often a good choice for building systems that require less maintenance. That's a per-project decision though. You do not need Ansible for VMs provisioning - you can bake a VM image that will pull repos and do other preparation stuff. HashiCorp Packer[1] is an good tool for this imo. This applies to bare metal, too, as you can bake ISO or IMG the same way. Stuff that differentiates those systems can be set up with cloud-init or something similar. Regarding Ansible, it didn't changed much over the years. At least nothing really major like statefulness. But again, I'm not opposite to using Ansible when a project reasonably calls for it. Proper tool for configuring multiple systems with details generated for/by other systems, say multi-cloud HA provisions, clustering etc. [1] https://www.packer.io/ https://www.packer.io/
wintorez 4y ago
Also, You Don't Need Micro-frontends.
Rochus 4y ago
The article represents a reasonable position. 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.
revskill 4y ago
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
- vasergen 4y ago
  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.
  - mirekrusin 4y ago
    Why micro-?
  - jacquesm 4y ago
    Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
    - foobarian 4y ago
      I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."
      - allendoerfer 4y ago
        > I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker." I know you are referring to something else, but it actually means that the battle is won.
api 4y ago
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.
- msaspence 4y ago
  > "move stuff around and complexity will magically go away" fallacy This is a great description of microservices
- tomtheelder 4y ago
  Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit. In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and allow more consistent and less risky deployments. There are certainly costs: infrastructural complexity, a new network boundary between services, increased risk of techincal/product drift. For orgs where the benefits outweigh the costs, due to scale/org structure/perf concerns/etc it can be an enormous win for velocity. For other orgs it can be a huge velocity killer. It just depends.
chaoz_ 4y ago
> Fault Isolation > The ability for a single feature of your application to go down without taking the rest down with it is a big bonus of a properly designed microservices architecture. 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.
- sorokod 4y ago
  Also known as "multiple points of multiple failures".
jmartrican 4y ago
Is this analogous to saying "you dont need TDD cause you can always write your tests after the code is written"? Or "you dont need encapsulation because you can just ignore the parts of the code you should not be touching"?
hatware 4y ago
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.
- jnash 4y ago
  What problems are solved better with microservices? Serious question.
taude 4y ago
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.
- Sevii 4y ago
  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.
softwarebeware 4y ago
"You don't need" anything. You can walk to New York from San Francisco. But of course you'd rather fly. You may settle for driving. The power of a concept isn't in the need but in how well it optimizes the process.
DoneWithAllThat 4y ago
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.
- honkycat 4y ago
  There are a lot of small shops who aren't dealing with scale, and assume that what works for them works for everyone. Personally, I think micro-services should be approached very carefully but I understand the idea of them.
  - jnash 4y ago
    Companies like Jane Street use Monoliths to handle millions of transactions per second. How many transactions per second do you have?
- DJBunnies 4y ago
  I think that all the time. Or more specifically, "I wish these services were a monolith so we could have better type checks/easier logging/debugging."
  - bluefirebrand 4y ago
    "I wish these services were a monolith so there was any amount of discoverability at all, and I don't have to beg for time from busy people on other teams to help me use their undocumented APIs"
    - arinlen 4y ago
      > I wish these services were a monolith so there was any amount of discoverability at all, Why do you conflate microservices with discoverability? What's wrong with simply calling a web service? > (...) and I don't have to beg for time from busy people on other teams to help me use their undocumented APIs And you believe that the same hypothetical team you claim doesn't document their API would all of a sudden documented all its internal?
blowski 4y ago
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?!”
- monksy 4y ago
  They're irrationally thrown up there as a silver bullet and people are heavily criticised when people suggest non-monolith+microservice alternatives.
- dfbsdfbwe2ef2e 4y ago
  That's true for all ideas. 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!"
  - blowski 4y ago
    I’d argue that’s being contrarian - taking an opposing stance just for attention seeking. This is more like “the trough of disillusionment” on the hype cycle. You’ve suffered so much at the hands of microservices, you want to convince everyone else not to use them. Lots of others have suffered similarly, so thanks to confirmation bias, your post gets lots of likes based on the sentiment.
  - nailer 4y ago
    That haven’t tested the vaccines. That’s why there’s emergency use laws.
- tomlin 4y ago
  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?
  - 4y ago
JLuterek 4y ago
You are probably correct for small to medium sized tech teams building software. With that said, in 2022 I'd expect any company selling a SaaS product to be built with micro-services. Buying a SaaS I want all of the benefits, but no longer need to deal with the hard parts.
- jnash 4y ago
  Nope. 95% of SaaS products out there use monoliths not microservices. For good reasons.
drewcoo 4y ago
Was there historically so much resistance to other forms of loose coupling and high cohesion? Maybe from the anti-OOP crowd when OOP was first catching on?
- nailer 4y ago
  OOP was a tight coupling between state and functions.
- jnash 4y ago
  Microservices can most definitely be tightly coupled. The same way that most OOP code I have seen is a spiderweb of tight dependencies. I bet that code you think is loosely coupled probably isn't. Most developers have no clue what "loosely coupled" actually means.
akoumjian 4y ago
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/ 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.
EGreg 4y ago
As someone who has built a monolith, full-stack (literally everything from MySQL to PHP+Node.js to the Web to Cordova) platform at https://qbix.com/platform https://qbix.com/platform I can still tell you, that microservices are great. But the average person isn't going to fine-tune all those microservices. They need to install something that just works out of the box. An expert can be hired to fine-tune some parts of the stack (e.g. add a CDN or varnish cache) and not others. The layers (e.g. database, file system) already are separated and cloud services like Amazon can even scale them automatically (e.g. Aurora or Lambda). 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/ https://qbix.com/blog/2021/01/15/open-source-communities/
- jnash 4y ago
  Nothing magically makes microservices good or bad. Nothing magically makes monoliths good or bad. It all depends on how good the developers are. However it is objectively a fact that microservides are inherently more complex than monoliths. You basically take a monolith and add encode/decoding, network latency delays, no global commits, potential timing issues, partly-failed system scenarios, new types of distributed error conditions etc. to the mix. So there is zero upside to using microservices IMHO.
magwa101 4y ago
monksy 4y ago
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.
- seibelj 4y ago
  > If you're doing more than taking a request, reading+writting into a database.. you're doing too much 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.
  - throwaway894345 4y ago
    It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)
    - seibelj 4y ago
      Yes let's make every function call its own service with monitoring, a database, the network stack, management, and so on and then enjoy wonderful performance and easy management
      - throwaway894345 4y ago
NHQ 4y ago
You don't medium dot com either.
kristopolous 4y ago
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.
- johnthescott 4y ago
  bravo
- jsargiot 4y ago
  Amen!
declnz 4y ago
> Odds are it is easier to resolve performance issues and bottlenecks in your monolith than it is to transition to a new architecture pattern. I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X
ehutch79 4y ago
I just read yesterday, that not only does my blog need microservices, it needs microfrontends.
mountainriver 4y ago
Just write regular sized services, we don’t need to all live on the edge
mesozoic 4y ago
I don't know who these articles are written for (having read this one in a dozen variations) Sure I agree they're not always the right solution but do you think you're going to convince someone who thinks they are at some small company from trying to roll them out?
ReflectedImage 4y ago
You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc.. 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]
- kordlessagain 4y ago
  That’s the story for them. I also think it’s possible to do this with code for APIs in different files.
- jnash 4y ago
  Thousands of developers use libraries and not microservices to implement Linux and Windows. If they can do it so can you. So no that is not correct.
lasereyes136 4y ago
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.
mbrodersen 4y ago
You have a problem. So you choose Microservices. Now you have N distributed problems and a system that is K times slower. Well done.
threesquared 4y ago
But honestly what do you do when your application monolith outgrows its relational database. This seems to be the main reason to split concerns into their own services. Relational DBs don't scale horizontally.
physicsguy 4y ago
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.
RickJWagner 4y ago
Wow. The pendulum has been going back and forth on this one for a long time.

113 points by msaspence 4y ago

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.

deleted 4y ago
[deleted]

goncalo-r 4y ago

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

goodoldneon 4y ago
Yea. IMO, microservices are usually more of an organizational solution than a technical solution
- __alexs 4y ago
  IMO software is usually more of an organisational solution than a technical solution.
- jnash 4y ago
  Libraries can do the exact same thing. And it is a less complex solution.
CharlieDigital 4y ago
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.
- __alexs 4y ago
  Sometimes boundaries are good. Not all things should be easy. The question is which things need to be easy, and which things need to be hard? Often the answer is "we don't know" but there is still an optimal answer to the question.
40acres 4y ago
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.
- jacquesm 4y ago
  For the bulk of the smaller companies the monolith is an excellent choice. For a smaller number of them decomposition of that monolith into a few (< 10 and usually < 5) services makes good sense. Typically the kind of project you are working on will suggest nice 'cut here' lines and if it does not then you're going to have to be a bit more creative. You could try going by entities or by processes or by large chunks of the project accessed by different people. And then there are projects that grow way beyond the point where even that will keep them manageable, in which case microservices may well make sense. But the number of companies faced with challenges at that level is quite small relative to the total and the chances that you find yourself in one of those if you don't have a few hundred co-workers as developer is very small.
tlonny 4y ago
This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...
- foobarian 4y ago
  When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?
  - XorNot 4y ago
    In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much. You're not Google, you don't have this problem.
    - foobarian 4y ago
      Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
- kkapelon 4y ago
  This doesn't cover independent deployments. Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.
  - tlonny 4y ago
    I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app. One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices. Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...
steinuil 4y ago
This reminds me a lot of Conway's law: > 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.

darrmit 4y ago

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".

jnash 4y ago
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.)

pmelendez 4y ago

>Modularize Your Monolith 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 4y ago
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.
- pmelendez 4y ago
  >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. YMMV but I do have personal experience where the risks weren't psychological. Teams stepping into each other shoes and broken each other features are a real problem, solved by communication but that overhead has real costs.
- jnash 4y ago
  Jane Street using monoliths to manage $bn of trades a day and millions of transactions per second. So nothing you say makes microservices necessary.

aarondf 4y ago

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! [1] https://github.com/hammerstonedev/sidecar https://github.com/hammerstonedev/sidecar

upupandup 4y ago
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.
- aarondf 4y ago
  > IMHO, AWS Chalice remains the goto method to generate REST API serverless manner Sidecar (my library) provides no REST API. You just... call the function from PHP. So you'd call it like <?php MyNeatServerlessFunction::execute(['foo' => 'bar']); And that would run the function _on Lambda._ Whether that function is JS, Ruby, Python, whatever. With Sidecar, you never have to configure anything in the AWS console, besides the initial IAM configuration. You give Sidecar admin keys, it configures all the permissions, roles, etc, and then self-destructs the admin keys. So you don't have to muck around with anything at all. > also curious how yours also differ from the paid Laravel solution that lets you deploy your stack serverless. Sidecar deploys and executes _non-PHP_ functions from your Laravel app. So it's completely different. Vapor deploys your whole app and runs it on Lambda, I just deploy single functions at a time.

hericium 4y ago

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.

orwin 4y ago
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.
- hericium 4y ago
  Sounds reasonable. Personally, I just try to stay away from k8s until it becomes a requirement. Until then simplest tools are often a good choice for building systems that require less maintenance. That's a per-project decision though. You do not need Ansible for VMs provisioning - you can bake a VM image that will pull repos and do other preparation stuff. HashiCorp Packer[1] is an good tool for this imo. This applies to bare metal, too, as you can bake ISO or IMG the same way. Stuff that differentiates those systems can be set up with cloud-init or something similar. Regarding Ansible, it didn't changed much over the years. At least nothing really major like statefulness. But again, I'm not opposite to using Ansible when a project reasonably calls for it. Proper tool for configuring multiple systems with details generated for/by other systems, say multi-cloud HA provisions, clustering etc. [1] https://www.packer.io/ https://www.packer.io/

wintorez 4y ago

Also, You Don't Need Micro-frontends.

Rochus 4y ago

The article represents a reasonable position. 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.

revskill 4y ago

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

vasergen 4y ago
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.
- mirekrusin 4y ago
  Why micro-?
- jacquesm 4y ago
  Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
  - foobarian 4y ago
    I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."
    - allendoerfer 4y ago
      > I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker." I know you are referring to something else, but it actually means that the battle is won.

api 4y ago

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.

msaspence 4y ago
> "move stuff around and complexity will magically go away" fallacy This is a great description of microservices
tomtheelder 4y ago
Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit. In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and allow more consistent and less risky deployments. There are certainly costs: infrastructural complexity, a new network boundary between services, increased risk of techincal/product drift. For orgs where the benefits outweigh the costs, due to scale/org structure/perf concerns/etc it can be an enormous win for velocity. For other orgs it can be a huge velocity killer. It just depends.

chaoz_ 4y ago

> Fault Isolation > The ability for a single feature of your application to go down without taking the rest down with it is a big bonus of a properly designed microservices architecture. 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.

sorokod 4y ago
Also known as "multiple points of multiple failures".

jmartrican 4y ago

Is this analogous to saying "you dont need TDD cause you can always write your tests after the code is written"? Or "you dont need encapsulation because you can just ignore the parts of the code you should not be touching"?

hatware 4y ago

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.

jnash 4y ago
What problems are solved better with microservices? Serious question.

taude 4y ago

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.

Sevii 4y ago
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.

softwarebeware 4y ago

"You don't need" anything. You can walk to New York from San Francisco. But of course you'd rather fly. You may settle for driving. The power of a concept isn't in the need but in how well it optimizes the process.

DoneWithAllThat 4y ago

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.

honkycat 4y ago
There are a lot of small shops who aren't dealing with scale, and assume that what works for them works for everyone. Personally, I think micro-services should be approached very carefully but I understand the idea of them.
- jnash 4y ago
  Companies like Jane Street use Monoliths to handle millions of transactions per second. How many transactions per second do you have?
DJBunnies 4y ago
I think that all the time. Or more specifically, "I wish these services were a monolith so we could have better type checks/easier logging/debugging."
- bluefirebrand 4y ago
  "I wish these services were a monolith so there was any amount of discoverability at all, and I don't have to beg for time from busy people on other teams to help me use their undocumented APIs"
  - arinlen 4y ago
    > I wish these services were a monolith so there was any amount of discoverability at all, Why do you conflate microservices with discoverability? What's wrong with simply calling a web service? > (...) and I don't have to beg for time from busy people on other teams to help me use their undocumented APIs And you believe that the same hypothetical team you claim doesn't document their API would all of a sudden documented all its internal?

blowski 4y ago

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?!”

monksy 4y ago
They're irrationally thrown up there as a silver bullet and people are heavily criticised when people suggest non-monolith+microservice alternatives.
dfbsdfbwe2ef2e 4y ago
That's true for all ideas. 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!"
- blowski 4y ago
  I’d argue that’s being contrarian - taking an opposing stance just for attention seeking. This is more like “the trough of disillusionment” on the hype cycle. You’ve suffered so much at the hands of microservices, you want to convince everyone else not to use them. Lots of others have suffered similarly, so thanks to confirmation bias, your post gets lots of likes based on the sentiment.
- nailer 4y ago
  That haven’t tested the vaccines. That’s why there’s emergency use laws.
tomlin 4y ago
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?
- 4y ago

JLuterek 4y ago

You are probably correct for small to medium sized tech teams building software. With that said, in 2022 I'd expect any company selling a SaaS product to be built with micro-services. Buying a SaaS I want all of the benefits, but no longer need to deal with the hard parts.

jnash 4y ago
Nope. 95% of SaaS products out there use monoliths not microservices. For good reasons.

drewcoo 4y ago

Was there historically so much resistance to other forms of loose coupling and high cohesion? Maybe from the anti-OOP crowd when OOP was first catching on?

nailer 4y ago
OOP was a tight coupling between state and functions.
jnash 4y ago
Microservices can most definitely be tightly coupled. The same way that most OOP code I have seen is a spiderweb of tight dependencies. I bet that code you think is loosely coupled probably isn't. Most developers have no clue what "loosely coupled" actually means.

akoumjian 4y ago

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/ 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.

EGreg 4y ago

As someone who has built a monolith, full-stack (literally everything from MySQL to PHP+Node.js to the Web to Cordova) platform at https://qbix.com/platform https://qbix.com/platform I can still tell you, that microservices are great. But the average person isn't going to fine-tune all those microservices. They need to install something that just works out of the box. An expert can be hired to fine-tune some parts of the stack (e.g. add a CDN or varnish cache) and not others. The layers (e.g. database, file system) already are separated and cloud services like Amazon can even scale them automatically (e.g. Aurora or Lambda). 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/ https://qbix.com/blog/2021/01/15/open-source-communities/

jnash 4y ago
Nothing magically makes microservices good or bad. Nothing magically makes monoliths good or bad. It all depends on how good the developers are. However it is objectively a fact that microservides are inherently more complex than monoliths. You basically take a monolith and add encode/decoding, network latency delays, no global commits, potential timing issues, partly-failed system scenarios, new types of distributed error conditions etc. to the mix. So there is zero upside to using microservices IMHO.

magwa101 4y ago

monksy 4y ago

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.

seibelj 4y ago
> If you're doing more than taking a request, reading+writting into a database.. you're doing too much 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.
- throwaway894345 4y ago
  It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)
  - seibelj 4y ago
    Yes let's make every function call its own service with monitoring, a database, the network stack, management, and so on and then enjoy wonderful performance and easy management
    - throwaway894345 4y ago

NHQ 4y ago

You don't medium dot com either.

kristopolous 4y ago

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.

johnthescott 4y ago
bravo
jsargiot 4y ago
Amen!

declnz 4y ago

> Odds are it is easier to resolve performance issues and bottlenecks in your monolith than it is to transition to a new architecture pattern. I dunno but when I see odds are $X I read unproved and perhaps unprovably, my opinion is $X

ehutch79 4y ago

I just read yesterday, that not only does my blog need microservices, it needs microfrontends.

mountainriver 4y ago

Just write regular sized services, we don’t need to all live on the edge

mesozoic 4y ago

I don't know who these articles are written for (having read this one in a dozen variations) Sure I agree they're not always the right solution but do you think you're going to convince someone who thinks they are at some small company from trying to roll them out?

ReflectedImage 4y ago

You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc.. 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]

kordlessagain 4y ago
That’s the story for them. I also think it’s possible to do this with code for APIs in different files.
jnash 4y ago
Thousands of developers use libraries and not microservices to implement Linux and Windows. If they can do it so can you. So no that is not correct.

lasereyes136 4y ago

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.

mbrodersen 4y ago

You have a problem. So you choose Microservices. Now you have N distributed problems and a system that is K times slower. Well done.

threesquared 4y ago

But honestly what do you do when your application monolith outgrows its relational database. This seems to be the main reason to split concerns into their own services. Relational DBs don't scale horizontally.

physicsguy 4y ago

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.

RickJWagner 4y ago

Wow. The pendulum has been going back and forth on this one for a long time.