You Don't Need Microservices
medium.comMicroservices 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.
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.
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've seen the degenerate states of both extremes:
- a monolith with too many engineers contributing: no continuous deployment but rather "release day," which was a shitshow; said day was an extensive process where hundreds of engineers (anybody who was on git blame) had to be online and sitting by for four hours while it rolled; the release team often had to hand-revert bad patches; bullying of engineers who "broke the build" reached levels that would raise HR eyebrows; there were still often rollbacks and site breakages.
- microservice hell: there were often 2-3 APIs for the same service; platform engineering (for the protobuf RPC generation) had to support five different languages; security auditing was NP-hard; every team had its own release process; services that were still highly used were "deprecated" and left languishing for years until somebody took up the mantle and released their own parallel service that did nearly the same thing but with a different API, so now other services had to use both; etc.
"But that wouldn't happen at $my_company, we know the pitfalls and we'd never be that bad at engineering!" Sure...sure. That's what these companies said to themselves too :)
I have also known both albeit on a lesser scale.
At a company we as a dev team had to maintain a constellation of desktop applications and homemade ETL Airflow-like software that scaled really badly. For the time I'd been there I had managed to automate deployment almost totally on my own. Sadly it had been somewhat controversial as it was done at the expense of other development tasks (my manager agreed but not his nontechnical manager), and probably too late too. Before I had had enough grasp on the complicated context we had to deliver on a big project and needless to say it was a shitshow and we developers took basically all the blame, with pretty much nothing to say back.
The tech stack and code had been in a state of neglect for 8+ years but that was not an acceptable answer at that time, it seemed, and I'd only been there for 6 months when it happened.
On the other end of the spectrum, at the above's parent company, I had to maintain several major versions of an API on several cloud regions. Undocumented peculiarities regarding the object storage that was specific to one region caused a production incident that took the dev and support team 3 days to untangle and solve.
I have similar stories on monorepo vs. multirepo too
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."
"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"
> 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?
If it was a monolith I would have access to the same codebase, so I could just go look at stuff in the code?
Versus microservices where I might not have permissions to look at their repos.
It's a fascinating set of priories that lead to these policies.
"We trust you enough to run your code in production but we can't let you read another team's code because you might steal it. Yes, the odds that anyone wants to steal the code for this mundane microservice are staggeringly low... and yes you're going to be less productive and more prone to serious bugs by being in the dark, but that's your problem."
I honestly don't even know if it's "you might steal it"
It's just this vague notion of "if you aren't contributing to this repo you don't need to access it" or something.
When I'm forced to work with a monolith that has 4000+ source files and takes a few minutes to even start up, and has about 20 configuration files that all need to be setup properly for it to even start, I wish for microservices.
When I'm forced to work with microservices that need Skaffold and Helm charts just to run locally, but with the configuration in the monorepo being kind of mismanaged and strewn around a bunch of folders with no documentation, in addition to debugging in the IDE not working because nobody set it all up, I wish for monoliths.
Really, you can have good monolithic systems and you can have good microservices as well, in addition to something in the middle: https://blog.kronis.dev/articles/modulith-because-we-need-to... (actually the first blog post that I wrote, the casual language probably shows its age).
But there can also be plenty of poorly developed projects with either. It just so happens that people hate monoliths more in the mainstream culture because most of the older and worse projects out there were monolithic, much like many hate Java and other languages because of being exposed to bad legacy projects written in them: https://earthly.dev/blog/brown-green-language/
Just wait for 5-10 years and people's disposition towards both monoliths and microservices will even out, the advantages and disadvantages of either will become clearly recognized and the hype will shift towards something like serverless. Much like now we know the advantages and disadvantages of languages with/without GC as well as higher/lower abtraction levels pretty well (consider Python vs Rust, for example).
Maybe things will slow down a bit because Kubernetes will also become a bit easier to use, possibly thanks to projects like K3s, K0s, Portainer and Rancher.
It turns out the secret is just not writing crappy software and having crappy processes. It turns out the caveat is that the conditional probability of those two things is vanishingly small, so regardless of monolith or microservices, most devs are exposed to crappy stuff and because their sample sizes are tiny they assume well we just did it wrong, when in fact they did it average and average is crappy for any and all architectures.
> ...when in fact they did it average and average is crappy for any and all architectures.
I feel like this is probably more true than many of the people around would like to admit.
Very much like how there are plenty of proponents of DRY and SOLID but plenty of bad systems still get built regardless, even when trying to follow any number of principles along the way.
So you'd have to decouple what an architecture is supposed to (realistically) be, from any company-specific interpretation of that, which may not actually be doable. It's not so much the "No true Scotsman" fallacy (which comes to mind), but rather the fact that things almost always differ in theory in practice.
As an unrelated example, it would also be really useful to generate implementations from code models, like OpenAPI spec --> usable API client in language/framework X, or OpenAPI spec --> usable service stubs for the server in language/framework X, but in practice it never works out and most model driven approaches remain on paper.
Similarly, there are lots of ways to screw up your application architecture regardless of the specifics. Talking about which type is easier to screw up and in what ways, however would be a useful conversation to have!
I wonder if part of the problem is the always new technologies used. Maybe if the world had stuck with some sort of improved version of C and got really good at it, with all kinds of great tools and techniques, we might be able to deliver code efficiently.
I definitely think that's an aspect of it, but it's not one we can really do a whole lot about. The nature of what we do and the skillsets we have mean when we encounter problems we then come up with solutions and those solutions have their own problems, so it just infinitely recurses.
I think that's a lot more controllable on an individual level than on an industry level. I'm sort of attempting to do that myself in some ways by just picking a stack and working my way through building something in it end to end covering absolutely every aspect I can imagine in terms of software engineering "jobs to be done" and as I build it, going through industry go-to resources of how to best do X and properly implementing the advice. I think if more of us bothered to do that we'd be far more capable of starting software companies off at a much more advanced stage of technical maturity and hence with less problems that arise from the hacky shit we cobble together under financial pressure to ship, ship, ship. That would ideally result in significantly less churn.
Essentially, yes. Just take something and get ultra good at it and then stick with that thing.
Nothing stops microservices from having the same problems. Plus all the extra problems you get with distributed systems (timing issues, logical dependencies etc.)
Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making dumb things hard. We were also able to deploy individual services much more frequently without needing to coordinate with a bunch of other teams, and builds, tests, etc were much faster helping shorten our iteration loops.
Local development environments were a bit more tedious in certain cases, but that was the only issue I recall.
Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.
I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request.
gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.
How does gRPC make authentication lighter-weight? Presumably you still have a token in either case which needs to be validated? There aren't many places where parsing HTTP requests is really a significant bottleneck, and I'd guess the majority of the remainder are an architectural problem (someone using a "get" endpoint in a tight loop instead of a "list" endpoint or some such).
Technically you could auth the connection using say, a custom SSL cert, and the connection isn't made unless the SSL cert is recognized.
There are other ways to do it as well where the socket connection is only authed once.
At a multibillion dollar company, local development is impossible, staging doesn't exist, most stack traces from production are truncated because the log aggregator cannot handle log entries as large as java stack traces, and most of the work involves migrating from talking to the database to talking to a microservice that exposes a single table of the database. What are joins?
At another company that was acquired by Amazon, the "user service" team (so again this is a microservice that exposes a single table of a database, this time with a two-pizza team dedicated entirely to that microservice) told us that we couldn't just query the user service when we wanted to render a page containing a username given a user id, because that was too many queries. Product demands from a VP dictated that we didn't have time to set up our own caching layer for their service (is this the responsibility of every team other than theirs?), so we shipped the feature with the usernames saved in our own DB, and now when users change their usernames the old name will appear in the pages for our feature, depending on when the pages were created.
Obligatory repost: https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZA...
If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.
On the contrary. An experienced architect defines the boundaries and then the microservice architecture enforced them in a way that a monolithic architecture cannot.
On the contrary. Using libraries with clearly defined interfaces makes it easier to combine those libraries into a single executable, reducing deployment and debugging complexity. It also dramatically improves performance given the lack of intermediate encoding/decoding protocol code and TCP/UDP hops. Experienced seasoned Architects knows this and work hard to remove unnecessary distributed complexity from systems they design. While “beginner experts” always pick the most complex “solution” for the job at hand. The worst spaghetti code I have ever seen in my 30+ year career is a 20+ years old Microservices architecture. So I can’t wait to read the future “We had a problem so we chose micro-services. Now we have N distributed problems + K impossible to debug obscure timing issues” articles.
My 2c is that an experience architect would know that it would be ideal if they could do this and be right, but in practice they aren't likely to get those boundaries correct up-front and it takes time and experience working in the domain to see what those boundaries truly ought to be. Also, it's perfectly possible for monolithic applications to enforce boundaries as strict as microservices do via a "modular monolith" approach where the domain contracts are marked as public, but all the domain logic is marked as internal, and a framework of sorts enforces that each module only has access to either it's own schema in a shared database, or it's own separate database.
These days I think that's actually where everything should start off. With a good implementation of this you can transition relatively painlessly to a distributed system, and in the initial phases the simplicity of the build/test/deploy cycle massively lowers the overhead compared to a microservices approach while the strong isolation of domain logic gives you the ability to reason about changes to your domain not affecting other areas of the system.
Having worked in both small companies with terrible monoliths, small companies with terrible microservices, big companies with terrible monoliths and big companies with semi-decent microservices, and then implementing a modular monolith myself, I've seen enough to know that it's a solid, solid starting point. Most companies are pretty small, and the difference between an engineering org of 40 engineers trying microservices vs an engineering org of 4000 engineers doing microservices is on such a different level that people who haven't experienced both likely can't appreciate the data point that they're missing.
I love the strong isolation that microservices provide, and they can be super beneficial, but done at the wrong scale, the wrong level of technical maturity, or the wrong time and they're a huge drag. By the same token a monolith that grows too large for too long is equally a drag, but it's one that's exponentially more tolerable in an engineering org of 40 engineers than it is an engineering org of 4000 engineers. The key thing isn't which architecture you pick, it's the ability to be able to transition and adapt at the right point in time. Modular monoliths buy you this opportunity at a fraction of the price and for much less risk.
100% agree. You can write bad code using both Monoliths and Microservices. However Microservices are inherently more complex and slower than Monoliths (because of the added encoding/decoding and network overhead).
This is probably true if you have good engineering discipline in the monolith case such that your team adheres to good architecture. In the microservices case, as long as your architect is competent, you can draw sane lines between components and it's dramatically harder for IDGAF managers and developers to violate them. Everywhere I've worked, the microservices approach ends up being considerably simpler precisely because it makes it difficult to do things that are probably bad ideas in the first place (it's the same concept with static typing, by the way--a sufficiently smart team may not need explicit types, but in practice most teams aren't sufficiently smart, and the types function as rails to keep people from doing dumb things). Every place I've worked, the network and complexity overheads are paid for many times over by the simplicity and performance of preventing people from doing dumb things.
It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole application, with failures cascading across your replicas).
>It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole application, with failures cascading across your replicas
This is not inherently true. Whether it's true or not is down to your implementation. You can most certainly have reliability and security problems while doing microservices.
> This is not inherently true. Whether it's true or not is down to your implementation. You can most certainly have reliability and security problems while doing microservices.
Obviously I didn't claim "you cannot have reliability or security problems while doing microservices".
I think the critical aspect of whether or not you need them and hence whether or not they represent a good set of trade-offs, is on what dimensions are you optimizing for.
My previous employer was a small engineering org of around 40 engineers with a monolith of below average quality, trying to go in a microservices direction and not really having that pan out a great deal due to being unable to spare the engineering bandwidth to invest enough in managing the complexity while still having to deal with the monolith.
My current employer is an engineering org of around 4000 engineers that one two headed monolith that makes up the original product (web app + api share some code and are monoliths in their own right) and also very successfully uses microservices for everything else and there is a lot of them.
At my previous employer dealing with the monolith was fine even though the code was rather horrid, and we would release twice a week. The "microservices" I wound up building/working on there were not worth the overhead / complexity added at all and we would have been far, far, far better off investing in cleaning up the monolith to make it safer/easier to work in.
At my current employer dealing with the monolith is not fine. You have to book releases in a calendar, it's scary, it's giant, and despite multiple releases of it per day, there are so many other teams that book releases for it that you have to queue up to get your turn and it's done that way for safety. Yes, we also use feature flagging too. It's also vastly more difficult to know/find who you have to communicate with about changes to the monoliths because unlike a tiny engineering org, that information simply doesn't fit in your head. Here, the microservices we own are awesome in comparison. They are small code bases that are easy to reason about, our organization invested a massive amount in the technical maturity needed to operate, maintain, and be able to handle the complexity, and we have continuous deployment pipelines that mean we can safely release multiple times per day and when PRs are merged they are shipped all the way through to production in around 15 minutes.
So, when you say "more complex and slower" you have to ask yourself "than what?" There is no "one is better than the other", there is only "every tool is the right tool for some job" and "every tool is also the wrong tool for almost any other job it was not designed for" and your job is to understand exactly what tool your specific situation actually calls for.
This is why I like modular monoliths as a starting point, as they're essentially a multi-tool. A half-way compromise which is not as easy to use as a full-blown dedicated tool, but is versatile enough that if it's the only tool you have and you have no idea what job you're going to need to do, then you've probably made an adequate choice regardless of what the situation calls for in the end. And if you outgrow your multi-tool, you can much more easily swap it out for a set of it's dedicated equivalents.
> Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them.
Likewise. When I see people complaining about microservices, more often what I see is actually poorly thought-through strawmen aimed at distributed systems, which boil down to "having to do network requests is bad".
I wonder why attacking the "microservices" buzzword gets these people on rage mode but the sight of a web app calling a dozen APIs somehow doesn't make them bat an eye.
That sounds like a "True Scotsman" argument. The fact is that microservices are inherently and objectively more complex than Monoliths. So if you can't build a well engineered Monolith then you are pretty much guaranteed to build an even worse Microservices system (because you now have the added encoding/decoding, network hops, latency and timing issues, no guaranteed data consistency, no global commit guarantees etc. etc. etc.)
I can believe that monoliths have a lower theoretical complexity floor than microservice architectures, but I don't think any shops are coming close to that theoretical complexity floor irrespective of their architecture, so we need to think about the actual, practical complexity of applications in each architecture.
Specifically, I think the strong boundaries between components better facilitates maintainability--as with dynamic typing, the absence of rails allows people to more easily make bad decisions. In the case of monoliths, this usually looks like an inexperienced developer (especially at the bequest of an unscrupulous manager who swears that we will definitely not do this again and will fix in a subsequent release) taking a dependency on another system's private internals. In other words, I assert that given a good architect and an average team, a microservice architecture will be less complex than a monolith despite marshaling data over a network. In order to have a well-engineered monolith, you need good architects and a good team (no unscrupulous managers who are empowered to compromise the architecture in the name of expedience).
> no guaranteed data consistency, no global commit guarantees
You don't get these for free with monoliths either. I've seen a lot of monoliths choc full of race conditions which don't manifest during development (small contrived test cases running on unburdened systems). Paradoxically, because microservices have to marshal data over a network, these consistency issues are more likely to appear. Moreover, people who work on microservices are more likely to think about race conditions precisely because the system is distributed (indeed, the architects think about this stuff when they lay out the interfaces).
A friend of mine is working on a 20 years old Microservices application. It is literally the worst piece of garbage system I have ever heard about. I am sure my friend would have loved for it to be a monolith instead of 50+ services with massively complicated distributed dependencies and timing issues.
Really? You’ve never seen an over-engineered microservices design that could be a much simpler express app?
What is an express app?
An app in express.js, a web framework.
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.
Companies like Jane Street use Monoliths to handle millions of transactions per second. How many transactions per second do you have?
It still depends on the organization size (or the size of the user base, or the complexity of the product). So you may only have experience with services where it was the right choice.
I did see two instances where it wasn't. (I mainly work with/for small companies, startups.) In one instance I was called in as a tech lead/expert for a small startup having a kind of a product/software crisis. They've been working on their service for a year or too (yes, way too long) and 2-3 months before the planned release at some random conference (Slush, TNW or whatnot) one of the developers figured out that the whole codebase was a piece of shit and there was no way they could be ready in time, but they should rewrite it as a collection of node microservices and that could work. The monolith they had was PHP, just to add to the fun, so switching over would mean switching languages too.
The guy, he was a smart and motivated chap, even started implementing one service in his free time, the user registration/user handling I think (the least important and least complex one, of course) which somehow screwed up the monotlith and made it start crashing. (Or so they said, I don't know what was up with that.)
Obviously, it was a 100% stupid idea and we went on with fixing their development process (starting to do scrum and teaching the stakeholders that they need to stop phoning the developers directly and asking for features, fixes, introducing automated testing, etc.) Oh, and it was a team of 2-2.5 people. (With the group manager doing some backend work too, but also managing another, totally unrelated project for another client.)
The other one was a bit different story, where I just shared my insights over a call. A guy I've known took over a project that was built by a small team (2-5 people, can't remember) for a startup and wanted some external opinion for himself and the founder. That one was built as a set of microservices but they did have all kinds of stability issues. The idea was that it had to be very-very-super scalable. Because, you know you launch and they will come and there's nothing worse than not being able to handle the load. Except, there is: they had been building the thing for over 2 years back then.
It was an online medical consultation solution (you describe your problem, pick a doctor, do a f2f call and pay by the time). The funny thing is that I've built a very similar system, as a startup cofounder, 3-4 years earlier for psychology consultation with the help of 2 other guys, who didn't even work full time (one of them came after the first one quit). The MVP was up in, I think, 2 maybe 3 months. Ours was a monolith-ish thing and theirs definitely looked better, maybe scaled better and would have been cheaper to operate at scale (we used an external service for the video calls). But ours was a lot cheaper to build and launch and we could test (validate) our solution a lot earlier with real customers.
If it worked out, we could have started breaking it down into multiple services as/if/when needed.
> (...) The monolith they had was PHP, just to add to the fun, so switching over would mean switching languages too.
Why do you feel this is relevant, let alone detrimental to the idea of microservices? It looks to me that it's one of the primary positive traits.
> The guy, he was a smart and motivated chap, even started implementing one service in his free time (...) which somehow screwed up the monotlith and made it start crashing.
This statement makes no sense at all.
> Obviously, it was a 100% stupid idea (...)
I saw no stupid idea in any of your statements.
You stated the legacy codebase was crap, and that a team member took up to himself to do the strangler's vine thing and gradually peel responsibilities out of the monolith. What leads you to believe this is stupid?
> Why do you feel this is relevant, let alone detrimental to the idea of microservices? It looks to me that it's one of the primary positive traits.
I did explain at the end of the sentence, why it was relevant: because rewriting in JS would have also meant switching to a completely new language. Which the team, as a whole had less experience with and which would have made it a complete rewrite without being able to reuse anything.
> This statement makes no sense at all.
I'm sorry you didn't understand it. If you asked a clarifying question I may have been able to explain.
> You stated the legacy codebase was crap,
No, I said one team member stated that the code base was crap. I didn't say it was crap. I didn't evaluate it, because I don't know (and don't like) PHP and because I didn't have to work with it anyway. The other two team members said the code was of acceptable quality for them to work on.
> and that a team member took up to himself to do the strangler's vine thing and gradually peel responsibilities out of the monolith. What leads you to believe this is stupid?
Because this is not what was going to happen and because they had been working on the thing for about 2 years back then without releasing it and because their planned release would have been in about 2 months. It's almost never about only the technology, these products and services serve a business purpose or provide value through other means. If it didn't matter, you can of course take all the time in the world, start over 10 times just to come up with what you think the best solution is for the problem. It's totally fine, this is the artistic approach. If you follow the engineering approach then you have to factor in the time and the investment too. Because in that case you have to deliver value.
Regarding peeling away gradually, this wasn't really what I said. The person pushing for the microservices solution said they needed to rewrite. So stop the world, rebuild the thing without having a working system during that period. (Because they didn't have a working system to start with.)
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.
I agree. There’s a whole cohort that seems to think you should introduce IO between every function call. But they’re not “managing complexity”, they’re just shifting it into the operational layer, where it’s harder and more expensive to run, debug, secure, etc.
A crypto exchange has bragged about having 30ish microservices per engineer. It's pretty wild.
I think that using the word "stupid" instead of "wild" would be more accurate.
I'd love a number attached to that "most"
All but two. And in my previous role that was a very substantial sample set.
They're irrationally thrown up there as a silver bullet and people are heavily criticised when people suggest non-monolith+microservice alternatives.
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?
Nothing in the article is fresh news. Sam Newman made many of these same points himself in his 2015 book on microservices.
The article does _not_ discuss why engineering teams ignore that advice.
Companies see microservices as a silver bullet for solving complexity. Inexperienced engineers attracted to shiny things jump on the bandwagon. Vendors sell tooling to deal with the new complexity. But in that case, if it wasn’t microservices, it would be OOP, FP, SPAs, RPC, RDBMS, NoSQL, etc. The problem is the hype cycle. Over-use of microservices is only a symptom.
He didn't label it as "news", it was an opinion. Regardless if it was said before, who cares? He's not allowed to speak on his experiences because it offends your MO?
I think the opinion he had was justified by his own experiences, which mimic my own - and many of those working at smaller agencies/dev shops (you know, the vast majority of the workforce). It was nice to read something not entirely in the perspective of a Silicon Valley developer drunk on his own ignorance of the rest of the world.
Check out my comment history and you’ll see that I agree with the points too! But the bar for a good Hacker News post is “interesting”. Opinions that are widely agreed with on here, and have been for years, don’t meet that for me personally. That’s my say on the matter, you of course are welcome to yours.
For what it’s worth, I live in the UK, and have never been to the US.
I implore you to watch the incessant, and regular posts on HN claiming that microservices are the future for everyone and everything, and then be there to tell them you've seen this before. My guess is you won't be as lead-footed in those cases. The idea that if you write an article or an opinion, and have to do an hour of research to see if its been covered before is a high level of micromanagement that you just aren't ever going to see, I'm sorry. It's super unrealistic to expect that.
Sure. It’s also super-unrealistic to expect me not to criticise the article for being boring.
> "where you can get a whole bunch of likes by saying “microservices bad amirite?!”
Okay.
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.
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!"
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.
That haven’t tested the vaccines. That’s why there’s emergency use laws.
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.
Amen!
bravo
"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.
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.
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.
The same advantages can be achieved by separating things into libraries or discrete packages.
Microservices just takes that and spreads it around a K8S cluster using gRPC or RESTful JSON or some other RPC bus for all the various modules to talk to each other, consuming far more compute resources and helping increase atmospheric CO2 and make cloud vendors rich. Why is calling a library running in a separate task (possibly on a separate CPU) via gRPC a better approach to code modularity?
The only time this makes sense is when you are (1) totally huge and (2) have specific hot regions of your service that you want to autoscale relative to the rest of the service.
Incremental upgrades can be achieved by just incrementally cycling your service, no microservices needed. Doing so when only some modules change can be achieved with CI without the crazy runtime overhead.
I agree that it only really makes sense to consider when you have runtime concerns around performance that justify the added complexity. I posted that in a comment elsewhere. However, I think the benefit to modularity can be significant sometimes. Separating something into libraries is an exercise in organizational discipline, and in my experience it often fails. An inviolable boundary can be valuable for orgs who struggle with that sort of thing.
That said, even small apps virtually always have hot regions. Typically those can be ignored until big scale without impacting the users, but that doesn't mean it's efficient to do so.
I would also definitely push back on the idea that a monolith is inherently more compute/energy efficient. I'm not sure how you arrived at that conclusion, but it doesn't take much in the way of efficiency gained from individually scaling services to make up for the tiny additional costs of your orchestration/communication.
Personally I'm a monolith guy. I think the discipline required to build and release a good monolith is typically easier than the difficulty of maintaining services. I would rarely recommend a microservice architecture. But I don't think it's in anyone's best interests to just pretend that the benefits of microservices don't exist.
Everything you claim is unproven and pure speculation. However what is proven to be true is that thousands of developers all over the world can effectively work on massive monoliths (like Linux and Windows) without using microservices.
> "move stuff around and complexity will magically go away" fallacy
This is a great description of microservices
> actually practical and useful provably-safe language (Rust).
You can have spatial and temporal memory safety by writing single threaded code in any GC language.
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.
You might misunderstand the point here.
It's about how to keep the velocity without firing junior dev, without removing bad code from the production system.
So microservice is a leadership tool to manage it. Keep it in control.
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.
Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
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."
I think there's a lot of historical accident involved. Personally, my experience of the two terms was that I heard about "services" aka "SOA" first, and it meant a top-down global architecture where the pieces were composed in elaborate, cumbersome ways: service buses, orchestrators, complicated XML-based technologies, service discovery, remote transactions, all that fancy stuff that many people tried and few people ever got working correctly. People were talking about integrating a new service to your architecture by dragging and dropping widgets in an orchestration dashboard generated from XML descriptors published by the services, and it was the kind of thing that blew your mind for a few seconds until you realized it was obviously never going to work.
Then I heard about "microservices," and the people using that term were talking about JSON and HTTP and DNS, stuff you could actually imagine working, and then you tried it and you actually could get it working with almost no effort, which was mind-blowing in a different and better way.
That difference was a historical accident based on where those terms were in the hype cycle. Now a lot of definitions of "microservices" describe architectures that are almost as elaborate as the old SOA ideas I was exposed to, and people have the same reaction I did to "services" back then. And now it's the supposed microservices experts who will tell you that if you did anything simple enough that you actually got it working in less than six months with less than fifty people, then you did it wrong and doomed your company. The hype cycle has made a complete turn.
This kind of thing happens a lot in IT. You could see the same thing around 'Agile', '4th generation languages', 'mindfullness' and a whole raft of other terms that momentarily become the fuel for the incomestream of certain consultants.
When I see a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together it usually is because someone took the 'services' pattern a bit too far and in that case 'microservices' is a proper moniker. And for Erlang based systems it usually is also appropriate. If there are fewer than 10 or so services usually they are not 'microservices' but just services.
> a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together
For what it's worth, I suddenly feel a lot better about my employer's architecture. :-) But we still call them microservices because language.
There was this fantastic cartoon in a dutch newspaper long ago, it was a really long train about to leave the station and lots of people were trying to get on it, by hook or by crook, people hanging on to windows, sitting on the buffers etc. A reporter with a microphone approaches one of the people trying to get on the train. "Sir, why are you trying to board the train, where are you going?". The answer "I have no idea but I really don't want to miss it.".
The banner on the train was 'The Internet', the cartoon was published in 1995, right when the dot com bubble started its proper inflationary phase.
These hype-trains occur over and over again around a specific theme, the funny thing is that 'the internet' eventually became at least as revolutionary as those that were trying to board that train hoped it would be. But the bulk of those hyped things are usually not going to make such a huge difference and then, instead of adopting the item and incorporating it we move on.
You can usually get an idea after a year or two when a technology is introduced which way it will go, and a good sign that the life is out of it is when the consultants and writers of books move on to greener pastures.
See also: blockchain, the semantic web, etc, etc...
> 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.
You mean a Client Server system? That is not microservices.
There is this much simpler advanced technology that can be used instead that has been around for 50+ years: it's called libraries/modules. It works. Linux is a collection of thousands of libraries. Windows is a collection of thousands of libraries as well. Linux and Windows are way bigger than pretty much any other software out there. So I am sure this advanced technology is good enough to handle whatever you and most other devs are working on.
Why micro-?
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.
Nothing you say can't be accomplished by using libraries instead. The largest software on earth (Linux/Windows/...) is created by composing thousands of libraries into a single system. With thousands of developers contributing from all over the world. It works. It's proven.
Composing libraries offers some of the advantages of microservices, but not all of them. For example, a vulnerable library still has access to all of the secrets used by any other library, whereas a vulnerable microservice will only yield the secrets it needs. Similarly, a critical bug in one library can bring the whole process down, even if the library itself is a non-critical component—a critical bug in a microservice will only tank that service (and maybe services that depend on it if they don’t degrade gracefully). Notably, Linux and Windows spend tremendous energy making sure these vulnerabilities and bugs don’t slip through!
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"
Yes, we have a term for that: Technical debts!
The reality is like this: You have a critical system that ran for ages, and now what will you do to scale the features ? By allowing/teaching junior devs to understand how to contribute to the codebase ?
There's a simpler way to do that efficiently: Extract a subdomain into its own microservice and you control the interface. Then even that microservice has bad code quality (tech debt), your business is still running fine!
Problem solved.
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...
The point is, to keep the sprint in velocity, let's just keep the bad code (tech debt), but make sure it won't break the quality of original system. By extracting "bad parts" into its own system, you can manage it efficiently.
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.
Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?
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.
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.
Yea. IMO, microservices are usually more of an organizational solution than a technical solution
IMO software is usually more of an organisational solution than a technical solution.
Libraries can do the exact same thing. And it is a less complex solution.
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...
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.
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...
Simple example.
You have an app and just 3 microservices web + recommendation engine + payment gatway
This means that the team that handles recommendation engine can deploy as fast as they want while the payment gateway (which is brittle and mission critical) stays put.
If you have just a monolith then everytime the recommendation engine is tuned, the payment gateway code is also redeployed with possible downtime (contrived example but just to give you the idea)
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?
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.
Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
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.
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.
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.
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.
> 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.
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. :)
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
Hmmm, great idea that way cloud providers can extract insane amounts of money from unsuspecting organizations. Let's call it function as a service :)
That doesn't seem advisable. Maybe you should try microservices instead?
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.
> 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
And that would run the function _on Lambda._ Whether that function is JS, Ruby, Python, whatever.<?php MyNeatServerlessFunction::execute(['foo' => 'bar']);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.
So it doesn't configure API gateway? Not sure how useful this is since that is the entry point for all the lambda functions.
If I want to create functions easily I would just use pure functions in Chalice
@app.lambda_function(name='MyFunction') def myfunc: return 'OK'
and then I could go into MyFunction and modify the code. I just don't see why I would need to use PHP for this.
Correct, no API gateway.
> Not sure how useful this is since that is the entry point for all the lambda functions.
Well that's just not accurate! You can also call them via API. Which is what Sidecar does.
> I just don't see why I would need to use PHP for this.
Because you're already using Laravel! If you're not using Laravel, you wouldn't use this.
If you want to see me doing a live-demo of this at a conference, it might make a bit more sense: https://youtu.be/0Rq-yHAwYjQ?t=11751
>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.
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.
>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.
Jane Street using monoliths to manage $bn of trades a day and millions of transactions per second. So nothing you say makes microservices necessary.
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.
What problems are solved better with microservices? Serious question.
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.)
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.
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.
> 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
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.
You have a problem. So you choose Microservices. Now you have N distributed problems and a system that is K times slower. Well done.
> 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.
Also known as "multiple points of multiple failures".
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.
Nope. 95% of SaaS products out there use monoliths not microservices. For good reasons.
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]
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.
That’s the story for them. I also think it’s possible to do this with code for APIs in different files.
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"?
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.
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?
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.
OOP was a tight coupling between state and functions.
Also, You Don't Need Micro-frontends.
You don't medium dot com either.
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 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/
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.
I just read yesterday, that not only does my blog need microservices, it needs microfrontends.
Wow. The pendulum has been going back and forth on this one for a long time.
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?
Just write regular sized services, we don’t need to all live on the edge