Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths are not dinosaurs

allthingsdistributed.com

Post reply on HN
Print view View original

201–210 of 243 posts

Re: Monoliths are not dinosaurs

#201

Post by EasternGuy »

disgruntledphd2 wrote: post #188
jowdones wrote: post #145

Earlier quoted context omitted.

So using the "wage slave" rethoric is punished now by the Thought Police. Happy happy thoughts and be greatful for the opportunity to trade our lives for a measly pay working for the man.

It's just kinda crap. It's not the same bloody thing. FWIW, I agreed with the general point but disagreed with the language. I commented to make the OP aware, as I always dislike being downvoted with no explanation. Shrug, it's not like I can pay my mortgage with HN karma.

"Slavery" is a powerful word, understood universally, with high chances of proving the point and making an impact when used.

Your censorship of it's usage may have been done on good intentions but the results are nefarious.

Does it seem to you that we are living in some Nirvana / restored Heaven Of Humanity? Take a look at this, wage slavery makes 25% of work classification: https://www.nirandfar.com/wage-slaves/

Confining the word "slave" to some well-in-the-past primitive dawn of humanity and punishing us for using it to depict the deplorable state of humanity today does nothing for improving said state and makes you in the best case one of the "useful idiots" of the establishment ( https://en.wikipedia.org/wiki/Useful_idiot ).

How do you define a "slave"? Think of this definition: "a slave is any person that trades their time in exchange for the right to live". Does it seem to you that Elon Musk is a slave? How bout someone working on a computer 1,000,000 times more powerful than 30 years ago and going through even more drudgery with less stability and guarantee of making a living out of the productivity increase?

Is it really the best that civilization can throw at the versatility and capability of the human mind? Fixing bugs in the 100'th million line of crap framework code and the perspective of being replaced by a statistical model? That's your glorious "non slavery" world you censor from using?

Re: Monoliths are not dinosaurs

#202

Post by murdoze »

paulddraper wrote: post #37

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

Microservices reveal communication.

I believe we do not have the right tools yet.

Re: Monoliths are not dinosaurs

#203

Post by viraptor »

osigurdson wrote: post #187
viraptor wrote: post #89

Earlier quoted context omitted.

> "we have 100 people so require 20 microservices" Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

I personally know of a two person team that claims to have over 100 microservices. I think most are just lambda functions however.

Sure, but the question was - are they forced to split new microservices just because they have more people? Or is it just how they decided to split up the app in a logical way.

Re: Monoliths are not dinosaurs

#204

Post by gabereiser »

SAI_Peregrinus wrote: post #75
gabereiser wrote: post #68

Earlier quoted context omitted.

there's String, string, std::string, and the satanic *char. Just like there's Slinky, Super Slinky, Extra Slinky, Heavy, and Pro. Nickel-wound (ref counted), steel wound (raw array), and classical nylon (a fucking pointer).

What are gut strings then? Indexed addressing?

lol, those would be raw pointers as well but at the asm level with registers. Joking aside, gut strings are extremely rare outside professionals. I’m not surprised to see it mentioned with this crowd. Cheers for tickling this music nerds interests.

Re: Monoliths are not dinosaurs

#205

Post by charrondev »

tracker1 wrote: post #196
Zanfa wrote: post #120

A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed. Never seen it work, don’t think I ever will. The only way microservices can ever work is if they’re extracted over time as the monolith gets fleshed out, likely over the course of years. And even they’re probably a bad idea.

Or... if you're working in an organization that already has a Microservice based infrastructure in place. Otherwise, I generally agree... I'll usually take a monolith approach and break things off in ways that make sense. Usually starting with long running processes that can simply be workers off of queues. Sometimes potential bottlenecks that have higher compute overhead, such as passphrase hashing and comparison wh…

Isn’t something paraphrase hashing something that should be heavily rate limited?

In order to DoS your typical site through passphrase hashing you would need to be:

- have a ton of valid usernames/emails of accounts that need to be checked (because a typical password check will rate limit by account) - send in a massive torrent of traffic from a ton of IP addresses (because a typical password check will be rate limited by IP, even more than typical IP based rate limiting)

While this is not impossible if you had those resources it still might be easier to just DoS the site though standard pages/ endpoints by sheer traffic.

Re: Monoliths are not dinosaurs

#206

Post by selcuka »

gabereiser wrote: post #194
selcuka wrote: post #183

Earlier quoted context omitted.

Obviously you haven't seen the Substring [1] type of Swift. [1] https://developer.apple.com/documentation/swift/substring

But this is a slice. So technically a []char?

Not really. It's only a reference to the original string, a start index, and an end index. It doesn't store a second (partial) copy of the string.

Re: Monoliths are not dinosaurs

#207

Post by simplotek »

paulddraper wrote: post #37

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain?

The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. Sure, there are plenty of advantages in scaling and reliability, but where microservices are worth their weight in gold is the way they impose hard boundaries on all responsibilities, from managerial down to operational, and force all dependencies to be loosely coupled and go through specific interfaces with concrete SLAs with clearly defined ownerships.

Projects where a single group owns the whole thing will benefit from running everything in one single service. Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.

Re: Monoliths are not dinosaurs

#208

Post by simplotek »

paulddraper wrote: post #192
LudwigNagasena wrote: post #155

Earlier quoted context omitted.

That just makes it a tautology. It basically says “essential complexity exists”.

It's a frame of mind. Often a developer will see something big or complex and see it as a problem. But they should consider whether this matches the size/scope of the problem being solved

> But they should consider whether this matches the size/scope of the problem being solved

In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.

Re: Monoliths are not dinosaurs

#209

Post by simplotek »

lelanthran wrote: post #152
paulddraper wrote: post #37

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

> Complexity can neither be created nor destroyed, only moved somewhere else. I have to say that this short quote is not the whole story; for example it's ridiculously common for artificial complexity to be introduced into a system, like using microservices on a system that gets 1k users a day. In which case, it is sometimes possible to remove complexity, because you are removing the artificial complexity that was ad…

> (...) like using microservices on a system that gets 1k users a day.

This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds.

Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.

Re: Monoliths are not dinosaurs

#210

Post by benjiweber »

viraptor wrote: post #134
benjiweber wrote: post #113

Earlier quoted context omitted.

It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/ Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.

That doesn't translate from the mandate, which is what I'm trying to cautiously call out. There's a big difference between "our company will not have a god database" and "we need to make more services just because we have more people". The link also mentions that the mandate was "something long these lines" - we don't know exactly what the split rules were. I think people bring up an exaggerated idea of extreme micro…

It does if there's an upper bound on the number of people in an effective team.
Post reply on HN