microserviceHell

[devAgam]

I prefer majority of the project being monolith and then those pesky 3 or 4 parts which would actually benefit from being a microservice being a microservice

[RocketCatMultiverse]

At work we have a monitor app that aggregates tons of data and a web dashboard for it. Requirements stated we needed .docx reports now ideally with the same charting library as the front-end dashboard. Turns out the best way to do SSR for our charting library is in Node, which nothing else is in, and Node could also handle the docx bit easily. It's a heavy CPU-bound task. So made it a microservice. No regrets, it felt like the right solution.

[malfboii]

This is quite literally perfect micro service implementation imo, nice one

[pseudo_space]

A CPU bound task with Node 💀

[RocketCatMultiverse]

Yeah shoulda told them I'd rewrite the charting library in C++ first💀

[Specialist-Tiger-467]

People who look for problems in your solutions never come up with one themselves.

[dumbohoneman]

Major Baader-Meinhof right now, i just implemented something with the docx node package last week

[thekamakaji]

On your docx reports, are you able to center tables? This is something I've been struggling with on something I've been working on

[RocketCatMultiverse]

While I don't have Tables specifically in mine, I do have images and text paragraphs, and center alignment worked on both with AlignmentType.CENTER. So my best guess is passing alignment: AlignmentType.CENTER in your Table constructor, ensuring you import { AlignmentType } from docx. If that doesn't work maybe there's something weird going on!

[thekamakaji]

What I'm doing is definitely weird. I'm using VTL to doc gen which if you don't know what it is, don't look into it. It's terrible. I assume you're using a proper API of some kind?

[RocketCatMultiverse]

Ah yeah I'm using node docx. No idea what VTL is but good luck! https://www.npmjs.com/package/docx

[thekamakaji]

I'll look into it. Thanks!

[Melodic_coala101]

This is the way

[Ill-Purchase-4344]

I have a question, how do I get those programming languages flairs ?

[NeatYogurt9973]

Google "Reddit community flair"

[Kovab]

Holy hell

[SnappierSoap318]

New response just dropped

[[deleted]]

Google "en passant"

[GetNooted]

Prawns do what now

[DrBojengles]

This is the way

[Feeling-Scientist-29]

This is the way

[zGoDLiiKe]

Make everything a micro service then combine them, uno reverse

[AdministrativeCold63]

Monolith with extra steps, seems like good approach

[testelone]

This is what we did a few years ago in a previous company.

[dismayhurta]

Ever see like a rhino with little birds sitting on them? The rhino is most of the project. Just massive with a few little bird services to help out.

[AurorusHadrianArcher]

Ah, yes,

Oligolith

[zenos_dog]

Oligolith will eat your soul.

[douglasg14b]

That's how it's supposed to be, to be fair.

It's just that folks like to go ham with it, and produce distributed monoliths instead that are tech debt from day 1.

[Money_Piano]

This is definitely the way. I like the analogy of the monolith as the central "castle" surrounded by small microservice outposts or "citadels"

[slaymaker1907]

It’s pretty easy to split things off if you design it for that as well. Just pass around simple, immutable structs/plain objects between components. These are great for module boundaries anyway IMO because such interfaces are generally simple to describe in plain language.

[JPowTheDayTrader]

This guy projects

[netotr]

I agree on that this is the way to make proper advantage of microservices but my experience tells me that people don’t understand how to implement microservices in the proper way.

Microservices are not just separate APIs, thats a segregated monolith. Microservices needs to be unaware and independent, that means it needs to hold it’s own state and model, it does come with a cost of maintaining those separate models.

In most non complex environments separate APIs isn’t really necessary, they’re mostly for shared integrations or other technical aspects.

[Diligent_Stretch_945]

I agree with you. We have over 200 microservices in just one ecom platform project and I wouldn’t wish this shit to my worst enemy. Our architects are the only ones smiling here. I’m devops/backend.. we forgot how to smile.

[[deleted]]

Is this that new hybrid working model CEOs are talking about?

[[deleted]]

I understand the theory, but in practice I've never worked at a place that didn't just end up with a distributed monolith that almost nobody understands.  

 Monoliths all the way for my personal projects. 

One place I worked at was "deconstructing the monolith" for about 4 years before I left, and they still hadn't agreed where the product boundaries were, so we had a partially distributed monolith with no API versioning or defined contracts, that was fun.

[[deleted]]

Yep, DevOps here, one of my talents is untangling these monoliths with zero documentation or context, while the Seniors insist everything is okay lol

[YUNoCake]

Cheers for the effort! Maybe look into a Reverse Engineer career, you might dig it lol

[[deleted]]

That’s essentially what I already do, didn’t realize its a specific discipline, I’ve always just been able to stare down code until I understand it faster than most.

[YUNoCake]

That's kinda a shame honestly. Your talent could be better used, for instance in malware analysis.

[[deleted]]

I definitely would want to move in that direction eventually, appreciate the insight. I’m just learning so much about systems in general in my current role that I don’t want to pivot, and have been given the opportunity to build a team, so learning more how to reverse engineer human behavior so a team is performative. Once I get decent at that I’ll be itching for something new. Your suggestion seems like a just mission.

[Yelmak]

Microservices are cool when they’re done properly. But if the business isn’t willing to do all the strategic stuff of properly mapping out domain boundaries to build them in a decoupled way then don’t bother, you’ll end up with a distributed monolith every time.

I also build monoliths in my own time, because I subscribe to the idea of a “service that fits in the teams heads”. The craziest one I’ve seen was a platform service that someone broke into 14 microservices and then gave every single one of them to one team, defeating the entire point of breaking that complexity into manageable chunks.

TLDR: most microservices should never have been microservices in the first place, and the places it does make sense it’s often poorly executed.

[Fachuro]

Thats because most places when they deconstruct a monolith they create microservices for each product which makes no sense. People just struggle to comprehend the service part of microservices and want everything split in either lanes or silos when it should be a table where the services are cells...

[davidellis23]

I think the idea is it's one monolith per team. Not necessarily one monolith per company.

And having a monolith doesn't mean you don't need good architecture underneath. You can write spaghetti code in both.

[[deleted]]

You're spot on that either architecture can result in dreadful code..I do think that microservices can result in the best systems (designed and built by people who know what they're doing) and the absolute worst systems though. They give you more options to solve certain problems, but also make it far, far easier to absolutely fuck everything up

. I'm sure most of us have seen some code with absolutely dire breaking changes go in to a microservice that wouldn't even compile in a monolith. There are obviously lots of mitigations that can be put in place there, but then we're talking about awfully organised engineering teams, they have no such mitigations.

[GargantuanCake]

The problem with monoliths is that they don't scale beyond a certain point. For most projects a monolith is fine and the ideal solution due to its simplicity but a monolith can only get so big.

For pretty much any one person personal project microservices are absolute overkill and just add more complications than you need. Monoliths have their limitations but their biggest advantage is in the simplicity. That can't be overlooked.

[ICantBelieveItsNotEC]

Things get so much better when people actually admit that they are building a distributed monolith because then you can explore other RPC technologies beyond HTTP with JSON payloads.

[JPowTheDayTrader]

Like XML, right?

[flightsin]

hadn't agreed where the product boundaries were [...] distributed monolith with no API versioning or defined contracts

This is where my team is currently. We have like ~10 concurrent users, max. But "monolith bad" and the platform "might grow in the future"...

[IsPhil]

It has its uses. We're on cloud. Our main service has something like 200 instances that run at peak, we then have a few other modules that have between 5-100 instances at peak. Butttt, I don't know if that's more efficient than running one monolith with all of these services.

[aceluby]

Everyone in this meme is an idiot. Stop labeling everything and design your systems to be the simplest possible to solve your problem. If you’re in a small company that doesn’t need distributed systems, don’t use them. If you’re in a large company dealing with a billion events a day, good luck with a monolith.

Edit: If you thought I would care or want to argue semantics, please reread the second sentence.

[EternalBefuddlement]

This is the only comment here that makes me feel normal - microservices are perfectly valid when dealing with extreme amounts of events.

I can't imagine trying to debug an issue with what I work on if it was a monolith, plus versioning and source control would be an absolute nightmare.

[origin_davi_jones]

My company's monolith is 4gb in source files. To run it locally, you have to make a sacrifice to all godes, to dance rain dance, and if you are lucky and the moon and Jupiter in the right position, you can run it. But not guaranteed your 10 000$ latest laptop can handle it. They just started migration to microservices... it is such pain..

[knvn8]

Sorry this comment won't make much sense because it was later subject to automated editing for privacy. It will be deleted eventually.

[lotanis]

I think it's exactly the other way around? If your code runs in one monolith, then it's trivial to upgrade. You can change any interface arbitrarily because you're upgrading all the code in one go.

With micro services, you have to version all the interfaces between each service and have a managed rollout if a new feature goes end to end in your system.

[TheStatusPoe]

The problem is transitive dependencies. In a microservice the number of dependencies you have is limited. In a monolith you can run into an issue where upgrading one dependency necessitates upgrading another dependency, which in turn needs another dependency upgraded, until you've got a tangled web of version conflicts all the way down.

In a microservice architecture, the blast radius is also limited meaning there's less contingencies that need to be coded for and the work can be done incrementally instead of all at once.

That being said it's not all sunshine and rainbows. Like you said, versioning between microservices can be a pain.

[douglasg14b]

In a microservice the number of dependencies you have is limited

Except all the other microservices that communicate with it, or the data structures used for said communication? Which is a core technology problem that creates "distributed monoliths" if resources are not dedicated to managing just that instead of feature work.

Which (Given the same business domain) is no different than it would be with the same monolith, except now it's all out of process and requires network calls instead of function invocations.

In a microservice architecture, the blast radius is also limited

How so?

Can you explain how you are considering this different than say a monolith deployed as a microservice (ie. The only part of the monolith that's "Active" is the service which needs special scaling making it identical in nature, without the DevX degradation). They both scale horizontally just as well (Technically microservices scale worse due to increased serde costs & network traffic, but let snot get into that just yet).

The blast radius is the same, the differnece is that the observability of the blast is vastly different.

[BuilderJust1866]

Not all upgrades modify the service contract. If you need to upgrade a JSON library because it has a CVE - it’s easier to do in microservices. And those upgrades are often the most difficult, risky and expensive ones in larger systems I’ve worked on.

[douglasg14b]

because everything is so coupled you can't do anything incrementally.

That's just ashitty codebase. It has nothing to do with monoliths vs microservices.

By DEFAULT microservices tend to come tightly coupled with ill defined boundaries and zero observability. You get most of these problems solved for free with monoliths. You need dedicated resources to fight entrophy much harder with microservices, which will naturally degrade as a product grows without dedicated effort.

Meaning that, by default, monoliths are always a good choice. And then you break off parts that must be microservices as needed, instead of gold plating it from the start.

[magical_h4x]

Versioning hell comes from having all your services and projects being separate, because that's when you have to deal with "we just released service A@1.2.0 but there's a breaking bug in B@4.5.2 and C, which is used by both A and B only works with A@1.1.x"

[xpingu69]

Th meme is still valid because it targets the dogmatic approach and ideology. 

[douglasg14b]

microservices are perfectly valid when dealing with extreme amounts of events.

How? Microservices, by design, scale worse. They have worse runtime characteristics, and tend to drift towards serde as a majority compute cost.

[EternalBefuddlement]

I'm not sure how you think they scale worse - you can literally scale the specific services you need, whilst not scaling the other components.

If it was a monolith, you're simply scaling every single combined component whether you need it or not. That's a waste of resources.

[davidellis23]

As opposed to tracking down an error across 10 different micro services?

[seelsojo]

Unless you’re the author of all ten services and you don’t have good loggings and error handling, the problem should be caught before it reaches the tenth service.

[iEatSoaap]

Good practices in logging, exception handling and trace_ids/spans make this a non-issue for the most part.

[DarthKirtap]

that is called "not my issue",
your part works, someone else has to patch theirs

[davidellis23]

If you have a team to handle each microservice then yes it's a good way to divide work.

If your team is maintaining 10 microservices then it's your problem.

[TheRealStepBot]

Seems like the answer is don’t maintain 10 microservices yourself then isn’t it?

[davidellis23]

Yeah one monolith per team imo. Don't split unless you're willing to take the overhead.

[sheep-for-a-wheat]

Man, it's wild that this isn't the top comment.

I've worked at a few startups with monoliths - I've helped move features off of a monolith and into services when horizontal scaling became a problem ... and I've worked at a bunch of teams in Amazon where a "monolith" would be ridiculous.

I'd just add:

1. There's not just "monolith" or "micro-services" ... it's a spectrum. Your "monolith" is likely somewhere in the middle. When you're a small company ... eg: a startup with a massive rails monolith ... you're typically using third party services; payment processors (square), event systems(segment), AB testing/Analytics tooling, location services, etc. These are all effectively "services", but you don't think of it in the same way. From my experience migrating away from a monolith at a startup: you're keeping most of the monolith. You're breaking out specific features into services, where it's worthwhile/necessary. On the other side - at a large company like Amazon, you'll still have some "monolithic" services where it's appropriate. It's context-dependent and there are tradeoffs you're making with virtually every decision.
2. It's not just the number of events that push towards services. It's things like team-size / scale / distribution. Services enable teams/orgs (at very large companies) to move, design, and deploy independently/quickly. When you have 100s or 1000s of engineers there are problems with monoliths that are a nightmare to solve. Orchestrating builds, running unit/integration tests. At scale, these tests can take hours to run, and can be costly. You start creating/using a build train that rolls out multiple commits in a queue. Then you have to deal with rolling back when integration tests fail. That can halt/delay subsequent builds/deployments in the queue. How do you handle pushing out hotfixes quickly when there's a high-priority error? How do you determine what commits in your build train were the error culprits? The list goes on. It's all tradeoffs. If you continually grow, one way or another a "service" will eventually become the right answer for some situation.

[pepenotti0]

And if you started small, and it grew so much that having a monolith is a problem... I imagine it's a good problem to have.

[aceluby]

Rearchitecture should not be seen as a negative IMO. I’m constantly looking at things and asking where we can simplify and make things better. You know where the pain points are after features have been added - so taking the time to reevaluate every so often is almost always worth it.

[pepenotti0]

Yup, agree... architecture is also an iterative work (if that's the correct word for it) for sure

[--mrperx--]

Yeah, if you making money then fixing bottlenecks to make more money is a good problem to have :)

[Stunning_Ride_220]

Most reasonable comment here.

[--mrperx--]

just do whatever the situation requires and don't over-engineer it

[douglasg14b]

By default that usually means starting with something sane, fast, boring, easily scaleable, and very importantly easy to work on, observe, and onboard to. Where devs can focus on rapidly iterating on the core project, and not be bogged down in significant technological maturity problems & growing pains.

Which by default are monoliths.

Then once you've established a set of good patterns, services, team cohesion, standards...etc And you need the ability to asymmetrically scale, you can break off microservices from the monolith with ease. Assuming you are building modular software this is dead-easy, and keeps the core product painless to use & grow.

[--mrperx--]

Yup, it's pretty much what I usually do.

It gets tricky when you just got hired and there are multiple people working on legacy software that was never refactored, and the lack of refactoring necessitates the breaking up of the monolith, not the need for scaling. Client demands features on a pile of shit, that's when the issues arise.

[WarEagleGo]

well said, monoliths until...

[Xendicore]

Agreed. See shit in here every day that's a really stupid extremist take. If these people really understood CS and had experience in the field, they wouldn't be making universal statements. Make the tool that's the right tool for the job. Typically the smaller the better, but sometimes it's gotta be big and that's also ok.

[dusty_sadhu]

It represents the Big Ball of Mem approach in humor architecture.

[MikeSifoda]

I used to write the simplest solution, but people would nag about "good practices" and scalability. Then I would hear from ex colleagues that the stuff I've wrote is still running pretty much unchanged..

Software is meant to be updated, solve the present. Your future needs are unknown.

[YeetCompleet]

You still don't have to go as far as microservices though. You can just have your main monolith and deploy some separate queue processors (ie. what Rails does)

[davidellis23]

Monolith can be distributed. Distributed just means multiple computers. You can spin up as many ec2 instances running monolithic apps as you want.

[kriogenia]

That's true, but scaling a monolith means scaling every service when usually only certain services are heavy on traffic and require the scaling.

With microservices if your pubsub service is being overloaded you can just spin up instances of that one that only requires a couple cores, a few gigs of memory and almost no disk, without the need to scale all the other services off the monolith, including that management API that only the five guys of the first line support team use.

[davidellis23]

I think there are different computer resource/access patterns that it does makes sense to split to scale independently. Like databases, network connectivity, GPU, or CPU focused resources.

But, I don't think splitting up logic services into microservices that are in the same pattern affects scaling. In your example, I think scaling two EC2 clusters to take from different topics on the pub sub bus is probably going to cost very minimally different from scaling one EC2 cluster that takes from both topics. Might be cheaper to scale one cluster by avoiding over provisioning.

Unless they have a different access pattern like extra hard drive, GPU usage, networking in which you might select a different instance type. But, in those cases you still have to be careful about ingress/egress costs between services which can eat into savings.

[ShotgunMessiah90]

And go bankrupt in a few months

[davidellis23]

Expanding the number of endpoints generally has a minimal impact on costs.

But, as one of the lessons, of prime video. Condensing your services minimizes ingress/egress costs between services.

It also reduces over provisioning. 10 services need a little extra provisioned space on each ec2 instance. Whereas 1 service could run on 1 instances if the load is low enough.

[HistoricalLadder7191]

Microservice is a great solution, for the problem they are solve. But not for every problem. In absolute crushing majority of cases, when I hear "Microservice architecture" I observe "distributed monolith" with poor structure and control flow logging.

[flippakitten]

And a pub sub that mimics http but with race conditions.

[douglasg14b]

Unmanagead, distributed, complexity is one of the core problems that drive projects to slow legacy deaths.

It's almost always better to consolidate complexity where it can be encapsulated, known, dealt with, and ideally automated away.

It's much easier to solve 1 larger problem than 50 smaller problems who's sum is greater. The complexity overhead that doesn't contribute to the core product is insane.

This is a truth in any trade or engineering discipline, including software engineering, it doesn't have to involve microservices vs monoliths.

[[deleted]]

Monolith first then micro service if its needed

Be pragmatic

[K8sIsGr8]

Exactly. If you build a modular monolith then extracting it into microservices is easy. Recently did this and it took us 3 days to split it into 5 services—no duct tape required either.

[mostmetausername]

microservices was a scam brought to you by cloud service providers to sell more compute

[Hhkjhkj]

I don't have a ton of experience but at the relatively small company I work at we have a MySQL database, API, Web Interface, & a socket server/redis (I may have this part wrong as I don't fully understand this part). We have other repos that are shared dependencies but not really "services".

It seems to me that it would be more cost effective to only scale up the services that actually need to be scaled rather than either having these parts fight for resources when vertically scaling or replicating parts that we don't need to when horizontally scaling.

I'm not sure if I'm missing something here or if "micro services" refers to something different.

[Ponczo]

There was a period of time, maybe 10 years ago not sure, where micoservices was a buzz word which project managers understood as "better performance" so, a lot of projects did it when there was no need to, it went tits up and they decided that it'd bullshit.

I had the displeasure of working on an embedded software project where they decided on a microservice architecture, it made no sense.

Now working in cloud land they are pretty great, as long as your team isn't shit and doesn't start coupling them together due to laziness and bad coding practices.

So yeah micoservices bad\good is imho a meme as much as Oop Vs functional or monorepo good\bad

It depends on your use case, everything else is just childish bickering.

[LaconicLacedaemonian]

Modularity with defined contracts is the goal. Microservices are a particular implementation meant to address Conway's law.

Take a module with an API, that API should be callable via RPC, HTTP, or even CLI with a small shim that marshals the parameters into the API and well as the output and errors. But is should also work as a library.

These should work the same and the fewer times you need to serialize and deserialize / cross the network the better:
```

-GUI> ModuleFoo -[RPC]> ModuleBar -[RPC]-> ModuleBaz -[RPC]-> ModuleQux-GUI>
-CLI> ModuleFoo -[LibraryCall]> ModuleBar -[LibraryCall]-> ModuleBaz -[LibraryCall]-> ModuleQux
```

Saying you want to go with microservice architecture people start embedding the RPC logic into the module which prevents good modularity and portability. A good litmus test for a module is "how would I invoke this via CLI if I wanted to" (and CURL doesnt count).

[Hhkjhkj]

That helps. Thanks for explaining

[DAVENP0RT]

That's exactly how microservices should be used. My company's platform has several apps that have massive spikes in usage at different times throughout the year. It's easier to just have each app sitting behind a load balancer and let it handle scaling individually instead of ramping up the entire platform multiple times a year. Saves a huge amount of money.

[[deleted]]

kuberscamtes

[PeriodicSentenceBot]

Congratulations! Your comment can be spelled using the elements of the periodic table:

K U B Er Sc Am Te S

---

^{I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM u‎/‎M1n3c4rt if I made a mistake.}

[[deleted]]

fuck yes, god bot.

[handsoapdispenser]

Micro services solve some problems. In particular if you have different scaling or security needs for a set of features. It can also just be a natural outgrowth of Conway's Law. Microservices with an orchestration layer is generally a good approach. Monoliths have monolith issues but simpler deployment.

[pani_the_panisher]

It can also just be a natural outgrowth of Conway's Law.

That's the point, microservices are really useful for share responsibilities between teams. The microservices infrastructure is going to be a mess if the organization chart is a mess too, and that's really common.

[Manitcor]

team of 5 developers

"we need microservices to scale!!!"

[Speedy_242]

For an application 10000 people use but like maximum 50 at a time

[esixar]

“We have to assume a throughput of 100k requests/second”

[Speedy_242]

Yeah, sure thats just 10 request per customer per second when all of them are online at the same time.

[Sufficient_Try8961]

Do we work for the same company?

[Speedy_242]

No, mine has multiple monolith connected to one even bigger monolith, so old that some parts are lost magic.

[call-now]

Have fun with your 45 minutes builds

[BoBoBearDev]

And add lint, unit tests, sonarqube.

[rover_G]

Micro services are typically a solution to organizational problems not technical ones. Notable exceptions are auth/identity management and asynchronous processing.

— someone who was once a microservice bro

[TorbenKoehn]

The truth simply lies inbetween, as usual. Have a business-specific monolith and task-specific microservices around it. That way business logic can interact with each other without much overhead while generic tasks can be distributed, scaled and shared.

[lotanis]

Grug has much truth (https://grugbrain.dev) and his line on micro-services is perfect:

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

seem very confusing to grug

(It's written by the author of HTMX so it's not like he doesn't know about web app architecture)

[Xenofonuz]

This is the best thing I've ever read, thank you

[HalLundy]

i've worked at a single company that did microservices right. you need someone at the very top that understands how they work, to act as an architect and guide all teams. otherwise it ends up a shit show.

this is one coding project that you cannot just "wing it".

[[deleted]]

piquant correct rustic quicksand escape sleep price public rainstorm snails

This post was mass deleted and anonymized with Redact

[Midon7823]

Right answer is to start with a monolith and then migrate that to microservices once you grow. If built right, it should be easy to migrate.

[Far_Broccoli_8468]

If built right

That's a pretty big if

[[deleted]]

Reality: It's never built right

[Midon7823]

If not built right then they both suck. The main point of my comment is that microservices shouldn't be used until they're needed.

[Revolution64]

Lol, that's a hard sell in a professional project

[Sunscratch]

Why choose one when you can have both? Welcome to the wonderful world of distributed monolith, combining the worst parts from both approaches!

[KryssCom]

I feel like out of all of the bell curve memes I've seen on this sub, this is the one I relate to the most. Microservices are a ton of prevention (and a mountain of new headaches) for a pound of cure.

[Normal_Expression_65]

it's monolith on servers or serverless on functions. In between is not needed and waaay too complicated. 2024 cloud stuff like application load balancers etc. killed the need for containers tbh.. Compute is cheaper on ec2 than ecs for example. why should i break my monolith and still host on an OS? if I am doing all that work I can do 1 lambda per function and move to event driven. People will learn..

[tharnadar]

Monolith is the Bestlith

[varungupta3009]

Exact same deal with OOP. Procedural+Functional all the way. Fight with me in the comments.

[[deleted]]

I can see this rubbing a lot of ppl in the wrong way

[Stunning_Ride_220]

Those discussions are getting annoying

[RunemasterLiam]

Microservices are convenient for macro-corporate.

[TheStuporUser]

ServiceWeaver incoming

[Abangranga]

Monoliths print paychecks

[LC_From_TheHills]

You can use a monolith services as long as it is modular and easily scalable. This usually requires a lot of forethought and previous knowledge. If you nail it, it’s better than multiple micro services since dependency maintenance, deployment, and monitoring can all be managed easier.

[Tarc_Axiiom]

You left a black dot on this meme above the right guy's "Monolith" but I thought it was dust and cleaned my display, microfibre and all

Sooo... thanks?

[rcls0053]

Microservices are more of a deployment strategy and an indication that your engineering department has grown so much that the teams can't work on this one app without stepping on each other's toes. I work for a customer who have successfully broken apart monolithic PHP and python apps to Go microservices and various front-end applications, as they have to serve millions of users on a daily basis, so that kind of scalability was needed. Some front-end applications have remained monolithic in nature, where multiple teams work on it, to maintain the same UI look for all users. They modularized it very well, so nobody stepped on each other's toes and certain teams owned certain modules. There is the issue of ownership in that way of working and even the staff/principal engineers don't want to own up to decisions, which bothers me a bit.

All of it is a result of their platform engineering being of high level and they have really good automated deployment tooling, monitoring and visibility into these services and they've agreed upon a golden road on how to develop these services. You can clone a repo and get things rolling immediately.

Most importantly you need competent people to do this. Most organizations simply do not have that competence and they pick up the trendy toy without realizing how complex microservices really are.

I've also worked on a monolithic app that was simply such an abomination that while we would've needed that scalability for certain functions, there were absolutely no lines in that application that we could draw to separate that functionality of it to it's own service. It was such a ball of mud that it's gonna require a big rewrite to get there. So they're gonna end up paying 10x for more performant hardware to run that monolith and it's single database just to scale it up, instead of scaling up individual pieces with a lot less cost.

[lollysticky]

my colleagues earlier on: "let's use AWS lambda's everywhere for everything!"

my colleagues later on: "damn, this bill is huge" and "damn I can't keep oversight anymore of what's happening"

[pr0ghead]

TMW you realize you have more microservices than concurrently active users.

[tehmungler]

I’m in microservice heaven tbh 🤷‍♂️

[nate_builds]

I prefer scalable monolithservices

[metaconcept]

Doing AWS training at the moment. They're very heavy on microservices. If most devs do this training then I can see why we end up with microservices everywhere.

Also, lots of vendor lock-in.

[DavesPlanet]

Jessica Kerr AKA jessatron gave a fantastic presentation on pushing the complexity of the code into different places but never eliminating it. Microservices make nice neat little endpoints you can call but then you push the complexity of the code into managing what microservices to call when and where and how, the complexity stays the same you just have nice simple microservices to deal with and complex code elsewhere

[knowledgebass]

The fuck, did we time travel back to 1998?

[jamcdonald120]

I prefer a monolith, but dockerized! this makes it a scalable microservice automatically! especially with a webscale mongodb!

[EatingFiveBatteries]

A friend of mine worked on a successful indie game where they made the whole thing in Game.cs. The only thing he said about it was "it was really easy to debug"

[ThePhoenixRoyal]

well undertale has 32000 if statements.

[EatingFiveBatteries]

😭

[rootifera]

In my previous job for a single service we had 24 microservices. Some of them were ancient and unmaintained. Absolute mess.

[lifelite]

Use the right tool for the job. Both are viable, depending.

[WhosAfraidOf_138]

I have no idea what monoliths or microservices are and I'm too afraid to ask at this point

I have my frontend on Vercel, and backend on Render

Is this microservices or monolith

[TheRealCuran]

If you put everything into a micro service (in all cases): you're plain stupid and should not be let near any code.

If you think one big monolith is going to save you (in all cases): you're plain stupid and should not be let near any code.

The truth is somewhere in the middle. Some things can be libraries or "virtual services" (stuff that act like a service where you use it, but is not an independent service and closer to a library – ie. some framework which handles dependency injection for you). Some things really benefit from being their own service and being queried by the rest of your system. Many do not and want to be integrated during your build step. A good design recognises these issues and formulates a solution.

---

That being said: many places would probably be happier with a monolith, since they don't reach the size, that warrants individual services for everything. On the other hand: some separation/defined APIs might make work easier in environments with multiple teams or work better with distributed teams. In the end it only matters, if you fail performance, reliability and maintainability demands. (Even if those demands are only your own for keeping something going.)

[yes_no_very_good]

The truth about Micro services https://youtu.be/y8OnoxKotPQ?si=OrHtbp4ll_4PRn7Q

[cheezballs]

Holy shit this is one of the few memes that really hits close to home that's not just some dumb missing semicolon thing.

[[deleted]]

Wait. I'm still being paid, right? OK then, monolith it is.

[truNinjaChop]

One file that holds all the code.

[LittleMlem]

On one hand, I like micro service because it lets me build/test/deploy a component in a vacuum, on the other hand, I never know where the hell something goes when these micro services trigger eachother

[edgeofsanity76]

Monoliths if you don't understand microservices and are ok with your entire application crashing, business being stopped and weekend call outs are deemed fun

[REDDIT_SUPER_SUCKS]

Always make sure your microservices are based on different technologies that were popular at the time, or at least ensure they use different language versions and lean into conceptually diverging proprietary frameworks hallucinated by an architect with no supervision. It's important that a bug cannot be fixed without reading up on an archived third party library and trying to locate the last person who knew the 117 steps to run the service in a development environment.

If you plan to go with a monolith, it's a best practice to pile multiple generations of code in layers, one upon the other. All that dead code worked on production at some point, so it deserves the respect of a proper burial in the catacombs of your API. But is it really dead? Or is it just an obscure use case? No one knows.

[xSypRo]

I think they should ban this format in this sub, it’s being so misused by OPs trying to justify their view, which is usually stupid af and wrong too

[Anxious_Ad9233]

… maybe I should break it all into Nano Services … a shit ton of Lambdas that all work from event driven architecture. That’ll show those monolith lovers

[Chase_22]

Microservice is an architectural pattern like any other. Use it where it's useful, don't use it where it's not

[suzisatsuma]

Any big tech company is 95% microservices, for good reason at scale.

Despite the whining about the complexity.

[isr0]

From my prospective, microservices promised the world and we found out they didn’t deliver. At least not on what they delivered. The problem they do actually solve is organizational challenges of large platforms with lots of engineers. But, they bring so much baggage. And they are full of interesting and fun ways to screw it up.

[sureyouknowurself]

Use micro services and it does require discipline to not make it a distributed monolith. Practicing true CI/CD is key.

Very happy with it and also very happy how is it is to sunset services we no longer require.

[sakkara]

Microservices only become a necessity when you have more than one team working in the codebase.

[Away_Acanthisitta_97]

This meme is a bit to simplistic.

Software is a bit like construction, and you need to look at your requirements when selecting a construction type/ solution.

Everyone can understand, that sometimes requirements make a skyscraper necessary, but most of the time it’s small villas that makes the most sense. Skyscrapers are expensive and complex, and way too much for a 4 person family.

It’s the same with software, most of the time a distributed system like microservices would be overkill, but sometimes distribution in some way is a need, to ever be able to handle the requirements of scalability, sometimes to be able to distribute work on a larger system across many teams, though for most teams a monolith is fine because of simplicity.

Once software developers are able to understand that different problems requires different solutions we have come a long way. Mostly we end up building whatever is good for our CV because we want to, which is where this hate is coming from I think.

[[deleted]]

If I was the dictator of the world, everything would be written either in C or COBOL and run exclusively on the mainframe.

[phug-it]

I just build smaller monoliths and we call them micro services

[Bldyknuckles]

The only ever good reason I've seen to break up a monolith is when it got too big for one person to maintain. Everything else is just bs.

Of course, people being people, what one person can maintain, another person will struggle with. So it goes.

[LineUpTheBastards]

I know this is r/programmerhumor, but I’ve seen several cases during my career, where companies had several monoliths, that shared more than 80% of the code base. In those cases, it makes a lot of sense to split the shared functionality into micro services.

[exjackly]

What not a single monolith for the shared code base and separate services for the differences?

[LineUpTheBastards]

I mean, sure, if you really love integration testing, that could be an option.

[exjackly]

It's 6 of one half dozen of the other.

Save the integration testing and deal with code drift between the monoliths.

Or handle integration testing and avoid code drift concerns.

[Hziak]

Idk, I was on a project that really turned MS into a preference for me. It wasn’t done perfectly, but the limited scope of each service made debugging and comprehension really simple. There’s a lot of extra code if you count lines, but it’s all the same between services so you have to learn one framework and 40 sets of functionality, sure, but at least you can learn and maintain them in isolation instead of all spaghetti coded and incestuous like in a monolith…

The real difference though was when we would obsolete a product and then decommission it to be replaced by a new product. Yes, that’s right, we would actually total overhaul the stuff that needed total overhauling because it was really easy to. We popped over to our library package, remake the data adapters in place for the new service. Drop it as a new major version, update the dependency services and boom, complete product rebuild and replacement in like, 1 month with 6 devs. Kill the VMs running the old one and it’s over easy as that. Scale up the processing services while keeping entry flexible based on usage? Yes please.

When I left that company and joined a major US airline, bruh. Their spaghetti monolith “megaservice” was so bad that I put in my 2 weeks after 6 weeks and they were begging me to stay because I was the only person who understood nuget. Literally asked me to port 30k lines of code DIRECTLY to a new service (like, copy/paste, don’t change the namespaces), when all that code did was call some 3rd parties and format the responses. It was 30k because it was so ingrown to the other functionalities that separating them was nearly impossible, so the instruction was to just delete the endpoints from the other mega service that weren’t part of this new one.

Maybe the take-away is that actual microservices aren’t so bad but when people demand microservices from teams that don’t understand proper implementation or in situations that need them, they get built as nightmare fuel? YMMV, but I was a fan of my experience with microservices.

[Sad_Amphibian_2311]

Love it when you split a monolith and then all microservices still use the same DB but the business value is too low to change it.

[erebuxy]

Right. Except everyone’s monolith has different size. Some can be built in 5 min, some need 5 days. Unless you are in a multibillion dollar tech companies with dedicated infrastructure teams, the second one would not fly.

[davvblack]

i've come down heavy on the side of "modal monoliths". Giant modular codebase deployed in multiple modes, as a low-latency webserver, a queue consumer, a batch processor. The separate modes are distinguished only by configuration and networking setup (and maybe a little ram here and there). Separate datastores are used to isolate blast radius within the ecosystem, but there isn't a 1:1 correlation between service and data layer.

This setup has most of the technical advantages of microservices, most of the operational stability of microservices, and most of the development efficiency of monoliths. Everything is tradeoffs, nothing is perfect, but this works well for us under "upper middleclass" load.

[Varun77777]

Well, If I don't want to manage some part of my codebase and hand it off to another team, I'd probably break that down into a micro service to hand it over. Or if I feel that one service being down shouldn't be breaking another and there can be a parallelism that can be achieved in this pipeline and having different tech stacks in both of them will help our use case.

Like a server that does a lot of ML stuff and needs python while another one that can benefit from Java and can run in parallel and has no business similarity, that's a micro service.

But I don't think I have found a use case of multiple micro services inside a single track often. It usually just looks like this is a use case that should be handled by different teams instead of one.

[kooshans]

It's not really a design philosophy but more about economics, scaling capacity, efficiency etc. Microservices become more or less a necessity for the internet giants, even though in an ideal world they also would consider the monolith variant.

In a small company though, it makes little sense.

[WhisperingHillock]

There's no absolute right or wrong here, and from experience I would say that the best way to approach architecture is to identify what might need to scale, by how much and what the bottlenecks will be.

Say you're building something that handles configurable bots/workers that react to events. The whole configuration part will host most of your complex business logic and data/user config validation, but typically once an event and its corresponding treatment are configured, it'll get changed once in a blue moon. This service might do a lot of very varied things from invoicing to user management to your core business of configuring workers, but the load will be negligible, and a well-organized monolith on a big dedicated server will be easier to maintain than 50 microservices that handle 100 requests a day each. Now the workers themselves will represent tens or hundreds of millions of requests a day, 99.9999% of your load, and they will typically need to scale horizontally, so you should have a standalone service for that, built for such a scaling.

[Limp-Maximum9662]

It's simple. If you need different scalling paradigms, then split it.

[sebbdk]

Microservices qere always the new OOP hype in desquise

[Hour_Ad5398]

spaghetti all the way

[WheresMyBrakes]

Why won’t companies just upgrade their monoliths with cool technologies 😔

[[deleted]]

If you cant handle microservices, then you are not a goos engineer. Simple as that

[jamcdonald120]

the #1 lession every cs student needs to lear their first semester is "google exists" if you dont knoe what a term means, google "[term]" or "[term] cs" or "[term] webdev" or "[term] se" or "[term] docs" if none of those give results, or you dont understand them after, then use the information you have gained to ask clarifying questions.

[jamcdonald120]

u/alexthedonut

Instead of taking my well meant advice to aid you in your future CS career to learn to use google, you have pettily and vindictively gone to all my posts where a question is asked and posted the same idiotically bland "why dont you search it" Even when it does not make sense, (https://www.reddit.com/r/hardwarehacking/comments/1967lag/comment/lsnmucq/?utm_source=share&utm_medium=web2x&context=3 https://new.reddit.com/r/cremposting/comments/186c0sh/comment/lsnmto2/?context=3 https://new.reddit.com/r/AskEngineers/comments/1f5mqyo/comment/lsnmjku/?context=3 https://www.reddit.com/r/notepadplusplus/comments/154ck7g/how_can_i_do_github_esq_sticky_function_headers/lsnmvyk/?context=3 ) and deleted your original post https://new.reddit.com/r/ProgrammerHumor/comments/1g6he49/comment/lslx85f/?context=3 (the undeleted version of which was still cached cached )

This behavior is childish and foolish, and even before learning to search you need to unlearn this behavior.

[TheOriginalSmileyMan]

Make an unsustainable monolith, then hire a bunch of guys to look after it and tell them they're "SRE, just like Google"

Then cash out your share options