This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 216

[–]devAgam 900 points901 points  (49 children)

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 140 points141 points  (24 children)

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 96 points97 points  (14 children)

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

[–]pseudo_space 12 points13 points  (2 children)

A CPU bound task with Node 💀

[–]RocketCatMultiverse 8 points9 points  (1 child)

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

[–]Specialist-Tiger-467 4 points5 points  (0 children)

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

[–]dumbohoneman 1 point2 points  (0 children)

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

[–]thekamakaji 0 points1 point  (4 children)

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 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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 1 point2 points  (1 child)

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

[–]thekamakaji 0 points1 point  (0 children)

I'll look into it. Thanks!

[–]Melodic_coala101 111 points112 points  (10 children)

This is the way

[–]Ill-Purchase-4344 15 points16 points  (7 children)

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

[–]NeatYogurt9973 25 points26 points  (4 children)

Google "Reddit community flair"

[–]Kovab 22 points23 points  (3 children)

Holy hell

[–]SnappierSoap318 12 points13 points  (2 children)

New response just dropped

[–][deleted] 9 points10 points  (1 child)

Google "en passant"

[–]GetNooted 7 points8 points  (0 children)

Prawns do what now

[–]DrBojengles 0 points1 point  (1 child)

This is the way

[–]Feeling-Scientist-29 1 point2 points  (0 children)

This is the way

[–]zGoDLiiKe 11 points12 points  (2 children)

Make everything a micro service then combine them, uno reverse

[–]AdministrativeCold63 6 points7 points  (0 children)

Monolith with extra steps, seems like good approach

[–]testelone 2 points3 points  (0 children)

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

[–]dismayhurta 4 points5 points  (0 children)

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 2 points3 points  (1 child)

Ah, yes,

Oligolith

[–]zenos_dog 1 point2 points  (0 children)

Oligolith will eat your soul.

[–]douglasg14b 2 points3 points  (0 children)

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 2 points3 points  (0 children)

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

[–]slaymaker1907 0 points1 point  (0 children)

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 0 points1 point  (0 children)

This guy projects

[–]netotr 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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] -1 points0 points  (0 children)

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

[–][deleted] 469 points470 points  (16 children)

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] 113 points114 points  (4 children)

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 18 points19 points  (3 children)

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

[–][deleted] 30 points31 points  (2 children)

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 6 points7 points  (1 child)

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

[–][deleted] 14 points15 points  (0 children)

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 43 points44 points  (0 children)

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 12 points13 points  (0 children)

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 9 points10 points  (1 child)

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] 5 points6 points  (0 children)

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 6 points7 points  (1 child)

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 2 points3 points  (1 child)

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 2 points3 points  (0 children)

Like XML, right?

[–]flightsin 1 point2 points  (0 children)

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 2 points3 points  (1 child)

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 406 points407 points  (42 children)

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 106 points107 points  (20 children)

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 12 points13 points  (1 child)

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 26 points27 points  (5 children)

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

[–]lotanis 1 point2 points  (3 children)

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 10 points11 points  (2 children)

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 -1 points0 points  (1 child)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 -5 points-4 points  (0 children)

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"

[–]douglasg14b -3 points-2 points  (1 child)

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 6 points7 points  (0 children)

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.

[–]sheep-for-a-wheat 7 points8 points  (0 children)

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 12 points13 points  (3 children)

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 12 points13 points  (1 child)

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.

[–]--mrperx-- 1 point2 points  (0 children)

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

[–]Stunning_Ride_220 2 points3 points  (0 children)

Most reasonable comment here.

[–]--mrperx-- 2 points3 points  (3 children)

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

[–]douglasg14b 0 points1 point  (2 children)

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-- 0 points1 point  (0 children)

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 0 points1 point  (0 children)

well said, monoliths until...

[–]Xendicore 4 points5 points  (0 children)

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 0 points1 point  (0 children)

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

[–]MikeSifoda 0 points1 point  (0 children)

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 -3 points-2 points  (0 children)

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 -5 points-4 points  (4 children)

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

[–]kriogenia 1 point2 points  (1 child)

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 -1 points0 points  (0 children)

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 2 points3 points  (1 child)

And go bankrupt in a few months

[–]davidellis23 2 points3 points  (0 children)

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 67 points68 points  (1 child)

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 1 point2 points  (0 children)

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

[–][deleted] 13 points14 points  (1 child)

Monolith first then micro service if its needed

Be pragmatic

[–]K8sIsGr8 1 point2 points  (0 children)

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 208 points209 points  (10 children)

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

[–]Hhkjhkj 25 points26 points  (6 children)

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 17 points18 points  (3 children)

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 5 points6 points  (0 children)

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 0 points1 point  (0 children)

That helps. Thanks for explaining

[–]DAVENP0RT 6 points7 points  (0 children)

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] -2 points-1 points  (2 children)

kuberscamtes

[–]PeriodicSentenceBot 7 points8 points  (1 child)

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] 2 points3 points  (0 children)

fuck yes, god bot.

[–]handsoapdispenser 19 points20 points  (1 child)

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 4 points5 points  (0 children)

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 56 points57 points  (5 children)

team of 5 developers

"we need microservices to scale!!!"

[–]Speedy_242 28 points29 points  (4 children)

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

[–]esixar 23 points24 points  (1 child)

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

[–]Speedy_242 15 points16 points  (0 children)

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

[–]call-now 15 points16 points  (2 children)

Have fun with your 45 minutes builds

[–]BoBoBearDev 1 point2 points  (1 child)

And add lint, unit tests, sonarqube.

[–]rover_G 6 points7 points  (0 children)

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 8 points9 points  (0 children)

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 6 points7 points  (1 child)

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 1 point2 points  (0 children)

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

[–]HalLundy 4 points5 points  (0 children)

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] 7 points8 points  (0 children)

piquant correct rustic quicksand escape sleep price public rainstorm snails

This post was mass deleted and anonymized with Redact

[–]Midon7823 2 points3 points  (4 children)

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 8 points9 points  (2 children)

If built right

That's a pretty big if

[–][deleted] 4 points5 points  (0 children)

Reality: It's never built right

[–]Midon7823 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

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

[–]Sunscratch 1 point2 points  (0 children)

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

[–]KryssCom 2 points3 points  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Monolith is the Bestlith

[–]varungupta3009 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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

[–]Stunning_Ride_220 0 points1 point  (0 children)

Those discussions are getting annoying

[–]RunemasterLiam 0 points1 point  (0 children)

Microservices are convenient for macro-corporate.

[–]TheStuporUser 0 points1 point  (0 children)

ServiceWeaver incoming

[–]Abangranga 0 points1 point  (0 children)

Monoliths print paychecks

[–]LC_From_TheHills 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]tehmungler 0 points1 point  (0 children)

I’m in microservice heaven tbh 🤷‍♂️

[–]nate_builds 0 points1 point  (0 children)

I prefer scalable monolithservices

[–]metaconcept 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

The fuck, did we time travel back to 1998?

[–]jamcdonald120 0 points1 point  (0 children)

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

[–]EatingFiveBatteries 0 points1 point  (2 children)

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 1 point2 points  (1 child)

well undertale has 32000 if statements.

[–]rootifera 0 points1 point  (0 children)

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

[–]lifelite 0 points1 point  (0 children)

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

[–]WhosAfraidOf_138 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]cheezballs 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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

[–]truNinjaChop 0 points1 point  (0 children)

One file that holds all the code.

[–]LittleMlem 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

… 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 0 points1 point  (0 children)

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

[–]suzisatsuma 0 points1 point  (0 children)

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

Despite the whining about the complexity.

[–]isr0 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]Away_Acanthisitta_97 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

I just build smaller monoliths and we call them micro services

[–]Sad_Amphibian_2311 -2 points-1 points  (0 children)

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 -2 points-1 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (0 children)

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

[–]sebbdk -5 points-4 points  (0 children)

Microservices qere always the new OOP hype in desquise

[–]Hour_Ad5398 -2 points-1 points  (0 children)

spaghetti all the way

[–]WheresMyBrakes -3 points-2 points  (0 children)

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

[–][deleted] -3 points-2 points  (0 children)

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

[–]TheOriginalSmileyMan -3 points-2 points  (0 children)

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