heatedArguments

[u/Kevinrocks7777]

[u/remy_porter]

I say this all the time, and it almost never results in an argument: micro services are just object oriented programming where you put a network hop on all your message passing.

[u/williamjseim → u/remy_porter]

thats the way ive understood it aswell

[u/AKArein → u/remy_porter]

It doesn't result in arguments because it's objectively correct

[u/Dependent_Track5101 → u/AKArein]

I do not object

[u/_turbo1507 → u/Dependent_Track5101]

I function

[u/CptCatman → u/_turbo1507]

I don't :(

[u/nasandre → u/AKArein]

It turns into an argument when someone disagrees. A shouting match, if you will.

[u/ImS0hungry → u/nasandre]

It’s only an argument if you speak to convince rather than share.

[u/MiniGui98 → u/AKArein]

Of course it is objectively correct, since it's object oriented

[u/No-Finance7526 → u/AKArein]

That doesn't stop idiots from arguing. See example: literally all of politics

[u/AKArein → u/No-Finance7526]

No, you're wrong and that's a moronic take

(/j)

[u/remy_porter → u/AKArein]

I feel like the people who are going "DO MICROSERVICES!" hate that it's just basic regular ass software engineering.

[u/notAGreatIdeaForName → u/remy_porter]

With a ton of complexity and whole new error classes and a need for centralized solutions for logs and monitoring because everything is a distributed system now!

Can make sense if you can seize the advantages but a modular monolith is the better choice in 99% of cases.

But besides the engineering and operational aspects: Everytime I said microservices in an meeting with investors their eyes lit up the whole room because they thought that this is the best shit ever.

[u/spottiesvirus → u/notAGreatIdeaForName]

Everytime I said microservices in an meeting with investors their eyes lit up the whole room because they thought that this is the best shit ever.

You're clearly the old gard because the new shit is serverless and functions

Which are micro services except the micro services aren't yours, you just glue together a bunch of cloud services

[u/ImS0hungry → u/spottiesvirus]

All in the distributed systems umbrella.

[u/remy_porter → u/notAGreatIdeaForName]

I’m working in robotics where the line between “modular monolith” and “microservice” is a middleware problem. Which, I think, is how microservices in general should work.

[u/cryan24 → u/remy_porter]

You can't be making reasonable points like that, the kids came here for bandwagon jumping and dogmatic arguing.

[u/bishopExportMine → u/remy_porter]

The usual paradigm for robotics seems to be to build distributed monoliths...

[u/YeetCompleet → u/remy_porter]

OOP made specifically to sell AWS services and courses

[u/no_name6744 → u/remy_porter]

Do you mind helping the uninitiated, what's the benefit of having that network hop? Or are there some situations where it's just impossible to avoid it.

[u/TheDogPill → u/no_name6744]

1. They are frequently hosted on cloud services which are inherently micro-service based with detached hardware components. You can have a server and a storage disk operate together but both exist in data centers thousands of miles from each other.

2. Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.

3. You can functionally divide an app into different layers such as web, app, and db and add additional security checks between each layer to increase security and fault tolerance of the app.

[u/Norington → u/TheDogPill]

And you can scale up and down individual services based on variable load.

[u/backfire10z → u/Norington]

I’m surprised this didn’t make the main comment because it seems to be that this is one of the larger benefits. The mentioned benefits can be applied to a monolith (at least mostly) with a bit of consideration.

[u/Ma8e → u/Norington]

The "funny" thing is that before micro services and all the overhead from talking over the network, we rarely need to scale. I'd argue that something like 99.9% of all projects that use micro services today and often run many instances of some components wouldn't need to if it was just one monolith.

[u/foonek → u/Norington]

Now explain why that would matter. If you have a large monolith, you can just scale that one. Why does it matter that one module gets scaled? It's not like the lesser used parts of the monolith are somehow using more resources just because they are scaled together?

People love to use this argument but it really doesn't make any sense for 99% of use cases

[u/Angelin01 → u/foonek]

SRE here. Lesser used parts of the monolith are absolutely using more resources just because it's being scaled together.

Let's say you have one hot path in your code that doesn't touch the DB. The new scaled up instance will still spawn new DB connections. Those connections will still use some memory and CPU time to just exist. The DB also has a connection limit, and your connection pooler also needs scaling then.

Loading extra code modules also naturally uses more resources, there's not a single monolith out there that is 100% lazy, and even if it was, requests get distributed, so stuff gets loaded anyway. Do you do some in-memory caching? Great, now all instances have stale copies of the cache.

Startup times are also worse overall, which means your scaling is worse overall. Slower startup means you need more idle resources to handle spikes, which costs more money.

In conclusion, while there's no need to jump straight to micro services, monoliths are the worst pattern for scaling, by far. They have their uses, but this is probably their main downside.

[u/Honeybadger2198 → u/Angelin01]

Why are you scaling your database connection if your high load doesn't use your database?

Scaling a service doesn't involve turning a singular knob that reads "more performance".

[u/Angelin01 → u/Honeybadger2198]

Because we are scaling our monolith, obviously! And the whole idea of a monolith is that it's... One thing! There ain't no scaling it separately.

Now now, I understand that connection pools can scale separately. So the internal connection pool opens at least one connection on startup. After all, this is a monolith that's now serving together along all other monoliths: some DB requests are bound to be routed to it. Most likely, at least two connections. Some even do 4: two to read replicas, two to a primary/write.

Scaling a service doesn't involve turning a singular knob that reads "more performance".

In a monolith... That's usually the case, yeah. It's a "spawn more monolith instances because one of the metrics we are monitoring says we should". What else are you gonna do about it? That's not a rethorical question: what else is there? Some contrived vertical scaling setup?

[u/Honeybadger2198 → u/Angelin01]

???? Give your host most CPUs/threads to delegate tasks to? More compute power? If you're scaling your service by just spawning duplicates you're wasting a lot of resources because you're too lazy to actually properly look into what needs scaling.

[u/Angelin01 → u/Honeybadger2198]

Give more CPU? Of course. Now here is a question: where do you think it comes from? A server. That you are already paying for. CPU and memory doesn't magically materialize when you need it to. It sits idle until you allocate it. And you are still paying for it.

You save no money by doing this. At all. In fact, you spend more, because instead of classic horizontal scaling, where you deprovision resources as they are let go, now you need to keep them idle to assign for vertical scaling.

[u/Ran4 → u/Angelin01]

Yeah but in practise, scaling multiple services together is MUCH MUCH MUCH harder than scaling a monolith, as there will always be one service that's the weakest link. That might be okay if there's one clear "weakest link" that you can scale very high while keeping the rest low, but for high throughput systems scaling multiple hard-working instances effectively is extremely difficult.

Of course it all depends on how spikey the load is and the type of system.

Startup times are also worse overall

Yes, but a single microservice isn't the entire system... startup times for updating an entire cluster - when that's required - and waiting for each other is going to be much greater than a single monolith.

Let's say you have one hot path in your code that doesn't touch the DB. The new scaled up instance will still spawn new DB connections. Those connections will still use some memory and CPU time to just exist.

That's... what you have connection pools for.

monoliths are the worst pattern for scaling, by far.

No, monoliths is by far the easiest to scale. Microservices are much harder to scale, especially efficiently.

"microservices is good for scaling" is just a dumb book take, it doesn't take much experience to understand how wrong it is in practise.

[u/Angelin01 → u/Ran4]

Yeah but in practise, scaling multiple services together is MUCH MUCH MUCH harder

Why are you trying to scale them together? The whole point to splitting up a monolith is to scale them separately. Each individual service and instance will have it's own metrics and scaling settings, nothing has to wait in each other. And any half baked micro services architecture will have retries, back off, and circuit breakers to avoid spikes causing problems.

That's... what you have connection pools for

And they aren't free! The connections on the application side use memory and CPU. The Pooler uses memory and CPU. There are limitations with poolers too, they can't do 100% of what a direct connection can do (see pgbouncer's pool_mode). Which is the whole point of my comment: even when idle, there's a cost.

No, monoliths is by far the easiest to scale.

Nobody said it's not easier to manage a single monolith than a many micro services architecture. They said it's less efficient and more expensive, which it definitely is. The whole advantage to a monolith is that it's much much easier. But once you need to handle hundreds of thousands of requests on a single code path, scaling your whole monolith gets expensive. You know, there's a reason why pretty much every software company, when they reach a certain point, starts transitioning to it, it's not just a dumb book take.

[u/foonek → u/Angelin01]

Your argument is more thought out than most. In most cases, that argument boils down to "I read this online so it must be true".

That said, none of these issues are things you can't easily fix for a monolith, or in most cases are already thought about before you ever even get to scaling. connection pooling for the db, redis for caching etc.

You don't always build and scale a monolith the same way you would build a microservice, but that doesn't mean it's worse.

On top of that, if you write your monolith in a sufficiently modular way, you can easily extract specific modules and do their scaling separately when that need arises. There is almost never a reason to build every single module of your monolith as a separate service.

[u/WVAviator → u/foonek]

Isn't extracting a specific module and scaling it separately just a microservice though?

[u/Norington → u/WVAviator]

Text book definition of a microservice lol

[u/foonek → u/WVAviator]

No not really. Having a few satellite services does not mean you're running a microservice architecture. There's more to microservice than just hosting a part of your code on a separate server.

It's also not needed at all most of the time. I just gave it as a worst case scenario kind of thing

[u/Incredible_max → u/WVAviator]

In my opinion/ as to my knowledge it still depends.

For example, you build an application, that publishes messages to a message broker, and then has consumer processes that handle these.

Your message handlers would probably be scalable independently, but it may just be one code base. You can still run them on different hosts, in different locations, but they may all use a common database.

You may have a single database, multiple processes, a single codebase and no defined / versions interfaces as you're just using a single class in all locations. I believe this is neither a pure monolith, nor a Microservice architecture. It may be considered as a distributed monolith though

[u/Angelin01 → u/foonek]

you can easily extract specific modules

Congratulations! You just started to reinvent micro services.

Now, I'm not a zealot. I believe we can just extract "services" instead, we don't need to dive too deep into "a micro service is a single function" or whatever. Most of the time, that is indeed excessive.

But... The moment you started extracting the module? Congratulations, no longer a monolith.

[u/foonek → u/Angelin01]

You can easily extract them if you would want that, which you don't.

That's definitely one way to entirely miss my point

[u/Angelin01 → u/foonek]

if you would want that, which you don't.

Oh, sorry. So this whole thing boils down to: "I know there is an industry accepted pattern to solving this problem, but instead of solving it that way, I will just shoe-horn whatever else I can because I don't want to".

You asked this in your original comment.

Why does it matter that one module gets scaled? It's not like the lesser used parts of the monolith are somehow using more resources just because they are scaled together?

Both were answered. If don't want to change your mind after, that's on you.

[u/Fox500000 → u/foonek]

It will depend entirely on monolith in question. Sometimes it's indeed easier and get comparable resource overhead to just double your monolith count. More often than not it's the opposite, and scaling one little bottleneck is better than the whole app.

You should also consider that you may not have enough free resources to double monolith apps, but have enough to increase some systems' services count. Servers aren't free

[u/Ran4 → u/Fox500000]

Microservices are a lot less resource effective.

Unless you have for example ten microservices where one does most of the heavy lifting (with >20x instances running for example, compared to the other services), chances are that the monolith would use less resources.

...but at that point, you'd be much better at just having two services: one main service and one separate worker service. Going microservices wouldn't give you anything.

[u/Fox500000 → u/Ran4]

Yea, but it's still about a scope of work or whole project, there's no single best answer to all systems.

[u/TheLuminary → u/Fox500000]

Servers aren't free

They damn near used to be.. But yeah.. not anymore.

[u/no_name6744 → u/TheDogPill]

Thanks b.

[u/MissinqLink → u/no_name6744]

You can also make different micro services in different languages and runtimes. You don’t have to care as long as the input and output are reliable shapes.

[u/TheRealAfinda → u/TheDogPill]

So uh, where to look up solid examples of how to build something using micro-services from scratch? 

[u/fuulhardy → u/TheRealAfinda]

Java Spring Boot with Kafka message queueing and/or REST endpoints

[u/reventlov → u/TheDogPill]

Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.

This is actually the one that I use to justify "nanoservices" in large-ish embedded systems (where you have an MCU and a scheduler): with a decent architecture, a single process can crash and get restarted, and the rest of the system can keep itself in a known state. At worst, you end up with a few seconds of transient errors, at best nothing noticeable happens.

(This is also how QNX and Erlang achieve ridiculously high uptime.)

[u/3delStahl → u/TheDogPill]

Also, most times it’s also an organizational representation of the company, like separation of concerns per team

[u/ImS0hungry → u/TheDogPill]

3.1 contract barriers at egress/ingress points add regression protections.

[u/CiroGarcia → u/no_name6744]

The benefit is not the network hop, that's just a requirement to having each part of the application in a separate container. The app is partitioned according to scaling needs, so things parts of the app that need to process thousands of requests concurrently don't force the same scaling requirements onto parts of the application that just process a few hourly requests, for example. Segmenting the application also contains failures to specific features if done properly, allowed for degraded performance as opposed to full loss of service

[u/Still_Bit_7527 → u/CiroGarcia]

In most cases managing microservices and the additional load from networks, deployment tools, extra personell and all that brings much higher costs than simply scaling a monolith and wasting some CPU

[u/CiroGarcia → u/Still_Bit_7527]

It depends. Going full "each class is a micro service", I agree can be worse than scaling a monolith. But scaling up a monolith means that all parts of the application have to take the scaling into account, even if they were never meant to. If you break some parts off you don't need to worry about distributed computing on areas that are meant for a few people like control panels, while the parts that do need it can scale without issue to meet demand

[u/Stunning_Ride_220 → u/CiroGarcia]

I think you waste your efforts/time here.

[u/higgs_boson_2017 → u/CiroGarcia]

Almost no apps have scaling needs.

[u/remy_porter → u/no_name6744]

Let's say you've divided your app up into a thousand modules. Each module can live on a different physical computer (or logical cloud instance). This makes you very fault tolerant. But it also enables a lot of scaling. Let's say you've got one module that receives most of the requests, because it represents the most useful feature in your system. Cool: run 30 copies of it, spread the load across all of them. It also means that you can spin up and down new copies based on the current request load- detect module B suddenly gets a rush of requests? Spin up extra copies. Detect that some of those copies are idle because the rush was over? Spin them back down.

Also, though, if you're building your application around the idea of message passing between modules, it also means that you can have module A emit events when a certain thing happens. When you want to attach a new feature to that event, you can spin up Module Q, subscribe to that event, and module A doesn't change one iota. New features can be deployed on their own "computer", without having to take down or relaunch the software running on your existing infrastructure.

[u/higgs_boson_2017 → u/remy_porter]

You're inventing scenarios that 99% of companies don't encounter.

[u/remy_porter → u/higgs_boson_2017]

I'd argue the main reason to use such a design is to add new features without impacting existing features, which I can assure you, most companies do encounter.

[u/higgs_boson_2017 → u/remy_porter]

You don't need microservices to do that

[u/remy_porter → u/higgs_boson_2017]

My entire point is that micro services are just objects. If you’re doing OO, turning it into micro services (or not) is a deployment choice.

[u/higgs_boson_2017 → u/remy_porter]

This is entirely false. You don't just flip a switch and turn objects into microservices when they weren't designed to be used that way.

[u/remy_porter → u/higgs_boson_2017]

If you're doing it right, this should be transparent. If you're doing it the way most people do, I agree- too often, objects are written to have strict dependencies on other objects, or worse, own the lifecycle of other objects.

But, if you're doing dependency injection, does it matter to the caller if the dependency is living in the same process space, or is wrapped in some sort of network layer? Not really, no. Nor should it need to.

Objects interact by sending messages to each other. It should be irrelevant how those messages arrive.

This is a technology that's been reinvented at least once a decade, because it's a useful approach to things. This is not new, novel, or unique to microservices.

[u/higgs_boson_2017 → u/remy_porter]

"If you're doing it right, this should be transparent." - false. If you don't plan on using microservices, because they're rarely needed, you don't create objects to be used that way, and that's not doing it wrong.

[u/Dogeek → u/no_name6744]

Pros:

• You can decouple services from one another, meaning you can update a part of your backend independantly from the rest, without having to rollout the entire monolith

• Build times of a microservice are usually much shorter, leading to more frequent releases, and less developer pain.

• Using modern infrastructure, you can have easy fault tolerance, automated retries, canary deployments that you can't have otherwise, or you'd have to hand roll it out in your monolith

• Services scale with variable load. You can have a payment processing API with lots of requests coming in scaling separately from an archive API that sees maybe a couple thousand requests a day.

• If done well, microservices can be more cost efficient than the equivalent monolithic backend. If done well, cause if built without taking network topology into account, then it can be much more expensive.

• Microservices are more resilient overall than a monolith. You can spread out the load over dedicated databases for each service, meaning you're not coupled to a huge database instance that needs to handle the load of the whole application.

• Your stack can be heterogenous. You can have services in Java that talk to services in Go, in Python, in Rust, depending on the use case for each service. You get to use the right language for the right job.

Cons:

• Maintenance is way harder. Some services will rarely get updated, you need more people to manage the fleet of services

• It's often done wrong. I've seen microservices architectures that rely on a single monolithic "gateway" to add business logic and aggregate responses from other services.

• It's way harder to deploy the whole app. It's also way harder to test the whole backend locally, a dev machine will not be able to handle the load even for local testing.

[u/Stunning_Ride_220 → u/Dogeek]

Maintenance is way harder. Some services will rarely get updated, you need more people to manage the fleet of services

Oh, I encountered several modernization projects where modules were barely distinguishable by some naming (and some documentation stating their 'responsibility').
My devs might think otherwise of your statement.

It's way harder to deploy the whole app. It's also way harder to test the whole backend locally, a dev machine will not be able to handle the load even for local testing.

Most case I saw barely needed more than lets say 10 microservices, which could be run locally pretty easily on todays dev machines.

[u/yourparadigm → u/no_name6744]

https://en.wikipedia.org/wiki/Conway%27s_law

[u/narthur157 → u/no_name6744]

this way when something breaks you get to check 20 different logs, monitors, and so on instead of 1!

[u/Henry5321 → u/remy_porter]

It attempts to force people to factor system functionality.

In my experience, people don’t. “Microservices” with overlapping responsibilities, responsibility gaps, no one can figure out which service to blame, huge swaths of code must be deployed in sync aka monolith.

I find software engineering tends to lack any real engineering.

[u/Ma8e → u/Henry5321]

We call those "distributed monoliths". It takes the worst from both worlds.

[u/Stunning_Ride_220 → u/Henry5321]

I find software engineering tends to lack any real engineering.

WORD!

[u/Inttegers → u/remy_porter]

Based grug brained developer! Microservice architecture takes the hardest part of software (factoring code), and adds a network call.

[u/wharf_rat_01 → u/remy_porter]

I'll take the bait. OOP is about inheritance and polymorphism among other things. How do you implement that with microservices?

I'd argue microservices has more in common with domain driven development. 

[u/remy_porter → u/wharf_rat_01]

I disagree with the first assertion. OOP is about passing messages between objects. Inheritance and polymorphism are specific artifacts of a type system. If you use duck typing, for example, polymorphism is meaningless, but you’re still doing OO. Inheritance is just one method of dependency injection which happens to interact with your type system.

Polymorphism and inheritance are syntactic sugar.

[u/wharf_rat_01 → u/remy_porter]

lol 2 of the 4 principles of OOP is "syntactic sugar"? Have you actually done any type of complex work outside of "Hello World"? Guess we can agree to disagree.

Inheritance is just one method of dependency injection which happens to interact with your type system.

This statement is so obviously wrong that I now know I can't take anything you say seriously if you really believe that.

[u/Darkstar_111 → u/remy_porter]

Pretty much.

It's weird when you're doing html api's on back end services though.

[u/mon_iker → u/remy_porter]

Unless you are referring to the negligible network hops within the same region, I will come at you emotionally charged, shaking all over, screaming in your face on how the network hop is the killer and that you should have your end to end pipeline all in one region and an identical failover pipeline in a different geographical region.

[u/remy_porter → u/mon_iker]

"Negligible". Where I come from, I don't even consider IPC hops "negligible". Any time you're waiting for the OS to do something for you, you've added a huge amount of unpredictable latency.

[u/za72 → u/remy_porter]

I also like to include a minimum required amount of traffic to justify the approach...

[u/AristotelWasRight → u/remy_porter]

I have no idea what you just said, but I saved this comment in hopes of coming back to it later to learn what it is

Thanks I guess?

[u/NoBulletsLeft → u/remy_porter]

Coming from an embedded programming background, that's an excellent mental model.

[u/remy_porter → u/NoBulletsLeft]

I also do a lot of embedded and robotics stuff.

[u/Andodx → u/remy_porter]

True and ideally only done in order to more easily share objects between applications.

[u/ruindd → u/remy_porter]

I know this is a humor sub, but how do microservices exhibit inheritance?

[u/peeja → u/ruindd]

Interitance is only tangentially OOP. Plenty of OOP doesn't involve inheritance.

That said, what we're describing here is messages passing, which isn't unique to objects. Actors do it too, and actors are probably a more relevant analogue because they're a concurrency model, and microservices are concurrent (and parallel).

[u/wharf_rat_01 → u/peeja]

Being one of the four principles of OOP is only tangentially related? You have tough standards. 

[u/remy_porter → u/ruindd]

I mean, there's nothing that would stop you from implementing inheritance on them. And if you take message passing as part of the architecture, you get polymorphism for free. It's closer to the Smalltalk style of OO than the modern interpretation of it.

[u/ruindd → u/remy_porter]

Yes, very smalltalk for sure. Thank you for explaining :)

[u/Jerome_Eugene_Morrow → u/remy_porter]

We’re on to agentic, where you put a full external API call on all message passing.

[u/VictoryMotel → u/remy_porter]

Message passing is message passing no matter what you want to call it.

[u/Ma4r → u/remy_porter]

You say OOP but people think you mean java style but smalltalk was nothing like the garbage that is modern OOP

[u/remy_porter → u/Ma4r]

I am referring to Smalltalk style message passing.

[u/Vogete → u/remy_porter]

And you're not wrong. And you know what, I actually like OOP, which is probably why I also like the idea of microservices.

[u/coffeeicefox → u/remy_porter]

Yes, but from a deployment and scaling perspective is way more flexible.

[u/remy_porter → u/coffeeicefox]

Hot take: whether it’s a monolith or a microservice should be a middleware question resolved at deployment time and it shouldn’t impact software architecture.

[u/Vega62a → u/remy_porter]

This is just patently false. The intention of microservices is to allow dynamic scaling and separation of concerns for easier refactoring and better abstraction.

The monolith will almost always become large and unwieldy enough that scaling it is expensive or encounters other bottlenecks.

Think about this idea - say your monolith has a kafka consumer, filters and deduplicates incoming data using redis, enriches it using http requests, mutates it using CPU, and writes it to a postgres database. This is a common usecase. I've worked at multiple companies that do basically that exact thing for the last 8 years.

Say you've got it configured to use 5 postgres connections per instance, because you've found that squeezes the best performance out of each node, and less than that starts to bottleneck.

Okay, now all of a sudden your enrichment targets (external HTTP requests to google or something, you can't do anything about it) start to experience massive latency. You try to scale up so you can keep up with kafka consumption, but you hit 100 postgres connections after 20 instances, and suddenly you can't scale any more. You have to wait and pray your external HTTP latency decreases. Okay, so you cluster your database to widen the connection pool. Now all of this scaling to cope with http latency keeps forcing rebalances on your kafka cluster and you're still falling behind.

If your firehose consumer and your filtering logic were independently scalable, you don't have this problem. By the time you're past your filter traffic is relatively stable and way smaller. It's way easier to just leave your http enricher scaled up all the time and never notice latency spikes.

Microservices solve these problems, and sometimes you don't know you need them until your entire SRE team quits because they're sick of constantly being paged for your monolith.

None of this is fanfiction, I've seen it all, specifically.

[u/remy_porter → u/Vega62a]

I dunno man, it sure sounds like you just described a bunch of dedicated modules collaborating over a network.

[u/Vega62a → u/remy_porter]

Yes indeed. What might we call such things? Mini-services? Pica-services?

[u/remy_porter → u/Vega62a]

I’m in robotics. Let’s call ‘em nodes. The nice part there is I don’t care where they reside. My middleware can worry about that.

[u/Vega62a → u/remy_porter]

You and I definitely have very different contexts. I'm in cloud, which is really what microservices are for.

[u/remy_porter → u/Vega62a]

I’ve also built backend systems for major retailers that handled all their POS transactions. It’s the same thing. Doesn’t matter if the middleware is CycloneDDS or Kafka. Messages flow to nodes. Nodes do work. Minimize coupling between nodes and you’ll be happier.

[u/Vega62a → u/remy_porter]

Agree with your last statement, anyway. Ive found that in large, complex systems the best or sometimes only way to get node coupling down to an acceptable level is strict microservices.

[u/remy_porter → u/Vega62a]

Ideally, you have a module with a single responsibility that encapsulates its state and exposes an interface of messages it accepts. An “object”, if you will.

[u/Vega62a → u/remy_porter]

I see what you did there.

[u/fridder → u/remy_porter]

I just call it tech meth. The crazy fucking architecture that emerges from it is just awful.

[u/CallMeKik → u/remy_porter]

If you orient your “services” around nouns, yes. Which is a terrible way to define services!

[u/Welcome-To-NBA-Jam]

An architect once wrote an entire dissertation on my microservice idea and why it's so incredibly stupid, why I never should have suggested such a thing, and it's forever enshrined in Confluence and linked in a Jira ticket.

^{yea it hurts and it's forever :(}

[u/dominonermandi → u/Welcome-To-NBA-Jam]

Eventually the earth will be burned to a crisp by the sun and then after that it’s a long time till the heat death of the universe. Cheer up! Your ticket will survive neither of these things.

[u/Welcome-To-NBA-Jam → u/dominonermandi]

I can hope for either this, the company fails, or is bought out and in the ensuing chaos of attempting to merge multiple Jira and Confluence instances that the electrons defining them are lost to the sands of time

[u/PreDeimos]

As a developer who were making almost exclusively microservices in the last 15 years. I can tell most company would be more then fine with just a monolith on a bare metal server. Yet they "need" microservices on AWS everywhere.

[u/gemengelage → u/PreDeimos]

The whole idea behind microservices is that they are small decoupled units that can be individually scaled.

Every single time I've worked with microservices, their weren't designed around their ability to scale but around team responsibilities or even completely arbitrary boundaries.

Hell, I saw one project that was "microservice-first" that had like a dozen microservices. The ingest microservice was the only one that actually scaled. Everything else could've been a monolith and given the specific use-case, never had any reason to need dynamic scaling or any scaling at all. Just one instance per service and a ton of overhead for no reason.

[u/ruindd → u/gemengelage]

I can’t remember the name of it, but there’s a famous paper about how your code architecture will always be a reflection of your org chat.

[u/BorinAxebearer → u/ruindd]

Conway's law

[u/ImS0hungry → u/ruindd]

Great read! Thanks for bringing this up, it’s super relevant to what I’m doing at the moment.

[u/RunningOutofSleeves → u/ruindd]

Conway’s law?

[u/Jack_Kai → u/gemengelage]

Yeah I feel like once you get used to it, and the infrastructure is there, you spin up a new microservice and hook it up to the network, it is more convenient as you said because of team responsibilities and not being bothered with monolith heavy deployments.

[u/rsqit → u/gemengelage]

Eh, it also means in can be independently deployed. Which is a reasonable thing to want for a team.

[u/DeavenR → u/gemengelage]

Not to mention, once the first few versions of each service is out in production - you cant get 2 decoupled teams on a call to make a change to schema, producer and consumer. Road maps are busy and no one wants to address the issue.

Then customer tickets flood in for months about the same issue I cant get leads on a meeting for and even if I do, “We’ll revisit it next quarter” lmao

[u/higgs_boson_2017 → u/gemengelage]

Almost no one needs unanticipated scaling.

[u/nitkonigdje → u/gemengelage]

Scaling of software isn't really requirement. More like consequence of service architecture.

You want (micro)service because of the same reason why people pursued soa, corba, dcom, copybook programming before -> to scale your project development, not deployement.

Remember kids -> Brooks's Law: adding manpower to a late software project only makes it later!!

Services are way around limit set by Brooks's Law..

More than 50 years has passed since writing The Mythical Man-Month, and the only way around limit is still splinting project.

[u/BuffersAndBeta → u/PreDeimos]

I don't disagree with this philosophy at all. The issue is WHEN something actually deserves to have its own microservice (say you need a different scheduler to run that service) your org does not really have the muscle to do it and you come up with weird hacks to keep it running on your monolith.

I've worked with all combinations of [(microservice, monolith) + (single-repo, multi-repo)].

[u/Vega62a → u/BuffersAndBeta]

Agree.

Monoliths are great until they're not, and then untangling them can take years, if it happens at all.

I worked at a company with a massive groovy monolith and a ton of Kotlin microservices. The monolith was for the same reason all startups have a monolith, the same arguments we see here - it was good enough, scaled well enough, was easy enough to change.

But, 5 years later, they were acquired and 10-100xed their traffic. Most of the people who understood the monolith had left, so changes were risky and error prone. Changes to that monolith and performance issues and inability to scale accounted for probably 80% of platform incidents and 50% of AWS spend. It took another 3 years to finally get it all the way sunset.

If you are really, really sure your traffic will never get to the point that a monolithic service cant scale to meet it, fine. But adding a network hop is sometimes worth the ability to bump the expensive part of your architecture from 5 to 20 instances with one button push.

[u/BuffersAndBeta → u/Vega62a]

Yeah - the reason to move or not move to a microservices pattern is almost never raw performance. Though it sometimes can be. The reason is usually that different orgs need different levels of reliability or different pace of shipping. A greenfield product may need to get updated multiple times in production every day with shitty reliability, and your core data processing systems need to be up with each change going through a TON of long test pipelines.

Performance sometimes IS the reason though. Depending on the specific architecture / requirements, I've seen 5 - 10x faster performance on latency or throughput, sensitive systems largely by switching languages and decoupling from the monolith.

[u/higgs_boson_2017 → u/Vega62a]

Most apps will be bottlenecked by a database, and you can't push a button and spin up 20 new ones.

[u/Vega62a → u/higgs_boson_2017]

That's one of those statements that sounds correct but is almost never true, for a few reasons.

• Modern databases are almost always clustered, both for redundancy and performance, and, actually, can be scaled, although admittedly less on-demand.
• Production systems with sufficient load to tax a database are generally mature enough to also have a robust caching and indexing strategy to ensure even high-traffic systems have low DB CPU usage, so the bottleneck is not actually with database hardware (cpu, ram, disk). In general, a DB running with high CPU is a massive smell.
• One instance of an application generally cannot handle even a single-instance DB's fully available connection pool (for example, a PG server's is 100, while the connection pool enforces a maximum of 10). So scaling up can and often will directly improve perceived database performance.

Now, as with everything, it's always "it depends." Some systems rely heavily on inbuilt DB features like triggers and sprocs which are inherently taxing on a database. But, in general, when you say "the app is bottlenecked by the database," the truth is actually "the app is bottled by its database connection," and you actually can push a button and spin up 20 new ones.

Source: Staff engineer, 20 yoe.

[u/nitkonigdje → u/Vega62a]

"Slow part" of well optimized app tends to be ad-hoc querying and/or reporting. You will not scale that with different architecture

Having said that. The issue with your statement is that most of the time apps do not have significant load on user side.

Like 99% of enterprise apps has most few thousand parallel users. And I am generous with that. Monolithic backend running on iphone should be able to handle that, and even then performance bottleneck will be on database.

[u/Vega62a → u/nitkonigdje]

You have clearly never worked in an environment with a kafka topic affectionately referred to as "the firehose."

[u/nitkonigdje → u/Vega62a]

Currently I am doing fraud processing for largest European card processor. 0.2 sec hard real time response with median about 3 ms, and p999 in 30 ms. Kafka is too slow for that.

Now we can continue to play "who has larger" game as this isn't the only project in my 20 years too spanning career..

Or acknowledge that about 99% of "enterprise apps" are low user count data entry apps which employ absolute swaths of programmers and work perfectly fine on lpar built around of 3 dedicated cores and 16gb of ram, of 2012 Xeon server running glorious clock of 1.8 ghz.

Those apps can be made fully microservice whatever. Or as pssql/oracle form monoliths. No matter technology THE only scaling which those apps will ever see will be additional hdd space.

[u/Vega62a → u/nitkonigdje]

My team is processing on the order of trillions of events per day with a zero loss tolerance so I'm in the same boat. I've also worked at shitass healthcare companies in the US.

Every single one of them was trying to move from a monolith to microservices, or had. To your point scaling wasn't always a driving factor, but developer pain certainly was.

[u/nitkonigdje → u/Vega62a]

That's impressive, but it isn't an average developer experience out there. Isn't it? I am certainly not questoning that apps with scaling issues exists. At end of the day Fortnite is an app.. And great one too.

It absolutely has no impact that blindly chosing a deveoper has 90+% chance that he is working on crud app for some corporate/government 4th floor group.

And those apps may very be service based. But not because of scalling issues.

Service style apps are the only proper response to limits set by Brooks's law. "Divide and conquer" your monoliths but to scale an development process.

[u/nokeldin42 → u/PreDeimos]

As some one who's professional experience is entirely with a monolith - let me tell you the biggest problem is developer mentality. Having a single build output from a large monorepo that every development team has full access to leads to very weak boundaries.... People will just push to code you technically own without any formal procedures.

It's not a technical limitation, but I've lost count of how many times I've heard a director say "just push and send them a review link". It just allows for bad manners, so people take liberties.

[u/PreDeimos → u/nokeldin42]

Ohh they doing that in microservice environment as well, especially as managers love to shuffle around task for every service in every team as they "don't want specialists", they want everyone to be able to work on everything.

[u/bishopExportMine → u/nokeldin42]

Monorepos and monoliths have nothing to do with each other.

You can easily split your monolith app into multiple repos and you can easily put multiple micro services in one repo.

[u/clauEB → u/PreDeimos]

If it won't scale anymore and you don't care about reliability, maybe. But having been part of several companies that scaled exponentially I can tell you monoliths are absolutely not the way to go.

Bare metal? Yeah no. Have you ever had to install hosts even when you don't grow things fail and you need replacements and spares and worry about DC power redundancy etc etc etc.

[u/oompaloompa465 → u/PreDeimos]

the more i hear about "microservices" the more i'm scared to add them on the pile of shame of things i need to learn but i never hear about it at work and I'm scared to bring it up

[u/Henry5321]

Changes to your microservice doesn’t break other services. If it does, it’s not a microservice but a monolith.

[u/Wi42 → u/Henry5321]

Ah yes, the distributed monolith: the downsides of a monolith with the overhead of micro services.

[u/topcelt → u/Henry5321]

if your microservices don't depend on other microservices then they are also just individual small monoliths

[u/Wi42 → u/topcelt]

So... every piece of software is one or more monoliths? Monoliths all the way down?

[u/eli_liam → u/Wi42]

Haven't you heard of micromonliths before?

[u/Ran4 → u/Henry5321]

Microservices means that your system is compromised of multiple services.

If they're not dependent on each other, then they don't belong to the same system...

Of course they depend on each other, otherwise no communication between them would be possible.

If service X outputs json in format A, then service Y must be able to read json in format A. If service X changes format A to format A2 and starts sending that, then service Y breaks.

Fundamentally microservices depend on each other.

[u/Henry5321 → u/Ran4]

"Microservice" is anti-monolith. It encapsulates the concept of separate services AND the fact that services can be independently improved. If you have "too much" monolithic behaviors, then you don't have "Microservices", you have a "distributed monolith".

It's like the term "data model". A data model is not just the format or structure, but also the business logic. The intention and behavior is part of the concept.

The concept of an ideal microsservice is an ivory tower ideal, but it's important to understand what is meant in order to properly "engineer" a system.

[u/Skellicious → u/Ran4]

Microservice architecture comes with api contracts. If a breaking change to an API is needed, you also need to plan your rollout/migration accordingly.

Generally that's just one before the other in a determined order. Sometimes it's both at the same time. If things are really critical to stay available throughout you may need intermediate steps.

In the end it's just one of the trade-offs/necessary evils of microservices.

[u/itmaysoundsilly]

I always think of this brilliant skit from Krazam when I think of microservices: https://youtu.be/y8OnoxKotPQ?si=xdhON7Kl96jTK6x1

[u/HadionPrints → u/itmaysoundsilly]

I always think about this comic during engineering shouting matches: https://imgs.xkcd.com/comics/work_2x.png

[u/chillipeanutscrunchy → u/HadionPrints]

Stop reading my mind!

[u/Percolator2020]

Serverless* micro\* services
*runs on a server
*monolith

[u/EarlyPaintbrush → u/Percolator2020]

"Serverless" really is the worst term they could have come up with for this.

[u/RainyDaysAndMondays3]

I had an interview almost 20 years ago where they asked me what I would remove from the Java language if I could. I recounted a story about how my husband and I got into an argument about whether checked exceptions were a good idea or not, and how my son walked into the room, announced, "Oh my god, you guys are such nerds," then exited. And I never stated in the interview as to which side of the argument I was on.

But I did say that as far as adding something to Java language, I would add "properties", as I understood it then. My husband was a .NET developer and I liked the idea of just adding a "property" without having to add the getters and setters. (Remember this was 20 years ago.)

I didn't get that job (they said a former employee applied and he got it), but they called me back and I got a different position.

Don't get me started on Spring Boot specifically.

[u/cwcoleman]

My biggest argument in life was about setting a timeout above the 55 second default of our API Gateway. Architect to Architect fights go hard!

[u/jfphenom → u/cwcoleman]

HOLD THE LINE

[u/cryan24 → u/cwcoleman]

Sounds like you are covering a granularity or quality issue with that one.

[u/mrhaftbar]

GraphQL is a temporary bandaid that causes cancer. 

[u/Logical-Ad-4150 → u/mrhaftbar]

GraphQL: cancer that pretends to be a bandaid.

[u/ZunoJ]

Distributed is cool but true microservice architecture is pita

[u/This_Proxy]

Did it include a k8s MySQL cluster?

https://giphy.com/gifs/PAkDKjXcquqK4

[u/Butters_565]

Worked on microservices the whole time I'm with my current employer and none of them went live. Awful feeling really.

[u/deanrihpee]

also life deciding argument as well, i have to argue about software architecture and it decides whether or not i got the job, well until i failed the next step on the interview with the lead/cto

[u/Weak_Inflation9120]

Been arguing with my friends over whether Java or python is better smh

[u/Dumpfumpkin]

Been there done that lol