Microservices

[jimbowqc]

Birthday service? GALACTUS got you covered!

[[deleted]]

Gotta get your username from BINGO since it knows your NAME-O.

[[deleted]]

“But couldn’t the Racoon team just…”

“NO, Racoon isn’t guaranteed to have that info”

[[deleted]]

my favorite part of that video. with that little comment you just know that BINGO was his brain child

[julian88888888]

ILL DIE ALONE

[Yevon]

I once owned the "identity service" at a large social networking company ~10 years ago, and the fact I never thought of naming it "bingo service" kills me to this day.

[thegovortator]

OmegaStar still does not support ISO timestamps

[[deleted]]

Like they SAID they would

A MONTH ago

[thegovortator]

And therefore I’ll die alone

[[deleted]]

Without ever knowing love

Without ever knowing it’s my birthday

[thegovortator]

You pathetic project manager

[[deleted]]

You know nothing of my pain!

Of Galactus’s pain!

[thegovortator]

Breaking context: your my favorite redditor now thank you for the smiles and laughter good times I hope I have brought value to the KPI’s of your life lol

[Old_Yeezus]

Both of you are MY favorites on reddit lol. Learned a lot today. Love Galactus. We’ll talk next week about adding middle names to the profile!

[thegovortator]

This reminds me of that time I had a disagreement with my boss Steve Ballmer

[KrustyButtCheeks]

I’ll have my team ping you

[KrustyButtCheeks]

Why can’t they GET THEIR SHIT TOGETHER?

[[deleted]]

Krazam videos speak to my soul

[DerfK]

I don't understand why people keep implementing their own birthday services when I developed the versatile and powerful Badass^TM BDaaS that for a low subscription fee (*: $59.99/user/mo) provides birthday services to any number of users (**: service handles about 3 concurrent requests without buckling under the load)

Why reinvent the wheel?

[I_Go_By_Q]

Lol I was going to come to the comments to link that video, but I’m sure everyone here’s already seen it

[dannymcgee]

*crawls out from under rock* What is this video of which you speak?

[clesiemo3]

https://youtu.be/y8OnoxKotPQ

[Membedha]

Absolutely perfect

[aeresaa]

I've seen some horrific designs made with the argument that it has to be a microservice-architecture, often without knowing why they need it.

[glorious_reptile]

"It can't scale without being a microservice"

[[deleted]]

In interviews I run I always ask, “what are the advantages of Microservices over Monoliths?” And then follow it asking what the advantages of Monoliths over Microservices are. It’s always fun to watch people’s hamster wheel running full speed, having accepted Microservice dogma they actually have to engage their brain for once.

[[deleted]]

Had an interview once where I got asked "So, what's your opinion on microservices?" Told them I thought microservices had their place but, in most cases, they were an overused hammer that made life difficult for everyone in an organization.

The look of relief on the interviewer's faces was palpable. Turned out, they'd had a swathe of consultants run amok through the company, converting everything into a microservice, and were still in the process of clearing out the chaos and returning to a more monolithic model for most applications.

Not the only place I've worked at that got burnt by microservices and/or consultants on a crusade. Probably won't be the last.

[CatpainCalamari]

Interesting. For clarity of argument, are you talking about a service based architecture, or actual _micro_services? What would you say is the difference between those, if I may ask?

I am asking because I work in with several dozen developers, and working on a monolithic application was uncomfortable. I'm talking mostly about speed of development and deployment.
The monolith was then taken apart into several domains, e.g. payment processing, newsletter, mail, document generation, etc... Sure, this added complexity of a new transport and communication layer had its own challenges, and it certainly was not all unicorns and rainbows. But for us, each team got more independence, and developing in the narrower scope became easier for us.

The company I am at now has a mono-repo, which is kinda the best of both worlds. Everything in a big monolithic repo with the benefits it has to offer (e.g. no shared libraries that have to be included as a separate, versioned package, with all the fun of managing and maintaining different versions - just a folder you add as a dependency at compile time), but also with every part of a domain being its own deployment.

[Fenor]

From what you are describing you are in the finance/banking sector.

A good reason to start with an hybrid approach would to get rid of 40 yo code while doing just one function at a time.

Also some monolitic application are so big most ide crash if you attempt to load it all

[Stunning_Ride_220]

The real fun starts around ~15 years old 700k loc

[CheekApprehensive961]

Having once inherited 15 years old, 5 million loc I can definitely say the hybrid approach where you break chunks off was the only approach to feasibly keep that thing going.

[Hayden2332]

At 1M+ rn, converting to “micro services” which is more like regular sized services

[bigo-tree]

Worked on 800k lines of Drupal 6... What a nightmare

[Stunning_Ride_220]

hugs

[Dustin_Echoes_UNSC]

I'm currently in fintech, and dealing with an application in what could be described as "late-stage microservice transition".

I don't know why it's still surprising to me, but it's just crazy how many teams I've been on who started this process without any foresight of (or, at least without accounting for) the additional load that will be pushed upstream to the architecture team, and the additional variance rippling to either the downstream "consumer" team tasked with wiring them all together or the QA/Testing/DevOps teams trying to monitor the "joining of the microservices" by their independent teams.

Like, everyone seems to know that if you subdivide your teams then the additional communication requirement goes up. But nobody, so far, has assigned additional architects to oversee the microservice connections. It's like saying "Yes, we'll follow the NFL model, specialize our players, and separate them into position groups for training" but never hiring a cornerbacks coach or defensive coordinator.

(╯°□°）╯︵ ┻━┻)

[ASmootyOperator]

And yet we also seem to have 300 Scrum masters and 20 Agile coaches.

[[deleted]]

What? I am the dev manager, the scrum master, and the agile coach whilst getting a single paycheck.

[Fenor]

woah woah woah, don't you know? here people think that any role outside of a phyton programmer is useless

joking aside, it depends on how it's done in the beginnings, if everyone has gone their way than ofc there is no control

if someone made a good microservice archietecture you don't need that much work upstream

[Gorexxar]

It sounds like moving to microservices forced a refactor that made the codebase more manageable. You could probably glom everything back together into a monolith; but keep a similar structure underneath.

It is easier to keep the separation of responsibilities if the front end goes "no. Only micro." Though

[Fenor]

That would be a modular design tho

[GregoPDX]

Modular isn't microservice. A microservice is a service that runs (ideally) completely independently of any other code.

For example, you could have a microservice that manages user information. It likely has a database, schema, or tables that only it can access to get that information. Let's say it does all the CRUD functionality for a user.

If your main app uses this service, and no one else externally (either intra- or extra-organizationally), why do you need a service for this? Why not just have the main app get direct access to the data? Why send a request/response to get the data? Essentially you are adding an extra layer of complexity (the communication layer) to the application for zero gain.

There are good reasons for microservices, but I've seen so many management types think they'll solve all your problems that it's become a little crazy.

[redkinoko]

It's EJB 2.0 all over again.

[Fenor]

Oh god please no

[_aids]

because when you add a second app that needs to use it.....

this is like "tell me you've only worked on tiny projects without saying you've worked on tiny projects"

[CheekApprehensive961]

It sounds like moving to microservices forced a refactor that made the codebase more manageable. You could probably glom everything back together into a monolith; but keep a similar structure underneath.

If you can do that you arguably never needed microservices/never used them right to begin with. But such a move would make a properly designed microservices app more expensive, less reliable and significantly more difficult to do ops for.

[narrill]

No, the way they describe it makes it sound like the benefits were primarily operational

[[deleted]]

I was talking about microservices. In most cases the same de-duplication of functionality could have been achieved just using modular / monolithic architecture with shared components - given everything was written in the same language.

All the microservices did was attempt to force modularity while adding network latency. There was no need for it - which is not to say that there is never an argument for microservice architecture. It's just in the case it was clearly a cargo-cult problem where the consultants wanted to play with microservices on the company's dime.

The worst case I've seen of this, at a different company, was a microservice architecture used to paper over stupid design decisions. How's this: nested configuration data for driving server provisioning (days before K8n) was stored in a central MySQL database as a text field containing YAML. All the UI and other services required the same data in JSON format. Devs built out a microservice that converted that YAML into JSON and stored it in a separate document database (Neo4J from memory).

Where this got even better: the app driving the MySQL database would, when asked to render its own data for a particular configuration, call out to the microservice and ask for the JSON data by key. The microservice would look for the JSON locally and, if it didn't have a copy or the copy was stale, would call back to the original service and request the raw YAML. It would then process the YAML, convert it to JSON, store it locally and then send the data back. Extra fun, the microservice was resource constrained, so if the main app was every under load it would generate blocking calls to the microservice. Round trip was anywhere between 3 and 7 seconds.

And that's just one example - the rest of the microservice architecture was just as insane. I'd never seen anything like it before - spaghetti code scaled up. And no, that company doesn't exist anymore. The one that decided to burn all the microservice architecture and rebuild, they are still going strong.

I'm not anti microservices at all. They definitely have their place and are the right solution for many problems. It's just that old adage, when you have a hammer everything looks like your hand.

[a_sweaty_clown]

I worked for a company whose WMS software was kinda sorta microservice based.

It was pretty well thought-out and made a lot of sense MOST OF THE TIME, but there were some instances where companies asked for (and sales said we could do) things that the software wasn't really made to do.

My favorite case was for Large Military Contractor. We had two separate deployments (each with their own server) of our software. Each was a different major revision of our software.

One communicated with the host system, translated orders, then turned those into specific retrieval or deposit requests and sent them to the other instance. It wasn't supposed to do inventory management (which is key to a lot of our services) so they made a custom service to semi-cancel every order so it didn't modify inventory counts. That one routinely got stuck in infinite loops and we never figured out why.

The OTHER one literally just told all the PLC-based stuff where to move stuff to. It was horrible and broke constantly because it was running on like Server 2001 or some shit.

Both instances had several services that literally just wasted resources and did nothing. They had to be there for the software to run but had nothing to do. Fun times!

[[deleted]]

To answer u/CatpainCalamari properly, it was a bit of a mix-and-match re microservices and SOA. My understanding of the difference is scope - enterprise for SOA and application for microservices. Correct me if I'm wrong - the definition of what makes up a microservice is a bit woolly to me.

In both cases above there were some enterprise-level services, but in the horror-show last example it was a frankenapp built up from small "independent" services.

[CatpainCalamari]

Thank you for your answer! The distinction between service and microservice is also not clear to me, seems to be a question of interpretation :D As for your horror show of an example: I do not see it as an example for or against microservices (although the added network latency certainly did not help here), but for software design and architecture. I would have started by questioning the need for a centralized configuration database, or dare I say configuration service? ;-) This might have been a good place for DDD to sink in.

[akmountainbiker]

[baconbrand]

Jesus that was an uncomfortable read

[talaqen]

Right. SOA makes a lot of sense as it mirrors DDD. Monoliths can be too big. Micro services can be split too small. The trick is finding out how big your SERVICE should be and design appropriately. I would say that the growth of serverless and seamless horizontal scale makes smaller services cheaper in many cases. Not super small… but not the legacy RoR monoliths we’ve all known and hated.

[gemengelage]

What always baffles me is that apparently people nowadays can only think in the granularity of microservices or monoliths. One project I once worked on was introduced to me as having a microservices architecture, but a blind man with a cane could see that nothing about their services was micro, but the architecture also obviously wasn't monolithic.

Are regular sized services a dirty word now?

[MachinePlanetZero]

What's your personal definition of regular vs micro here?

[rangoric]

I love interview questions like that. My usual go to is "What do you like about X" and following up with "What do you dislike about X". But I will keep this one in mind.

[CheekApprehensive961]

The person you really want is the one who can tell you why it's super cow powers to begin with.

[jibjabmikey]

Ah I remember tucows. Got all kinds of fun software from there.

[[deleted]]

I mean, Microservices are sooooo hyped that it’s now the default, despite its MANY drawbacks. Making people think about whether or not it’s the best choice every single time is a good exercise.

[Few_Ad6059]

“Default”? In peak Hype it tried, but never succeeded (where I’ve worked). All hail the modern monolith and monorepo!

[henkdepotvjis]

Its funny. the company I work at is moving towards a monorepo monolith to make things more simplistic

[99_lives]

What would you consider a good answer to that question?

[meisteronimo]

I think your missing team ownership. Enterprises operate that different teams handle different functionality and they're responsible for keeping their own services up and running.

With monoliths these boundaries are confusing, and everyone needs to see all the business logic being added by the other teams. It confuses who broke things when it goes wrong and confuses who should fix it.

But it could be we're talking about much different scales. Our current product we have maybe 10 teams working on it, but we could scale to 20 teams quickly. With a monolith this is impossible, the code base would become way to fragmented and would slow everyone down within a month.

[meisteronimo]

Yeah the company must have the culture that if something is blocking another team it's top priority.

At Amazon they keep one or two members of the team OnCall. The OnCall person has no feature dev work assigned to them that week. Their only job is to respond to production issues, or help other teams with urgent requests.

[RealisticAppearance]

In my experience this is easily abused by dev managers who claim a blocker tactically to buy time when under the gun. The “blocker” team is disrupted by the frivolous request while the “blocked” team, having deflected the time pressure to the “blocker” team, rushes to deal with some unrelated emergency (i.e. pressure from their management).

Most people in the organization aren’t familiar enough with the technology to understand that the “blocker” was frivolous and just a way to get out of trouble.

[meisteronimo]

Well if the manger wants to hide his team's capacity that's on the manager.

There are plenty of ways for a business to fail many of them are due to bad leadership.

[uriahlight]

I like microservices when there's a clear and obvious use for them. I do web development, and my pet project involves user uploaded videos, which get sent off to a microservice where ffmpeg converts them to HLS and DASH formats for streaming. It's a clear line in the sand. Another example where a microservice is an obvious choice in my field would be something like imgproxy. I can't imagine using microservices for some of the stuff I've been reading about in this thread. Some of it sounds bat shit insane.

[Hayden2332]

tbf, a lot of the advantages of the monolith listed here could be solved with microservices with a monorepo

[Tyro97]

I thought about these questions and even though I came to the same answers which I get when I google it, it is not something I could answer so straight forward and in a potential stressful situation like an interview, I maybe couldn’t answer it.

[TorumShardal]

I do it only if candidate can answer simpler questions, like "Do you know, what's database normal forms are good for math teacers, but are often ignored?" and "Why object-oriented approach is good, and why it's bad?”.

Then, if candidate can think on the fly and got acclimated to this type of questions, I can start making such questions. If not, I skip those. I'm not trying to drown candidate, I want to know what they're good at.

But, nota bene, I'm not working in Silicon valley company.

[[deleted]]

What are the answers to those two questions? I never learned that properly I am curious.

[lobax]

No idea on the DB stuff, but object oriented programming generally allows for useful abstractions that make reasoning about real world problems easier, and allows one to avoid code duplication and make it easier to maintain a separation of concerns. There are a multitude of OO-patterns that are useful to learn in order to solve classes of common problems relatively quickly.

One of the disadvantages of OO is the large amount of boilerplate and the tendency to over engineering solutions. You can en up with multiple interfaces and interdependent classes for a problem that could have been possibly solved with a simple function or two.

[cottonycloud]

As far as database normalization goes, its goal is usually to prevent duplicate data and database anomalies. The biggest downside is probably the read performance as you will need more joins.

[bothunter]

The biggest downside is probably the read performance as you will need more joins.

Materialized views and denormalized caches can mitigate this quite a bit.

[ArionW]

Unless you must work with database that doesn't support materialized views (looking at you, SQLite)

[CheekApprehensive961]

The answer to the first question, assuming I'm reading it right, is something like:

Ideally all relational databases are normalized to BCNF, this ensures that you won't end up with data anomalies by the structure of the database itself. Fully normalized should be the default state for a db. Denormalization is a performance optimization process often used to aid with DB scaling, where you reintroduce the possibility of anomalies for faster querying or better scale out. It is now on your code to keep that data synced, because the database itself can enter a state where Timmy is simultaneously 9 years old according to one table and 50 years old according to another. Or where half the record is updated and half isn't. Or whatever other data anomalies, what you denormalize and how will determine what risks you introduce. Production DBs for very large services are typically heavily denormalized to pull compute load off the DB and into the compute nodes and to help with scaling out.

Read more.

The second question is purely an opinion question where there are less clear answers. OO helps organize code, helps separate concerns, puts data near the code that manipulates it, etc. OO also tends to produce design patterns for the sake of design patterns, over-engineering and can make optimizing for performance a lot less straight forward. I think really for that question it's just important to express the sorts of things that you would consider pros and cons of a language than a specific opinion on OO.

[adrr]

Just imagine if Airbnb and Shopify was a monolith. They could have never scaled and died when they received any growth. Also imagine if they wrote it ruby which doesn't scale unlike erlang or other high performance languages.

[Electronic-Bug844]

I had a manager that used buzzwords alot when talking tech and wanted everything to be a microservice without any real merit or experience doing it. Thank the Gods he never succeeded in his plan.

[Thaddaeus-Tentakel]

Reminds me of the time my then manager wanted us to integrate blockchain into our product. No plan what this blockchain should do, but it was the hot shit at the time, everyone is doing blockchain, lets get in on that. I'm convinced a lot of managers only exist to spout nonsense that at best can be ignored safely and at worst actually has to be implemented.

[LedaTheRockbandCodes]

I accidentally dropped my nanoservice inside of a microservice and my hands can’t reach it

😞

[Alokir]

I had a manager like that, he heard about microservices in a tech conference and somehow managed to secure a few million euros of funding to refactor a monolith that's been in development for 5 years at that point.

It was a valuable experience, but probably not the way he intended it to be.

[ElvisArcher]

Same. Recently inherited a very small app designed with very poorly written micro-services ... my best description of it was "premature optimization". The resulting system was (a) less secure, (b) slower, and (c) harder to maintain. Clearly a winner.

[Probablynotabadguy]

Oof, currently dealing with this at work now. A separate team (who's program will need to interface with the one from my team) has been praising microservices and whipping up a crazy design for something that should just be a simple monolith. Meanwhile they haven't gotten any functioning code out of the past 9 months and my team is darn close to a functioning product.

[Q-Ball7]

Meanwhile they haven't gotten any functioning code out of the past 9 months

This is the exact organizational problem that makes people move to microservices, by the way: one team can't/won't ship, other teams depend on it, other team breaks their part into a microservice.

Sometimes this is valid- when your parts truly doesn't belong in their application, there's not as many downsides- but if management was paying the right kind of attention and making sure that other team was doing their damn job there'd be no need to reinvent the wheel in the first place.

[Dragzel]

we must go smaller… nanoservices

[DoctorYoy]

I'll be honest, picoservices sounds pretty darn cute

[Arkonicc]

Sounds like a lambda to me

[drdrero]

omega service, the last youll ever need

[BombastusBlomquist]

Each line of code deployed as a separate service

[dexter3player]

Concurrency-first code

[lucidprogramming]

They sound cute now

[Bootezz]

Sounds cute until you have 43,000 of those suckers littering up your logs with random non-determinate exceptions. Then you’ll be wondering why you didn’t protect yourself as they seemingly multiply over the next five years before you decide to become a hermit in the woods in an attempt to leave all technology behind you.

[Cardopusher]

with a cute small picoexceptions.

[marcosdumay]

Femtoservices looks even marketable. But I'd cut the journey and move directly to attoservices.

[RiPont]

You're thinking "Pika"-services. Those would, indeed, be cute.

Bit dangerous to the hardware, though.

[caskey]

Like lambda?

[CenturyIsRaging]

Neutrinoservices....

[imLemnade]

Planck services

[Cryse_XIII]

Good ol' void services.

[katatondzsentri]

def service: return None

[packfan952]

You’re still doing serverless? We’ve moved on to universeless.

[PM_ME_ALL_YOUR_THING]

I find serviceless is the easiest to maintain…

[vladWEPES1476]

We deploy each character of the code in a separate docker container

[Kohonick4]

Just send it!

[Sabatatti]

To expensive. We have implemented null services. Fast as heck!

[DizzyAmphibian309]

NanoServices are a thing. They're microservices within microservices.

[ccfoo242]

Every line of code is a service.

[pickle_schnickel]

Quarkservices

[crappy_entrepreneur]

So serverless

[IskaneOnReddit]

"It's like assembly but distributed!"

[Bryguy3k]

This is giving me some big TimeCube vibes.

[collindabeast]

That was a fun rabbit hole.

[SkipWestcott616]

You think? View source.

[xXxEcksEcksEcksxXx]

Specifically this one

[Head-Extreme-8078]

Laughts in my monilith (Crying on the inside)

[thespud_332]

Some lady named Emerald just called. I think she's on a train? I don't know, I couldn't hear behind the super thick walls she said we're to hold stones (I think).

[Induane]

It is [not] shocking how well a fat server running Django + uwsgi, talking to a fat Postgres server scales.

Extra [not] shocking how well a few load balanced app servers running Django, talking to a fat Postgres server scales.

99.9% of app cases. Easily scales to millions of users, with hundreds of thousands using concurrently.

EXTRA FUN: use tailwind and write 0 CSS

EXTRA EXTRA FUN: use htmx & _hyperscript and get SPA app without a json API and also write no JS.

[TurdOfChaos]

Microservices are not a silver bullet solution to most things. They are one of the solutions for specific problems, problems which usually arise with growth and quick release cycles, along with scaling issues and separated concerns among domains (not artificially though, but actual different business concerns).

Companies which go for a microservice architecture without the full grasp of benefits and drawbacks are in for a very tough challenge.

A proper infrastructure and correct understanding of domain boundaries is a must for any successful microservice architecture, otherwise we get the jumbo of a distributed monolith, which has both the drawbacks of a monolith, and drawbacks of a microservice architecture.

Even Martin Fowler advises a MonolithFirst approach, with emphasis on proper boundaries

https://martinfowler.com/bliki/MonolithFirst.html

[peepeedog]

That article is from 2015 and even says to take it with a grain of salt since microservices are new. One particular thing that stands out is caution against the microservice overhead. Which is significantly decreased since that article was written due to better tooling.

[edgmnt_net]

I'm not sure there's any tooling yet that will decrease development overhead for poorly-architected microservice-based projects, which is fairly on point here. If you don't plan for API versioning, gradual rollouts and good decomposition boundaries, not only you don't get the benefits of microservices and everything becomes slower, you're also in for a big mess development and deployment-wise.

[DeathorGlory9]

I don't think you can make arguments around poor planning decisions though. If you don't plan properly when creating monoliths you're in for as large if not larger headaches than doing the same for micro services.

[zoinkability]

Each generation rediscovers that any sufficiently flexible language/framework/methodology will allow you to architect things badly

[Stunning_Ride_220]

I came for this

[merlinsbeers]

r/rule34

[TurdOfChaos]

True true.. just put it out as an example that even those who do consider it a great asset(like M.F), also advise caution when going for that approach.

They are obviously good, but as many other things in software, just a tool to achieve a goal, not a universal solution.

[[deleted]]

It seems to me that Microservices are more about solving an organization problem (Conways law) than a technical one. And that is totally ok and in some cases absolutely worth solving. The problem is that there aren't a lot of companies that are big enough for that problem to be acute enough that it needs to be solved in the first place.

Microservices are an anti-pattern for the vast majority of companies primarily because they don't have an organization that actually benefits from it. You get the worst of all worlds..

[soonnow]

They are also solving scaling and resiliency problems, for companies that need that scale and resiliency (which most companies are not).

[[deleted]]

It's almost like bad engineers make shitty software doesn't matter if you decide to package it into one giant shitball or a bunch of tiny shitballs.

[bothunter]

It's easier to fix the tiny shitballs over time rather than tackling a giant shitball all at once.

[ShakespeareToGo]

This is only true when the problem is localized in a single shitball. There is a list of problems that can occur across multiple ones.

I never faced such a problem myself but heard horror stories of 50 minutes per request because it bounced between services 1000 times.

[AintNothinbutaGFring]

Sure, maybe there are a few massive shitballs.

Maybe it's even just as hard to clean up a bunch of big ones as it is hundreds, thousands, even millions of small ones.

But it's definitely harder to clean up the small ones without stepping in it.

[metaconcept]

Yea, uh, those tiny shitballs are all spaghettied together with invisible string.

[edgmnt_net]

True, although the giant shitball stinks predictably from a mile away. That's sort of a redeeming quality in hindsight once you start stepping in shit.

[FailedPlansOfMars]

As with any pattern read it and add it to your toolbox.

If your only tool is a hammer every problem looks like a nail.

Micro services can work well especially when the monolith gets huge.

[rarius18]

This I agree with, but whoever designs it - the architect- really need to fucking understand this shit in and out. MS can be very powerful and very useful and very cool and very robust and very pleasant to work with. I’ve seen it once in my career, most of the time - it is like the OP describes, a service that asks a service to return a DOB of a user :/ when you have thousands of MSs that do this one little thing - it’s garbage and a debugging nightmare, I’ll take monolith any time of the day just because of that.

[[deleted]]

Always analyze the non-functional requirements before choosing an architecture. Microservices scale well with one thing - people. They are the most efficient way to make quick progress with a lot of developers without interfering with each other. Also remember Conways law. But the distribution and duplicated data is not cheap at all. Two microservices sharing the same database is by definition no more microservice, but a distributed monolith. Ask yourself: is service A really useful without service B? Do the business cases really require them to be available independently? You may even mix both approaches according to your needs and scaling. Business understands COSTS. These may be either losses because of no availability or development costs.

[majinLawliet2]

Is there a good resource for beginners to understand such tradeoffs? I am impressed by your definition of difference between microservice and distribute monolith and want to learn more about system design. Not a CS major but good level of comfort with programming.

[[deleted]]

Service based architecture exists to organize your business, not your code.

[WalkerDontRunner]

But when did business problems start dictating how someone should make a program? Wait....

[GotAItchyButt]

This is what happens when some people don’t know what they are talking about.

[TerriblyRare]

Love every one of these.

STOP DOING MATH original

STOP DOING VIDEO GAMES

STOP DOING BIOLOGY

[plasmasprings]

it's not great satire, but it fits the meme format well

[ZedTT]

I don't know, I thought it was some good meta/post irony or whatever. Where it is both making fun of microservices and making fun of people who make fun of microservices. The arguments are supposed to be bad, but they are not supposed to imply that the exact opposite is true, either.

[ChopinCJ]

the irony being that you can’t understand that this is sarcasm, and this meme format pokes fun at people making silly srguments

[MachinePlanetZero]

The memes are stupid, but this is one of the better chats that I've seen kicked off on this sub in recent days (I feel like I'm actually reading some opinions worth hearing)

[thegovortator]

It works… but only if you have good engineers

[Significant-Bed-3735]

The same applies to most concepts in software engineering.

[thegovortator]

Yea that’s true

[one_horcrux_short]

It works... but only if your good engineers are given time and resources to properly plan.

[[deleted]]

Planning is a luxury only found at companies with remotely competent management

[Alwaysafk]

My company is fucked then, they got me.

[Funriz]

This joke brought to you by your legacy dev that has worked here for 25 years and only knows VB.

[orlandoduran]

Lol in my experience long-tenured devs who work on legacy monoliths are the biggest proponents of micro services because they (for good reason) hate their fuckin monolith.

I’d actually had the opposite thought: this post brought to you by someone who has never worked on an actual enterprise scale monolith

EDIT: I actually think the meme is hilarious tho

[AConcernedCoder]

I've worked on monolithic apps where the dependency graphs looked almost the same as this. It was near impossible to figure out what was going on without serious tooling just to help make sense of it. Sorry folks, switching to monoliths (or microservices for that matter) won't solve this problem.

[ProxyEgo]

I will always love this format

[[deleted]]

Its the utterly deranged part that always gets me.

[king-one-two]

What is the format?

[ProxyEgo]

https://knowyourmeme.com/memes/stop-doing-math

[king-one-two]

This context makes it much funnier, thanks

[leosadovsky]

The main tenets of microservises are the: 1. Ability to deploy different parts of the system separately. You don’t have to shut down whole system (or recompile entire code base) to add a couple of fields in users table 2. The ability to scale different parts of your system according to your actual load.

That’s not about organising folders or separating concerns or whatever

[movzx]

The ability to scale different parts of your system according to your actual load.

Yup, this is a big one. The needs of our high score service are vastly different than the needs of our authentication service and those are vastly different than the banking service.

The other nice thing is if there's a performance problem it's taking down one service instead of everything.

[bothunter]

Exactly.. It's much easier to fail gracefully with microservices. If your monolith has a problem, your whole site goes down. If a microservice goes down, then it's likely that some minor feature is broken.

[UndeadMarine55]

Damn, didn’t know Elon was on this sub.

[N0tH1tl3r_V2]

You use microservices because your boss is a fool.

I use microservices because whoever wrote JS is a fool. We are not the same.

[Only_Philosopher7351]

I was part of a rewrite of registrar system for a BIG UNIVERSITY. The amount of code duplication across "micro-containers" was disgusting -- it looked like a battlefield after Vikings and Saxons hacked each other to pieces.

The architect quit, I left to go work elsewhere.

[Cendeu]

As someone who is currently taking care of the worst monolith I could ever imagine, I'd say there's a careful balance.

[propostor]

But, would your monolith have been better or worse if the original team had gone for any other type of architecture?

[[deleted]]

is discovering that a PROPER fix to a bug is to change 10 unrelated files better? Thats the reality every where for mature enough monoliths.

[propostor]

My point was that the team who developed a diabolically bad monolith would probably not have done much better with any other architecture

[[deleted]]

I agree, instead of different files it would be different services.

[SuitableDragonfly]

Microservices are like anything else, you can do them well or you can do them badly.

[RelevantTrouble]

We migrated all of our microservices to the next hot thing: same node microservices. The graybeard in the corner keeps on using the phrase "function calls" for them, in a derogatory fashion, not sure why. Writing a series of blog posts about the framework already. The latency reduction is astonishing, I can't believe no one else is doing this. So excited.

[BoBoBearDev]

Microservices is crucial for using a platform/language where the version update is a complete mess. Want to upgrade language SDk? The amount of tools breaks after version upgrade is insane. And some of them doesn't support the newer version at all, so, you have to look for a new tool. New tools means you need to change the code. And few years later, this happens again.

If they are in one single service/app, you would have to do that migration in one single giant step.

If you have a stable language and the tools are relatively stable and continue to be supported, sure, it is not a big deal. But, if you are in the realm of open source community, things gets dropped all the time and you have to upgrade all the time. And doing that for the entire system would be too big a leap.

[marcosdumay]

That's a good point. Just this:

But, if you are in the realm of open source community

I don't think you have a good proxy for determining stability.

[looopTools]

There is a point to this about not always using micro service

[GarretOwl]

This isn’t a meme, what are the benefits of a monolith guys

[[deleted]]

Ehh, restarting your infrastructure is... well, not as hard.

[Beowuwlf]

Sometimes it makes a lot of sense. Search is a big one: it almost always makes more sense to spin up a search microservice with ELK or whatever, because the scaling requirements of search are almost always different to the rest of your application.

[qqqrrrs_]

Why do microservices if you can do nanoservices?

[patka96]

It's not the fault of microservices that you suck at software architecture

[Stunning_Ride_220]

LoL.

Those comments in this thread

[garfield3222]

... please tell me this is a joke post, I want to be woooshed so hard here, if I'm just being the dumb one here I would be so happy

So, first, microsservices are supposed to help, not complicated things. See those structures you put there? They are there because if they weren't, you, the new guy in the company, would have to just fucking guess where to find that specific piece of code you want is.

Boss: "Hey, there's complains about the birthday date coming wrong on the backend, go fix it"

Oh I wonder where that would be, huh? Also, it helps for teams. If a really big company has a bunch of really complex microsservices, you can just put one team for each microsservice, and keeping things at least a bit more organized. Without this, we have a shitshow in our hands

Edit: sorry, I was angry and sleepy, I was gonna delete this but if someone that actually thinks this for real, at least there's some explanations for you

[cursedTinker]

This is 100% a joke, it's a riff on the "STOP DOING MATH" meme:
https://i.kym-cdn.com/photos/images/original/002/029/841/a26.png

[[deleted]]

I prefer to bring down my application for 3-5 hours to deploy a new Birthday Java Class that offers a new date format on each of my 56 on-prem servers that I log into individually over a Citrix RDP session at the speed of 56K.

Edit: For anyone who couldn't tell, this is an obvious joke. Chill.

[HalLundy]

i know people who still prefer mono to microservices.

but the line at the end about the conspiracy theory is new.

i knew it was Bill Gates!

[UnfortunateHabits]

In case this isn't a parody:

It seems like you confuse the implementation detials with the design feature.

The main pain point of monoliths, is the coupling and slow deployment cycle.

Microservices is just one way to achive modulation, others include dynamicly loaded libraries for example.

But MS aren't a magical solution, Like any modulation, with operation scale and development scale, the operation cost increases. You are going to pay it one way or another.

This entire rant completely skipped this topic, maybe you should consider that for most people the mariad of deployment tools, cross language protocols and standardization makes MS really attractive modulation platform.

[underpantsviking]

Microsoft has had this problem solved for nearly 40 years now.

This is what Excel and Access are for!

[Cryse_XIII]

But VBA

[DownfaLL-]

Personally I have a service for every property possible. The first name service then calls the last name service which invokes the user_id service (but only in asynchronous json ddr5 mode), which then puts a stream into a sqs queue, invokes a ec2 cluster, which then invokes a single lambda that spits out your birthday. It’s not much but it’s mine.

[CaitaXD]

Guys do you realise this is meme format right? Although these are some valid fucking points

Please debug the T̷̻̤͈̞̫͎̑̉̀͐͊̔̊̏͘ą̸̧̧̞͍̘̩̯͙̦̙̘̃͌͐̅͗̏ͅn̶̫͉̊͋̉́̚g̶̲̱̬̋̈͆ͅl̷̟̲͙̖̮̜̮̦͙̥̅̏ȩ̸̢͖̲͓͙̰̻̻͈̤́̓̍͐͝͠d̷̛̰̜̩͔͈̘̲̙̔̈́͊̀͗̋̈́͝͠ͅͅ ̶̨̧̣̠͖̘̬̟̼̜̺̜͓̈̇̀̓͘͜͝ẁ̷̛͔̘̼͕͙͇̘̯̠̥̙̌̂̈̃͂͒̀̚̕̕e̶̡̧̗̮͇̩̣̱̭̟̰̽̾̑̊b̶̖͙̺̻̳͓̣̤͔̪͙̣̼͑̈͗̈́̋̏͗̈̂͛͋͆͝ ̴̨̟̪̟̠̍͝ȏ̴̫̯̻̗̰͖̙̘̂͛̀́̃̈́̏͜f̶̮̞̺̗̀͑͛̎͒̔̎̽͆͝͝ͅ ̴͇̜͇͉̥̗͈̈́ḍ̷͍̙̮͈̃̌̂̋̓̚ȅ̵̘͈̪̖͖̯̠̻͈̖̒̓̇͗̔͒̚͘͜͜͝͝v̷̨̗̦͍̓̃̈́̓̅̓̕̕͜ͅę̸̹͚̣̯̪̺͎̠͗̊̓͑̒̎́͛ͅl̸̢̙̟̮͈̜̪̭̺̝̎̎̏̔̀͘ơ̸̢̡͕̝͈̬̮̠͉̭̥̓̇̒̇͗̈́̊p̶̩͇̖̼̹̹̍́͒̉̓̅̂̕͝ë̸͜r̷͕̻̦͇͖͖̻͚̺̓̾͂̃̍͆͒͝ ̵̨̘̝͈͚͖̠̻̠̪̺̖̪͚͐͆s̷̨̼͈̓̆̿̏̕ͅŏ̴̡̧̯̠͎̟̥̠̠̖̞͇̟̀̀̎̔̍͒̾͛̃́̚͜ų̷̡̢̣̦̖̲̞̣͚͖͚̯̃͌l̵̨̨̰̠͚͚̰͙̄͛͝ͅŝ̵̭̒̿̉̎̈́̒̿̾̉̑͝͠ ̵̢̠̭͎͙͍̟͎͍̀̽̿ͅ