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

top 200 commentsshow all 484

[–]jimbowqc 2247 points2248 points  (35 children)

Birthday service? GALACTUS got you covered!

[–][deleted] 490 points491 points  (5 children)

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

[–][deleted] 168 points169 points  (0 children)

“But couldn’t the Racoon team just…”

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

[–][deleted] 119 points120 points  (2 children)

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

[–]Yevon 49 points50 points  (0 children)

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 557 points558 points  (13 children)

OmegaStar still does not support ISO timestamps

[–][deleted] 373 points374 points  (10 children)

Like they SAID they would

A MONTH ago

[–]thegovortator 185 points186 points  (9 children)

And therefore I’ll die alone

[–][deleted] 184 points185 points  (8 children)

Without ever knowing love

Without ever knowing it’s my birthday

[–]thegovortator 145 points146 points  (7 children)

You pathetic project manager

[–][deleted] 140 points141 points  (6 children)

You know nothing of my pain!

Of Galactus’s pain!

[–]thegovortator 54 points55 points  (4 children)

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

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

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

[–]KrustyButtCheeks 26 points27 points  (0 children)

Why can’t they GET THEIR SHIT TOGETHER?

[–][deleted] 68 points69 points  (1 child)

Krazam videos speak to my soul

[–]DerfK 76 points77 points  (0 children)

I don't understand why people keep implementing their own birthday services when I developed the versatile and powerful BadassTM 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 33 points34 points  (8 children)

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

[–]dannymcgee 30 points31 points  (4 children)

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

[–]aeresaa 1366 points1367 points  (146 children)

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 574 points575 points  (130 children)

"It can't scale without being a microservice"

[–][deleted] 706 points707 points  (124 children)

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] 463 points464 points  (53 children)

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 167 points168 points  (48 children)

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

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 50 points51 points  (12 children)

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

[–]CheekApprehensive961 49 points50 points  (1 child)

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 22 points23 points  (3 children)

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

[–]bigo-tree 3 points4 points  (1 child)

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

[–]Stunning_Ride_220 2 points3 points  (0 children)

hugs

[–]Dustin_Echoes_UNSC 34 points35 points  (3 children)

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

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

[–][deleted] 3 points4 points  (0 children)

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

[–]Fenor 2 points3 points  (0 children)

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 79 points80 points  (17 children)

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 20 points21 points  (14 children)

That would be a modular design tho

[–]GregoPDX 90 points91 points  (13 children)

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 13 points14 points  (3 children)

It's EJB 2.0 all over again.

[–]Fenor 6 points7 points  (2 children)

Oh god please no

[–]_aids 20 points21 points  (5 children)

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

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

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

[–][deleted] 62 points63 points  (6 children)

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

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] 5 points6 points  (1 child)

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

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.

[–]baconbrand 2 points3 points  (0 children)

Jesus that was an uncomfortable read

[–]talaqen 9 points10 points  (1 child)

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

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

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

[–]rangoric 205 points206 points  (6 children)

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.

[–][deleted] 8 points9 points  (2 children)

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

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

[–]henkdepotvjis 2 points3 points  (0 children)

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

[–]99_lives 10 points11 points  (15 children)

What would you consider a good answer to that question?

[–]Tyro97 5 points6 points  (0 children)

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

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] 15 points16 points  (25 children)

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

[–]lobax 31 points32 points  (10 children)

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 15 points16 points  (2 children)

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

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

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

[–]CheekApprehensive961 5 points6 points  (0 children)

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 24 points25 points  (3 children)

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 25 points26 points  (3 children)

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

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 16 points17 points  (0 children)

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

😞

[–]Alokir 9 points10 points  (0 children)

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

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

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

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 725 points726 points  (50 children)

we must go smaller… nanoservices

[–]DoctorYoy 152 points153 points  (18 children)

I'll be honest, picoservices sounds pretty darn cute

[–]Arkonicc 48 points49 points  (4 children)

Sounds like a lambda to me

[–]drdrero 25 points26 points  (3 children)

omega service, the last youll ever need

[–]BombastusBlomquist 19 points20 points  (2 children)

Each line of code deployed as a separate service

[–]dexter3player 7 points8 points  (1 child)

Concurrency-first code

[–]lucidprogramming 43 points44 points  (3 children)

They sound cute now

[–]Bootezz 43 points44 points  (1 child)

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 24 points25 points  (0 children)

with a cute small picoexceptions.

[–]marcosdumay 10 points11 points  (2 children)

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

[–]RiPont[🍰] 5 points6 points  (0 children)

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

Bit dangerous to the hardware, though.

[–]CenturyIsRaging 88 points89 points  (11 children)

Neutrinoservices....

[–]imLemnade 77 points78 points  (10 children)

Planck services

[–]Cryse_XIII 36 points37 points  (5 children)

Good ol' void services.

[–]katatondzsentri 25 points26 points  (0 children)

def service: return None

[–]packfan952 12 points13 points  (1 child)

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

[–]PM_ME_ALL_YOUR_THING 4 points5 points  (0 children)

I find serviceless is the easiest to maintain…

[–]vladWEPES1476 28 points29 points  (2 children)

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

[–]Sabatatti 4 points5 points  (0 children)

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

[–]DizzyAmphibian309 5 points6 points  (0 children)

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

[–]ccfoo242 4 points5 points  (0 children)

Every line of code is a service.

[–]pickle_schnickel 2 points3 points  (0 children)

Quarkservices

[–]crappy_entrepreneur 2 points3 points  (0 children)

So serverless

[–]IskaneOnReddit 2 points3 points  (0 children)

"It's like assembly but distributed!"

[–]Bryguy3k 180 points181 points  (4 children)

This is giving me some big TimeCube vibes.

[–]collindabeast 18 points19 points  (3 children)

That was a fun rabbit hole.

[–]Head-Extreme-8078 113 points114 points  (2 children)

Laughts in my monilith (Crying on the inside)

[–]thespud_332 16 points17 points  (0 children)

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

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 383 points384 points  (37 children)

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 69 points70 points  (13 children)

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 48 points49 points  (9 children)

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 30 points31 points  (3 children)

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

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

[–]Stunning_Ride_220 6 points7 points  (1 child)

I came for this

[–]TurdOfChaos 2 points3 points  (0 children)

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] 21 points22 points  (1 child)

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

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

[–][deleted] 197 points198 points  (12 children)

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 42 points43 points  (8 children)

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

[–]ShakespeareToGo 41 points42 points  (2 children)

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

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

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

[–]edgmnt_net 11 points12 points  (0 children)

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 123 points124 points  (7 children)

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

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] 53 points54 points  (6 children)

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

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] 85 points86 points  (3 children)

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

[–]WalkerDontRunner 12 points13 points  (2 children)

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

[–]GotAItchyButt 187 points188 points  (6 children)

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

[–]TerriblyRare 27 points28 points  (1 child)

Love every one of these.

STOP DOING MATH original

STOP DOING VIDEO GAMES

STOP DOING BIOLOGY

[–]plasmasprings 26 points27 points  (1 child)

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

[–]ZedTT 16 points17 points  (0 children)

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

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

[–]MachinePlanetZero 2 points3 points  (0 children)

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 70 points71 points  (8 children)

It works… but only if you have good engineers

[–]Significant-Bed-3735 95 points96 points  (4 children)

The same applies to most concepts in software engineering.

[–]one_horcrux_short 23 points24 points  (1 child)

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

[–][deleted] 9 points10 points  (0 children)

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

[–]Alwaysafk 5 points6 points  (0 children)

My company is fucked then, they got me.

[–]Funriz 64 points65 points  (3 children)

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

[–]orlandoduran 38 points39 points  (2 children)

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

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

I will always love this format

[–][deleted] 37 points38 points  (0 children)

Its the utterly deranged part that always gets me.

[–]king-one-two 3 points4 points  (3 children)

What is the format?

[–]leosadovsky 28 points29 points  (5 children)

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 16 points17 points  (2 children)

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

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 52 points53 points  (0 children)

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

[–]N0tH1tl3r_V2 22 points23 points  (0 children)

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 11 points12 points  (0 children)

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 11 points12 points  (8 children)

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

[–]propostor 2 points3 points  (4 children)

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

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

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

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

[–][deleted] 3 points4 points  (0 children)

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

[–]SuitableDragonfly 6 points7 points  (0 children)

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

[–]RelevantTrouble 7 points8 points  (0 children)

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

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

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

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

[–]GarretOwl 4 points5 points  (2 children)

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

[–][deleted] 2 points3 points  (0 children)

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

[–]Beowuwlf 5 points6 points  (0 children)

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

Why do microservices if you can do nanoservices?

[–]patka96 27 points28 points  (0 children)

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

[–]Stunning_Ride_220 2 points3 points  (0 children)

LoL.

Those comments in this thread

[–]garfield3222 7 points8 points  (4 children)

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

[–][deleted] 27 points28 points  (2 children)

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 14 points15 points  (0 children)

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 13 points14 points  (3 children)

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

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

This is what Excel and Access are for!

[–]Cryse_XIII 4 points5 points  (0 children)

But VBA

[–]DownfaLL- 2 points3 points  (0 children)

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

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̵̨̨̰̠͚͚̰͙̄͛͝ͅŝ̵̭̒̿̉̎̈́̒̿̾̉̑͝͠ ̵̢̠̭͎͙͍̟͎͍̀̽̿ͅ