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

151–160 of 243 posts

Re: Monoliths are not dinosaurs

#151

Post by vinay_ys »

kqr wrote: post #144
vinay_ys wrote: post #128

Earlier quoted context omitted.

Both essential complexity and accidental complexity can be created or destroyed based on how functional scope or technical scope is defined and understood. In a live and evolving system, a lot of complexity is also because of not having a vision for how the product domain or market or ecosystem might evolve and having a coherent shared understanding of it amongst product managers and platform builders. When product d…

Do you have a suggestion on how to avoid the flip-flopping problem? Or is there a way to turn with the wind without increasing complexity? Genuinely curious.

Well, flip-flop is usually due to heavy investment too early – on poorly formed thesis of a potential product-market fit or business model (ie., vision). Early days has to be about optimizing aggressively for speed of learning/validation/formation of thesis.

There has to be an overarching thesis that is well-formed (formed based on experience/tests from adjacent/related markets, key assumptions validated at reduced scale, strong backing by investors/founders etc).

During this vision formation/validation stage, keep things very lightweight and don't over-invest in prolonged tech platforms.

For example, if your product/service has an on-the-field operational part to it, then run that part with manual operations with pen/paper – pen/paper is extremely flexible and universally usable and survives all kinds of surprises in the field – don't wait to build a software solution to test your thesis in the field. Manual ops can scale quite well especially during learning phase (scale is not your goal, learning/validating is). Choose the use-case for your experiments carefully – optimizing for fast learning and applicability of that learning for next adjacent use-case you intend to expand to.

Once you get going, still build the tech systems without dogmas or baking strong opinions in too much. Keep your engineers generalists and first principles problem solvers and interested in solving both tech and functional-domain problems and encourage them to be humble and curious – because both the functional and tech world is constantly changing. Don't hire a huge product management org – every engineer/manager should be thinking about customer/product first. Over time, parts of your product are more mature and parts of your product are very nascent and still volatile. If your entire team is still thinking customer/product first and build tech to solve problems from first principles, then they should have found the right coupling/cohesion balance between different parts of the system to avoid shared fate, high blast radius or high contagion of that volatility/instability affecting more mature parts of the system.

Re: Monoliths are not dinosaurs

#152

Post by lelanthran »

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

Re: Monoliths are not dinosaurs

#153

Post by criley2 »

pbreit wrote: post #34
bovermyer wrote: post #11

You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.

Now that PHP has lost its massive deployment advantage, step up to Rails or Python.

Rails and python aren't a step up from PHP for webservers. Both are massive steps down in terms of real world performance. https://www.techempower.com/benchmarks/#section=data-r21

Personally if I was "stepping up" from PHP and wasn't going to use something powerful (or didn't need all that power) I'd be stepping up into javascript and nextjs and stuff like that.

Re: Monoliths are not dinosaurs

#154

Post by yuvadam »

Microservices were a zero-interest rate phenomena that benefited no one but cloud service marketing teams.

As money becomes more expensive and as we inch further towards a massive economic crisis, companies that have allowed their R&D budget to bloat out of proportion with needlessly-distributed architectures are NGMI.

Re: Monoliths are not dinosaurs

#155

Post by LudwigNagasena »

dimtion wrote: post #41
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…

Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."

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

Re: Monoliths are not dinosaurs

#156

Post by KyeRussell »

NohatCoder wrote: post #150
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.

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service. The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

> because some job fits being its own service

Determining this at all takes skill. Determining it that far ahead of time requires so much skill and foresight that suggesting that people try is bad advice.

Re: Monoliths are not dinosaurs

#157

Post by zo1 »

osigurdson wrote: post #92
Spivak wrote: post #84

Earlier quoted context omitted.

I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.

Micro-services are currently on trend so hard to argue with unless you are a founder. Maybe the best thing to do for the industry in general is go absolutely nuts with microservices. Factor projects so every method is a separate service / lambda. If anyone complains, use the single responsibility principal to snuff out all opposition. Once we've explored this to its logical conclusion the pendulum will swing back to…

I got tired of arguing against microservices just like I got tired of arguing against SPAs and multi-repos.

And at least with one of them, the pendulum has already started swinging back. The cool-kids (aka "javascript hipster devs") have re-discovered the concept of a monorepo and are pushing for it hard, making it seem like some sort of new concept with fancy tooling. It'd be funny if it wasn't so caricatured and a sad state of our industry.

Re: Monoliths are not dinosaurs

#158

Post by ProZsolt »

NohatCoder wrote: post #150
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.

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service. The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.

Re: Monoliths are not dinosaurs

#159

Post by lakomen »

sgtnoodle wrote: post #60
bedobi wrote: post #55

Earlier quoted context omitted.

What do you mean "the type of strings"? In pretty much every programming language, String is one of the most fundamental types. There's no "different types of string". (yes, this is a joke, a bad one at that. badum tish)

When I worked at Google, they had their own string type in place of std::string for various reasons. Python has byte strings, Unicode strings, format strings, regular expression strings, and probably a few others! Rust has str and String, depending on ownership.

> Rust has str and String, depending on ownership.

Why I hate Rust

Re: Monoliths are not dinosaurs

#160

Post by anonzzzies »

Aeolun wrote: post #45
keyle wrote: post #32

Earlier quoted context omitted.

There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.

If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.

The first thing I hear from the tech lead/CTO or whatever when I walk into a company is 'we are going to use microservices', then a lot of kubernetes, sqs, lambda etc. And THEN they talk about what the project is. I only didn't manage to keep away from a monolith for a fraction of the money and time; it was a huge fail; 20m$ burnt on engineers and aws and the endresult was a painful burning pile of nuclear waste. They had money to burn so they are still alive, but I should've walked out after the CTO pushed microservices past his team (his team + my team) who said it was nonsense in this case (it's in all cases, but whatever, I cannot prove that so).
Post reply on HN