Don't microservice, do module

https://yekta.dev/posts/dont-microservice-do-module/

by thunderbong • 2 years ago

138 159 2 years ago

gostsamo2• 2 years ago

Yet another self righteous person on the internet teaching us the errors of our thinking. Everything wrong with micro services is an issue with micro services and everything wrong with modules is a skil issue of the person doing the modules.

Once the interface is established, each team can operate independently, just like in microservices, as long as they adhere to the defined bounds.

Where I was lost laughing.

I'm sorry, but the hords of spaghetti monsters that I battle on a daily bases are spawning because communication is hard the more people are involved in it and the more someone is in a hurry to deploy their feature. Not even talking for the fun when you need to update a third party dependency and you discover that half of the code base depends on a now removed feature, so expect migration in 5 to 12 years time.

Joel_Mckay2• 2 years ago

Microservices can destroy DevOps teams used to kludging polyglot stacks together.

The issue is hardly limited to training, but rather ignorance of ones own bad habits.

Author probably heard the buzzword off someone else's CV. =)

graypegg• 2 years ago

I feel like at this point in my career I've worked in all four quadrants of the spagehtti/encapsulation plane

                   ^
                monolith
                   |
                   |
  <- spaghetti ----+------ clean ->
                   |
                   |
          independent services
                   v

I really feel like it doesn't correlate. I think the real cause of spaghetti monsters is *mismatching* microservices to applications that are actually a single project under the hood, or monoliths to applications that are actually multiple applications under the hood.

solidasparagus5• 2 years ago

If you turned that into a heatmap of all software projects, I bet there would be hotspots. Probably would need to filter by project size or you would just end up with clusters at the top-right and bottom-left though

m_2000• 2 years ago

Having an opinion on something doesn't make the speaker a self righteous person.

Regarding the topic, I assume that with "the hords of spaghetti monsters" you mean lack of software perfection. In our profession, it's mostly about how to manage the lack of software perfection, and the answer does not always have to be a microservive. They are great for controlling hardware resources in a cloud-deployment, but then I see tech-dudes dockerizing everything anytime without asking why.

It's a decision every dev team have to make for themselves.

gostsamo2• 2 years ago

Opinions are like asses - everyone has one. Self righteous people are those who think that only their opinions matter and try to present them as facts, rolling over any reasonable objection with hand waving and insulting the other party for not understanding things.

HL33tibCe7• 2 years ago

As I’ve grown older I have developed a heuristic, which is that people who talk/write like this, i.e. being completely convinced that one way of doing things is always wrong and one way of doing things is always right, and that people doing things the other way are just ignorant/stupid/wrong, usually have no idea what they are talking about.

zdw• 2 years ago

I feel the same way about people who are "Everything needs to be containerized in K8s". Sure, it's useful in some cases, but it isn't some universal panacea.

Understand the problem space, understand the solution space, and try to find a fit, don't just grab your favorite hammer and start whacking away.

Art9681• 2 years ago

The k8s evangelists are operating under the assumption that if your product or service is successful, you're probably going to want to scale it, and if you believe in that vision, then you're probably going to want to think about k8s early in your project, not when you've grown it to millions of users worldwide.

But I get what you mean.

rswskg2• 2 years ago

It's not about everything fits, it's just much easier for orgs to have a consistent environment for developers to use. Google does this to great success, getting out of the box logging, metrics, a universal way to define a system, access secrets. A whole class of decisions stop being made all the time. Anyone in the org can look in a repo and understand what and where everything is deployed. It's simple stuff like this that make it compelling.

photonthug3• 2 years ago

Understand the problem space, understand the solution space, and try to find a fit, don't just grab your favorite hammer and start whacking away.

People who understand the problem space will eventually notice that kubernetes isn't a hammer but whole toolbox. So you can reach for it when you need a hammer, a different hammer, or a screwdriver, or when you're not sure what you need, or when you're 90% sure what you need but also willing to admit you might be wrong.

Not a universal panacea, but if we're going to get into this "right tool for the job" discussion, it's a complete misunderstanding to characterize it as a single tool.

frenchman99• 2 years ago

I agree with you. And at the same time, I often feel like it is more difficult being heard when being nuanced. It seems like what gets discussed most are strong opinions.

outofpaper• 2 years ago

Maybe we need to work on Sound bites

- The only thing every project has in common is that they are all different projects.

- Success in one project doesn't guarantee success in another.

josephg2• 2 years ago

Yep. It’s easier for a simple message to be carried by the wind.

But the process of growing up is one of increasing capacity for discernment. Ie, you learn more subtlety discerning when thing A or B is a better idea in any given moment. Will a hard or soft approach work better? Use my old tools or learn this new framework? Make a long term or short term decision here?

It’s hard to communicate because this kind of learning takes a lifetime to accumulate.

mattgreenrocks3• 2 years ago

Yeah, so it presents a real conundrum. If you read the article, then he still presents arguments in favor of microservices.

I often feel like it is more difficult being heard when being nuanced. It seems like what gets discussed most are strong opinions.

I really resent this phenomenon. It traps us in poor local maxima because our systems optimize for engagement over actual development of complex, nuanced opinions. It feels like the dopamine-addled end up indirectly pulling the levers on how we talk even if they're less interested in the actual craft.

onehair• 2 years ago

The hardest part is when you're being nuanced and people misconstrue it as you being indecisive xD

_heimdall7• 2 years ago

I've definitely seen that happen, and in my opinion its just a sign of bad culture or bad leadership. That's not to say its toxic or widespread, maybe its just a poorly run meeting, but nuance should be a focus of any important discussion rather than the voice that goes ignored.

tpmoney• 2 years ago

My approach is to have strong opinions (weakly held), and ask if people have objections to the tradeoffs. That tends to keep the focus on specific reasons to choose a given path rather than you and someone else just having different preferences. Doesn't always work, but it's a lot easier than fighting over whether option A or option B is just universally better.

bloppe• 2 years ago

Depends on your audience. Maybe you need to dumb it down for some people sometimes. That's life. I just try to stay in situations where the audience appreciates nuance if I can

deepsun• 2 years ago

I.e. every architectural question in IT is answered by "It depends".

PS: And every single problem is a "problem in communication".

josephg2• 2 years ago

While true, but that’s totally devoid of information. People still need to make decisions. Even people who lack the wisdom to make them well.

themgt• 2 years ago

There’s a Persian proverb, which is a shorter form of a poem by Saib Tabrizi, which says "don't microservice". We don’t live forever, do we? Laying the first brick correctly is the first step to avoid building a crooked wall.

rgrieselhuber2• 2 years ago

The best advice I got early in my career on this topic was: “Nobody serious is going to take you seriously if you give one option as the ‘way it has to be.’ Everything has trade-offs, you will be much more effective as a communicator if you list a few options, along with their trade-offs (and be honest about these). You can even have your preferred / recommended option but it also must come with trade-offs.”

hakunin4• 2 years ago

One of the problems I often see is that when trying to explain one of the possible options, people don't understand it. When that happens, you try to explain it to them harder. Your explanation is then mistaken for pushing for that option. It's important to carefully navigate around this perception. People should understand that first you just want to be on the same page what your options are, and then discuss the best one.

dpacmittal• 2 years ago

I do this instinctively but I feel like I'm coming across as confused and unsure.

citrin_ru• 2 years ago

Well, you mileage can vary. I see trade-off almost everywhere but many managers are not exited to hear about trade-offs and want to get a perfect solution when you don’t need to sacrifice anything. Though it is not as bad as a manager who already made a decision ignoring trade-offs of different options.

philwelch• 2 years ago

Unfortunately there are a lot of non-serious people in the industry.

dude187• 2 years ago

That's how I give advice and it can be a huge struggle when working with people out of their element, or in a job they frankly didn't earn.

It's really the only way a productive design conversation can go, but those who can't contribute from their side of the fence will get frustrated. Saying things like "you just need to tell me what to do".

On the flip side, those who think they know better will have pretty much already made up their mind. Which makes things even worse if they don't know better, but for the competent ones this is the easiest and most effective setup of them all.

carimura• 2 years ago

Same. Basically an inverse relationship between certainty and knowledge. Sort of like those stories told by entrepreneurs about why their startups were successful.

alemanek4• 2 years ago

Yep, I used to be that guy as well. It is easier to see things as black and white because then you don’t need to dive deep and it is easier to sell to management. The really strong engineers/architects I have known can explain the trade offs of the various approaches.

For small teams or early stage development I love a well architected modular monolith. Grow past a couple of teams and maybe add some dedicated ops people and service oriented architectures start making more sense. Get real big and have the capacity to handle the monitoring and orchestration challenges and microservices enable that.

It’s all trade offs and recognizing that allows you to evolve with your operational and organizational needs.

seabrookmx• 2 years ago

I much prefer "service oriented architecture" terminology to "microservice" because services need not be the same size. Have a daemon listening to a queue to send emails? Sure, microservice! Have 10 REST endpoints that are backed by the same interconnected data? Sure you could have 10 lambdas or something but.. why?

Brajeshwar• 2 years ago

I've worked on quite a few defining products with a friend, business partner, and all-round designer-engineer genius. About a decade ago, we decided to answer, especially in the early stages, that anything that needed our opinion was - "It depends."

There isn't one silver bullet for most problems or situations; it all depends on several factors.

_heimdall7• 2 years ago

My only real question when I have interviewed anyone for a senior level role or similar is to find out whether they'll start with "it depends" or similar.

I'll lay out what sounds like a pretty clear algorithm or infrastructure scenario but skip some key assumptions that are needed. What I want to see is follow-up questions related to users, scaling, data retention, etc. Its a big red flag for me if a candidate jumps right into a solution.

onetimeuse92304• 2 years ago

Yeah, I am also suspicious about people with radical opinions. Truth is USUALLY somewhere not at the end of scale.

BUT, have you noticed yours is also a radical opinion?

The reality is that sometimes, a radical opinion is actually a correct one.

Which is to say heuristics are useful but they still do not replace critical thinking.

The problem with Microservices is actually that IMO most developers simply have no time, willingness, experience or mental capacity to think critically about all that stuff. People frequently need to make decisions efficiently. The theory of efficient decisionmaking I have is that frequently enough it is more important to make a decision than to make a perfect decision.

And it kind of makes sense because I also suspect majority of the population (and that includes developers) are simply unable to think critically or retrospect about their own performance.

And what you do when you have little experience in the field and can't yet think critically about things? You use training wheels.

In case of IT (and business in general), a powerful training wheel is imitation.

So what happens is that somebody at some company will publish a paper about how they solved a problem and suddenly a bunch of people will try to jump on that bandwagon ("you can't go wrong if they succeeded with it") but without the hassle of having to actually think through it, understand what were the circumstances at that other company, how those circumstances are different from own use case, etc. They will imitate what others have done before but without realising a lot of important things about the problem. Which is how we got to this whole microservices mess.

Anyway, I am personally rolling back microservices implementations pretty much every project I join. People do not realise how much time they spend solving problems that are simply due to the fact they have partitioned large application into hundreds of small services which need to each be maintained separately. We have dedicated teams to do stuff that is simply unnecessary (they usually call them "devops", but really they are just ops because more frequently than not they are not actively developing the functionality). All the performance problems, all that inefficiency usually vanishes when you roll all that functionality into a single application and just scale that one application instance over multiple servers.

My current team is even more funny. The microservices were originally meant to allow teams to work independently, but at my current team they work hard to bind all of the development process into a single stream of work. So there is some 80 people in 10 different teams all working on same set of environments, applications, with the same monthly release process, coordinating their work everywhere. But there is about 1 service maintained for each developer which means people spend half the time dealing with complex configuration. And the other half of the time figuring out how to improve performance of an application which copies all of its data from service to service.

podgorniy• 2 years ago

Your comment reads like you did not read beyond the title. In the article they provide analysis and contexts in which microservices are usable. Article does not fit in your description of "ignorant" or "completely convinced of one way".

lolinder9• 2 years ago

Let’s do a 1:1 comparison of microservices and modules. Spoiler alert: the argument favors modules, as there is little to be said in support of microservices when pitted against modules!

This is the introduction to their argument and it definitely accurately captures the tone of the rest of the article. As for ignorance, you get frequent sections like this:

With a monolithic architecture, your system is either UP or DOWN, with no in-between. With microservices, you need to monitor every service. All the services need to be UP, and they need to be able to communicate with each other, all for you to be able to say the system is UP. If even one out of your 888 services is down, the system can no longer be called UP!

The author manages to take one of the most compelling uses of microservices and turn it into a negative thing. Somehow in their mind switching from a model where you're either UP or DOWN to a model where you can be partially UP is worse, which suggests to me that they don't have very much experience operating either type of architecture. Managing an incident during a partial outage is infinitely less stressful than managing a complete outage. Whether you can officially label the entire system as UP is immaterial in a real ops context if the impact of the isolated service that is DOWN is minimal.

ryandvm• 2 years ago

Yup. Anybody that doesn't understand that most problems are complicated doesn't understand most problems.

__0x01• 2 years ago

The author did provide an exception:

Unless your specific use case demands the unique advantages of microservices, it is wiser to stick with a well-structured monolith.

The author also has a section in the article called “When should you consider using microservices?”.

_heimdall7• 2 years ago

The only right answer when asked "should we use (X)" is "it depends."

I really dislike using react and can easily say off-hand that people just shouldn't use it, but that's because I also dislike working on exactly the types of projects that react is a good fit for. There's a time and a place for everything, if not then why would anyone have bothered to build and maintain the thing?

gilbetron2• 2 years ago

To quote the movie Four Rooms: "The less a man makes declarative statements, the less apt he is to look foolish in retrospect."

hackan• 2 years ago

Yep, this post is awful in many aspects, throwing rants here and there w/o ever making a point. I have no idea how this got so many upvotes!!.

lolinder9• 2 years ago

It got upvoted because microservices are currently sliding into the trough of disillusionment. It's trendy right now to hate on them, and the author is fully on the mindless hate bandwagon right along with a lot of HN readers.

In a few years we'll hopefully be out onto the slope of enlightenment, with microservices applied where they're useful and not applied where they're not. If we don't get there, then we'll just run the whole hype cycle over again with yet another rebrand of the same concept.

whack2• 2 years ago

being completely convinced that one way of doing things is always wrong and one way of doing things is always right, and that people doing things the other way are just ignorant/stupid/wrong
people who talk/write like this usually have no idea what they are talking about

According to your heuristic, you have no idea what you're talking about?

In all seriousness though, your comment comes across as unnecessarily personal. I disagree with the OP's conclusion, but he raises some interesting arguments on an interesting topic. I came to the comments to see a technical discussion around the pros/cons of microservices. It's off-putting to see that the top comment is an ad-hominem attack

lolinder9• 2 years ago

I think you might have misread OP. The first quote you extracted isn't their description of the author, it's their description of what the author is conveying in TFA, and that's honestly a pretty accurate way to capture the piece. TFA's section giving the reasons why you might consider a microservice architecture basically boils down to "if you already have microservices, if you absolutely must use a different language, or if you're an irresponsible idiot". That's not the attitude of someone who is open to the idea that someone reasonable might make a different choice than they would.

What OP actually has to say about the author themselves is that people who write like that "usually have no idea what they are talking about", which is also absolutely true in this case. There are many tells throughout the essay that give away that the author has very little experience operating any type of system, microservices or otherwise.

richardfey• 2 years ago

You are absolutely spot on.

i_am_a_peasant• 2 years ago

I can agree halfway, thing is many times "it depends" is such a non answer. like it always stops with "it depends", not "in this case you do x, in this case you prioritize other things and you do Y"

slurpyb• 2 years ago

Only a sith deals in absolutes

yanis_t• 2 years ago

I wish we had more articles not about what good practices are, or how things should be designed in theory, but rather about how to enforce those practices in a large organization, when you are not necessary a guy who makes decisions.

Joel_Mckay2• 2 years ago

Unfortunately, the "wisdom of the tribe" cannot be written down for the laymen.

Most juniors can't look at a design-pattern, and somehow immediately understand why it is good or inappropriate.

Almost all recent grads are similar to the following fellow:

https://en.wikipedia.org/wiki/Eddie_the_Eagle

red_admiral2• 2 years ago

when you are not necessary a guy who makes decisions

I think a lot of it comes down to: if the guys who do make decisions make them badly, stuff is going to suck. You need the right people at the top.

CuriouslyC2• 2 years ago

While I hate the cargo culting of microservices, there is one use case they handle very well - reusable services with obnoxious dependencies that don't really need to be integrated in with the rest of your codebase. I would much rather take a docker image of a whisper or text-to-speech service and add it to my compose file and call it via HTTP than try to wrestle a CUDA build and get whisper/TTS bindings working for every language where I might need them.

mind-blight• 2 years ago

A similar case for me has been processing large files. It's really nice to be able to scale up the memory of the file processing server when there are large files being processed, they scale it back down for normal usage

_heimdall7• 2 years ago

Microservices can also be a great fit for certain team/org structures. Its not ideal to pick the tech based on the team structure, but that's life.

I've also found it micro services helpful for heavy data processing projects. A micro service architecture driven by events as data is processed and moved through different steps can be a surprisingly simple setup to reason about and debug.

alephxyz• 2 years ago

The author seems to be assuming that microservices are only used to break down a single application into different services, in which case their arguments are valid. If you instead consider that a single service can in fact be used by multiple applications, most of their arguments are plain wrong.

For example: >Why would you ever want to allocate more resources to one particular part? It’s not like the other parts will eat up the extra resources. If your system needs more RAM, it needs more RAM. Why would you care about which part needs more RAM?

icholy• 2 years ago

There's a benefit of microservices that I don't hear talked about. At my workplace, there's absolutely no respect for api boundaries. Devs will monkey patch and reach into other module's internals without a second thought. I can't imagine the monstrosity that would exist if the network boundary wasn't there to stop them ...

duxup• 2 years ago

Microservices (like a lot of things) might just be there to solve human developer problems as much as anything else.

There are times where I'm all "No the authentication service is doing great, leave it alone!!!".

aitchnyu• 2 years ago

We can enforce module boundaries in code with tooling.

An example for Python: https://github.com/gauge-sh/tach

NoGravitas• 2 years ago

That's just another way of saying that microservices don't solve a technical problem, they solve an organizational problem.

BillyTheKing• 2 years ago

yes - and writing code also doesn't solve a technical problem, a computer runs fine with 0s and 1s, no need for code, in fact code produces a performance overhead - but it solves a human abilities problem, namely that 0s and 1s aren't particularly expressive for us. Almost everything we do solves for communication, some things on an individual scale, like programming languages, and other things on an organisational scale like micro-services (I'm also not blindly advocating for micro-services, but I do get why if done somewhat competently it's easier to organise a team of 1000 developers into 50 teams of 20 each responsible for one service rather than 1000 developers responsible for everything)

kgeist2• 2 years ago

Devs will monkey patch and reach into other module's internals without a second thought. I can't imagine the monstrosity that would exist if the network boundary wasn't there to stop them ...

We have a tool in our modular monolith, which is like a linter which checks architectural violations like that. If someone tries to bypass the API layer of a module and peek directly into the internals, it refuses to build (and CI/CD refuses to deploy/release). No need to replace a basic linter with a network boundary...

the10243• 2 years ago

We've encountered the exact same problem in the past, and open sourced our solution to enforce those boundaries! https://github.com/gauge-sh/tach Alongside CODEOWNERs, you can effectively constrain teams to focus on where they need to be.

10000truths• 2 years ago

You don't need network level separation for that, UNIX sockets and pipes are just as effective at enforcing those boundaries.

vilunov• 2 years ago

What's stopping them from violating network boundaries?

immibis3• 2 years ago

the network

the10243• 2 years ago

Typically teams won't have access to the code that's being deployed on the other side of the network boundary. This physical separation is overkill though; something like CODEOWNERs and https://github.com/gauge-sh/tach can do this without incurring remotely the same overhead.

huygens63633• 2 years ago

Microservices are not solving a technical problem. This is related to another issue: many technical people think tech is the hard part. Technology is the easy part. If you think the tech is hard, you have no idea how hard The Rest is. I know it sucks, but the sooner you learn this the better.

twelfthnight3• 2 years ago

So true. Communication is insanely difficult. Hiring competent, motivated engineers is insanely difficult. Working around short-term thinking executives is insanely difficult. Iterating until you stumble on a success product is insanely difficult.

How often does anyone talk about these problems in meetings? It's wild, I feel like all I ever do is argue over mostly irrelevant technical minutia.

huygens63633• 2 years ago

Exactly! It's this huge elephant in the room and all we want to talk about is our editors and how Java is faster than Go or whatever.

I'm sitting in this meetings thinking "Guys, using XML or JSON truly, truly does not matter here. You have already wasted months on this shit and the value meter is still at $0. I'm telling you we can make this work with either Scala or 6502 assembly or anything in between. What matters is that we need a coherent vision, formulate actionable goals and work on improving our communication and keeping it there."

Maybe I need to go into management? (/s ?)

nikau• 2 years ago

welcome to bike shedding

https://en.wikipedia.org/wiki/Law_of_triviality

hakunin4• 2 years ago

Trying to solve a communication problem with more code and infra is often a mistake. This is something many engineers don't realize they're essentially doing. Some communication problems can be somewhat alleviated by processes and technology enforcing those processes, but you must always consider the cost, and weigh it against alternatives that don't require engineering overhead. In almost every case like this, increasing the amount of code and infrastructure is the wrong option.

from-nibly2• 2 years ago

Yes, but Conway is not wrong

mattgreenrocks3• 2 years ago

If you think the tech is hard, you have no idea how hard The Rest is.

If people/orgs really believed this, they'd keep headcount as minimal as possible.

DowagerDave• 2 years ago

Don't they? The only experience I've had where this isn't the case is startup mania, where gasoline is poured over open flame.

red_admiral2• 2 years ago

I always thought microservices did solve a technical problem, but one that only appears when you're the size of Twitter or similar. I would agree with you for the huge majority of companies that don't build their own datacenters.

huygens63633• 2 years ago

It's an organizational pattern. I've seen it being used at very small companies to good effect. It matched their (dysfunctional) culture: islands, little communication, etc. Working on a monolith together is a nightmare if you hate each other.

zelphirkalt• 2 years ago

It depends on what kind of tech we are talking about. Making a truly good and flexible tech product is truly hard. There will always be someone arguing YAGNI at inappropriate moments, influencing design negatively in ways, that will usually never be overthrown again, because of the additional mindset of not wanting rewrites and mindset of not wanting to change a (halfassed) working system.

intelVISA3• 2 years ago

Many vogue tech decisions are over-engineered band-aids for organizational dysfunction.

skwirl• 2 years ago

There certainly are many cases where microservices are used where they are not actually appropriate, but this entire post just betrays a lack of experience working in a large monolithic codebase with many engineers.

Octokiddie• 2 years ago

Microservices are the Wrong Answer

The author never states the question. This makes it impossible to evaluate the answer, which presumably is stated in the title. The article would be much stronger with a clear statement of the perceived problem that microservices solve and why modules are a superior solution.

DeathArrow• 2 years ago

Probably the author never worked on large projects that need to scale. Almost no one of his objections does make sense. Imagine Facebook, Uber, AirbNB, Google as monoliths.

dave1999x• 2 years ago

His LinkedIn is on the article. He has 3 years of professional/non academic experience so you're highly likely to be correct.

nasmorn• 2 years ago

OTOH I only know micro services from 5-20 dev teams where they made no sense whatsoever.

krab2• 2 years ago

Tell this to Instagram or WhatsApp before acquisition. ;-) They have scaled well enough, IMHO.

On the other hand, I agree that for the larger teams, microservices make sense. It's much easier when you can roll back a failed deployment and block new releases just for your service, while the team tries to fix it. Also, monitoring and resource accounting is easier. All at the cost of some inefficiencies compared to a monolith.

disgruntledphd22• 2 years ago

Yeah but all those companies invest an absurd amount into tolling to make this practical, and they AFAIK don't do insane things like having separate databases for individual services.

netdur• 2 years ago

got it, I will not build micro services, I will build just regular one.

tombert• 2 years ago

Honestly I never really understood the hatred that people on HN have for microservices. Everyone acts like "OMG THEY'RE SO COMPLEX!!!!", but a) that's not unique to microservices, b) monoliths aren't somehow immune from this complexity, and c) most big systems end up getting pretty complicated regardless of the model.

Yes, Kubernetes is a pain in the ass, and libraries getting out of sync can be real problem, and distributed systems are inherently difficult, but I think that the benefits of something like event-sourcing with lots of individual, self-contained, "I don't care where this data came from" services outweigh a lot of the complaints. It's not like most of us are reinventing Paxos every day; we're using well-tested off the shelf components like Kafka and Consul and RabbitMQ.

Also, I don't really understand the author's point about individual scaling not being a good thing. It can be very hard to measure things like memory usages for individual components of a huge service; the smaller and more atomic the service is, the easier it is to find out how many resources it actually needs. With a big ol' monolith, it seems like people just go off intuition (AKA self-righteous guessing).

I dunno, even for home servers, I still basically do the microservice model. Maybe I'm weird.

solidasparagus5• 2 years ago

I never really understood the hatred that people on HN have for microservices.

If you're an early stage company and just trying to ship something with a small team, the overhead of microservices (testing, deployment, monitoring, platform infra such as k8s, etc) can be pretty obnoxious (like an order of magnitude more time than the work to actually deliver business value). And microservices give you enough rope for one overly clever person to hang the whole team, so there are definitely some traumatized developers out there.

If you are doing something simple enough, throw it in a single docker container and spend your time focused on building something useful.

photonthug3• 2 years ago

This is all true, but I think tends to cover up root-causes.

Over the last 5-10 years, tons of people got jobs on the strength of "k8s experience" which was more like "I was on the software-side of an application development that was deployed with kubernetes once" and then got hired based on that as if they had architecture and infrastructure experience/expertise, when they actually don't have either one.

So yeah, when you need 6-8 months of on-the-job training for your "experts" to get some expertise, that will set you back 6-8 months when it comes to productionizing your product (assuming the product itself is already finished!). It's not the sheer amount of work that's involved with microservices vs monoliths. It's the skill set, which is large enough that you can't get it overnight. Even setting aside the wider ecosystem and just counting the number core concepts at play, it's easier to pick up a new programming language than to learn kubernetes architecture/administration/operations.

Startups (or a company of any size that simply doesn't have the ability to evaluate candidates) will be better off if they won't saddle themselves with full-time people of questionable qualifications, working instead with some limited-engagement technical consultants and contractors in a tactical way. Contractors like this will have actually solved the problems involved multiple times and will probably have bootstrap-a-whole-org testing/deployment/monitoring code in their back pocket already.

To me it seems like all this is the predictable downside of the whole "full stack engineer" thing. A server-side language + html/css/javascript can probably fit into the average human brain, but even there it seems misguided. Once "full stack" is further twisted to mean SWE+Infrastructure+Platform+Cloud+Architecture and then you throw in a little "No-Ops" and "Low Code" optimism, then it's getting unrealistic, but naive management will imagine anyone can do anything and it's all very easy. It is easy, but not anyone can do it. Expertise is required, especially during design/bootstrap phases. As a company you don't have to buy that expertise forever with a FTE, but you also can't just assume you'll multipurpose some existing FTE for this stuff if they have less than adequate experience.

hubraumhugo• 2 years ago

This parody sums up the issues with mircoservices very well: https://www.youtube.com/watch?v=y8OnoxKotPQ

c0balt• 2 years ago

Tbh, the best way to do this is likely the hybrid model adopted by, e.g., gitlab rails and Grafana Loki etc.. air usually let's the operator select if they want to run as a monolith, service with multiple components where some are instanced, and full micro service mode.

For small deployments you can just use the monolith and be done with a single "service" while you still have the ability to scale out for large deployments. This gets even better when they allow you to do an in between where one component does A and B while only C is handled by micro services.

nallerooth• 2 years ago

Self-confidence is good. On the other hand, too much self-confidence means disaster. - His holiness the Dalai Lama

I guess it's true for microservices as well.

rswskg2• 2 years ago

I lol'd when I got to 'Why would you ever want to allocate more resources to one particular part? It’s not like the other parts will eat up the extra resources. If your system needs more RAM, it needs more RAM. Why would you care about which part needs more RAM?' and stopped reading.

didip• 2 years ago

Microservice design is a solution to scaling up people in a large organization.

Regardless what HN people believe, some people like & proficient in a few languages that may not match the existing codebase. Eg. 50% of the team is Go enthusiasts in a Java/Python shop.

Microservices solve that. If your company is tiny, you don’t win much using microservices.

elktown4• 2 years ago

It's also an excellent way to create large organizations due to the complexity chain reaction it seems to kick off.

norman784• 2 years ago

I would love the day when WASM + WASI fulfill their promise and let us write our modules against an interface so you can easily swap the underlying implementation without changing something in your app, this way I can care less if I'm running a microservice or a module, let that decision to the devops/management team.

immibis3• 2 years ago

C FFI and machine code already accomplish this. The reasons you wouldn't use C FFI and machine code are the same reasons you wouldn't use WASI and WASM.

brunoarueira• 2 years ago

The main problem with adopting microservices is the hype and many times the person who defends it doesn't have enough data! "We'll rewrite this into technology X, because this doesn't scale", but sometimes anyone measured it, tested or doesn't have a good knowledge about. Another common pattern is if a module is buggy, you start to listen people screaming that this need to be a microservices. My basic thought is to write modules and when non core features evolve in such a way that the team needs to be splitted, demanding more allocated people, this features needed to move somewhere and at that point the projects will benefit!

rcleveng2• 2 years ago

Separation is a critical part, and that could be modules that form a separate microservice, or split off into it's own "macroservice", the mechanics are the same.

I've seen many cases where there is a service that does like 3 things. 2 of them are low importance and one of them super critical. A low importance one will have a bug, crash, introduce latency regression, etc and take down the critical one.

Time to separate the critical one into it's own deployment to isolate and improve reliability.

The other is on trade-offs, super important that every decision makes has them, just respect that and realize the answer is often "it depends".

fire_lake• 2 years ago

The fault tolerance aspect is underplayed here. Different modules might have different reliability and uptime requirements. I don’t want an unreliable module without SLAs running on the same instance as something on the critical path for users.

basfo• 2 years ago

Why would you ever want to allocate more resources to one particular part? It’s not like the other parts will eat up the extra resources. If your system needs more RAM, it needs more RAM. Why would you care about which part needs more RAM?

Looks like resource isolation and avoiding a non performant piece of code to bring your whole system down is overrated.

Just scale vertically! Get a bigger instance!

rcleveng2• 2 years ago

Just scale vertically! Get a bigger instance!

That works great until it suddenly and unexpectedly stops working.

kgeist2• 2 years ago

We use a microservice architecture at the company and like every second incident is a cascade failure which is actually harder to monitor and manage... And having microservices doesn't help.

Things like, someone forgot to batch the events when posting to the event bus so a large tenant generating many events suddenly overflowed RabbitMQ which ran out of memory and started blocking producers who are holding DB connections and so we're out of DB connections now and the whole thing goes down. The only difference is that when it's going down it's harder to understand who's calling who in all this mess (compared to a single beefy server).

steve_adams_86• 2 years ago

I’ve yet to see an article which explores the pros and cons of different strategies and demonstrates each with examples rather than picks one and insists it’s better for arbitrary reasons.

I’ve used microservices, monoliths, serverless, and other similar permutations based around different core architectures (event buses, peer to peer, client-server). Some aspects of each were awesome. Some weren’t. Knowing why and how/when to leverage each is far more interesting than demoting or excluding a solution because you like another one more.

There are some suspicious ideas in here. “If your system needs more RAM, it needs more RAM. Why would you care about which part needs more RAM?” I suppose. But what if I only spin up a service once per day, and it needs far more ram than the rest of my system? I should use those resources for the 23 hours of the day that I don’t need them and pay for them nonetheless? It I don’t own my hardware, that’s an insane waste of money. Sometimes ephemeral services are a huge cost saver even for smaller teams… And it isn’t strictly due to poor communication. It’s a legitimate challenge presented by resource and finance constraints.

“Microservices introduce a lot of overhead in terms of communication latency” - sometimes this is perfectly acceptable. Say you have jobs you need done, and sometimes it goes from ten at a time to perhaps 100. A monolith would get bogged down severely. The client’s expectation of having the job done is likely not instantaneous if it’s something that needs to be sent to a queue. In this case, ephemeral job runners make sense. They can take on however many jobs they can at once, and if they’re maxed out, spawn another worker. This does not work well with monoliths in my experience. The communication overhead doesn’t matter here, as it could be worse if the monolith is bogged down while working anyway.

There’s more I don’t agree with, but I don’t claim to be a seer or anything. Maybe I’m just old and incapable of learning (though I do like the module approach as well).

nijuashi• 2 years ago

To be frank, this is a terrible advice. I’m certain this person, given enough time, will come to the same conclusion as he/she is exposed to different projects and organizations.

As many posters here state, there are many instances where services are loosely coupled, developed by different team and/or at different time, and makes no sense to make into a monolith.

As you may not benefit from shoehorning a well-maintained monolith into a microservice, the opposite is true.

rysertio• 2 years ago

Am I the only one who uses microservices to deploy small monolithic projects?

whack2• 2 years ago

My intuition is that at a certain scale, microservices are preferable to a monolith. Two principled reasons:

- Autonomy over deployment rollbacks. If your team owns a microservice, and you noticed that you deployed buggy code, you can easily and autonomously do a rollback. Your rollback doesn't impact other teams. It isn't visible company-wide. This allows teams to take more risks with fewer downsides and more psychological safety

- Isolation of secrets, api-keys etc. If one module has access to an api-key, then it's effectively made visible to every single module in the monolith. Other teams can decide to bypass your API entirely and read directly from your database, making it impossible for you to abstract away your implementation details

Problems solved by microservices that could in theory be solved in a monolith:

- Build/test times. A big monolith will have a huge build time and a large number of CI/CD tests. In theory you could parallelize your build/test-suite to make it infinitely fast, but I'm not sure how practical this is

- IDE slowness. A monolith will make your average IDE run much more slowly. In theory also solvable, but would require major IDE changes and investments

- Code ownership by specific teams. In theory you can use things like regex-CODEOWNERs to enforce code-ownership of individual modules, but it's easier with microservices

- Migrating to better languages/frameworks. If your original monolith was written in perl or on a bad framework, it's very hard to move away from it. With microservices, each microservice can be independently and incrementally migrated, allowing the company's tech stack to evolve gracefully.

Any others I missed?

lolinder9• 2 years ago

One that I don't think a monolith can solve is partial availability.

A monolith is either available or it isn't, which is fine as long as you can guarantee that nothing ever takes down the monolith, but we all know that that's not something you can guarantee.

If you split out services that live outside the critical path, then when those services go down you can still engineer your system to keep going and gracefully degrade the functionality provided by those currently-down services.

This makes incident response much less stressful because there's less urgency, which in turn leads to fewer mistakes during the response and faster recovery times.

(Yes, there are some pieces of functionality that will always be in the critical path, like authorization, but many things don't have to be.)

ziml77• 2 years ago

This is why I like having things split up. Even with zero service redundancy, it massively improves the reliability of the system overall. Often users don't even notice that a less important service had to restart because of an issue. If that service was just another component of a monolith, then it failing would guarantee that the whole monolith fails.

anothername12• 2 years ago

In my experience you’ll be fine with monolith instances and failover. Probably until you’re Google scale

krab2• 2 years ago

Not really. Even with a monolith, you get partial availability. Most often as a default.

Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available.

Then, you have some background workers, maybe ingesting data from third party services. They're completely different processes from your web servers, even though they still use the monolithic code base. If they're down, the web app can still work with stale data.

The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned).

intelVISA3• 2 years ago

Modulith is the underrated happy middle ground imo.

the10243• 2 years ago

Google famously still primarily maintains a monorepo, but they absolutely don't deploy a monolith. They published a paper last year that describes an approach that is quite close to what they have internally - https://dl.acm.org/doi/pdf/10.1145/3593856.3595909

Effectively, by setting strong boundaries between modules, they can develop on their application as if it was a monolith, but at runtime, separate those modules physically deploy them as micro-services. This solves a lot of the versioning issues (since the app is rolled out atomically) and correctness issues (easier to reason through a monorepo).

elktown4• 2 years ago

Not sure if there's any other profession than software that has such a hard time with proportionality. We can seemingly with a perfectly straight face argue that yes this massive Rube Goldberg machine was required to avoid that small nuisance that feels wrong but actually isn't something that consumes time at all.

Imagine if a carpenter or plumber acted like this; having self-fulfillment as prio 1, 2, 3 in all cases, not outcome. They'd never get hired again.

jiggawatts• 2 years ago

Microservices are just Enterprise Java Beans reinvented, but without the efficiency.

At least with EJBs we had the option of bypassing the network layer and having tightly coupled services communicate directly in-process.

Someone looked at that and thought: “Too efficient!” and made the network step mandatory.

This is how we ended up with web apps like Jira that take a solid minute to open an empty form.

supermatt• 2 years ago

So I can just rename my "microservice" to "module" right? That is all the author seems to have done in my eyes, but then also thrown away the bits that make it scale - for no less complexity.

First of, I am going to disagree with the microservices.io definition the author references, because it is short-sighted and ends up contradicting itself when talking about assemblage. Chris Richardsons book is definitely worth a read, but we clearly come from different worlds when it comes to a core belief of microservice architecture.

Too many people who complain about microservices are clearly unaware that a microservice doesnt mean remote, or distributed. It can have local transport - even a simple function call - which is the same as the "modular" approach the author dictates - but is also more flexible in that you CAN have remote transport with no additional effort because the service locator handles it for you.

Its just building your code in a modular way, with a defined interface between isolated components, a service locator (this is effectively an index of your modules (microservices) and where they are located - local, remote, etc) and some mechanism to call them based on the supported transports (thread local, RPC, whatever) of that "module".

It can all reside in a single repo. Your microservices can all be compiled in a single app, your service locator can be a switch statement, and your transport can be a function call. The only requirement is that they never perform a task that another microservice can handle - and if we were just talking programming, we would just call that "modularization" or using DRY principles! Microservice architecture is just non-monolithic DRY.

Anyone NOT writing microservices that way is just making life hard for themselves and probably hasn't read even the most archaic book on microservice architecture. Remove the remote transports, and you have a well built, domain driven monolith...

zubairq• 2 years ago

Having worked with several systems using both modules and micro services I would say that using modules is the way to go from a debugging and understandability perspective, so modules are a more productive method.

However micro services can still be valid but to me they are actually “developer UI” and should only be used when services have to be shared between developers who don’t know each other. For example a public API will almost always be an API with a micro service behind it

namaria• 2 years ago

Don't take design advice in a vacuum. Think about the problem at hand, the constraints and the people and organizations involved, and design something appropriate to that context.

kodama-lens• 2 years ago

While I don't agree with quite some assumptions and comparisons the author makes I tend to agree that microservices are often not the right answer for your problem.

They can be great when:

* You need just one function that is not directly related to your core application logic and might be needed by other service. Great usecase for a microservice or lambda

* You need to separate statefull and stateless components

* Have async workflows

* Scaling to infinity and beyond

But most don't application problems don't have these requirements for it's core logic. Microservices have a huge cost. Code and dependency dublication, complex deployments, latency, harder debugging and tracing and the cognitive load is much higher.

A lot of read blogs and new form netflix and google and want to do the same. The management of my current project is asking for microservices because it is the new hot sh*t, so teams are doing it just like SAFe and AI - even when it does not help to solve the problem.

0x63_Problems• 2 years ago

Probably the most formative experience in my early career was seeing a massive (attempted) rewrite from a monolith to microservices. Multi-unicorn company spent a year and $Ms in developer hours just to realize that the network separation did more harm than good. There are use cases for network separation (fault tolerance, independent scaling, polyglot teams etc.) but for essentially every startup I've been at, the better bet is to enforce logical boundaries in the codebase itself.

YektaDev• 2 years ago

Thank you to everyone who contributed insightful thoughts and feedback on the subject. Your input has been invaluable, and I've taken the time to revise and improve the article.

Don't microservice, do module

Related Stories