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

Why is everything so scalable?

stavros.io

Post reply on HN
Print view View original

361–370 of 383 posts

Re: Why is everything so scalable?

#361

Post by mejutoco »

mjr00 wrote: post #58

> The first problem every startup should solve is “how do we have enough money to not go bust in two months”, but that’s a hard problem, whereas scalability is trivially solvable by reading a few engineering blogs [...] Do you know what the difference between Google and your startup is? It’s definitely not scalability, you’ve solved that problem. It’s that Google has billions upon billions with which to pay for that…

> by having a single monolith you now have an implicit dependency on the same runtime working on all parts of your code

I think many people would not consider what I am going to suggest a monolith, but docker compose all hosted in the same server acts a lot like a monolith.

> particularly true in Python, where it's not a common/well-supported use case to have multiple versions of library dependencies

You can use virtual environments each with its python version and packages.

Re: Why is everything so scalable?

#362

Post by mejutoco »

williamdclt wrote: post #81
DrScientist wrote: post #27

Isn't it simple as the following? Break your code into modules/components that have a defined interface between them. That interface only passes data - not code with behaviour - and signal the method calls may fail to complete ( ie throw exceptions ). ie the interface could be a network call in the future. Allow easy swapping of interface implementations by passing them into constructors/ using factories or dependenc…

You're not missing something, but you're assuming that it's easy to know ahead of time where the module boundaries should be and what the interfaces should look like. This is very far from easy, if possible at all (eg google "abstraction boundaries are optimization boundaries"). Also, most of these interfaces you'll likely never need. It's a cost of initial development, and the indirection is a cost on maintainabilit…

I think it is more intuitive if we think of side-effects. By specifying the interface you are explicitly defining inputs and outputs. If you want to add this later, it can be very difficult to make sure you can find all the side-effects. The whole point of the interface is to explicitly limit those side-effects and extra inputs outputs to happen, so it makes sense to define in advance.

Re: Why is everything so scalable?

#363

Post by mejutoco »

afiodorov wrote: post #200

I've found that building my side projects to be "scalable" is a practical side effect of choosing the most cost-effective hosting. When a project has little to no traffic, the on-demand pricing of serverless is unbeatable. A static site on S3 or a backend on Lambda with DynamoDB will cost nothing under the AWS free tier. A dedicated server, even a cheap one, is an immediate and fixed $8-10/month liability. The cost t…

> A dedicated server, even a cheap one, is an immediate and fixed $8-10/month liability.

Personally, I am more worried about the infinitely-scalable service potentially (liability) sending a huge bill after the fact. This "liability" of $8-10 is predictable, like a Netflix subscription.

Re: Why is everything so scalable?

#364

Post by DrScientist »

8note wrote: post #282
DrScientist wrote: post #27

Isn't it simple as the following? Break your code into modules/components that have a defined interface between them. That interface only passes data - not code with behaviour - and signal the method calls may fail to complete ( ie throw exceptions ). ie the interface could be a network call in the future. Allow easy swapping of interface implementations by passing them into constructors/ using factories or dependenc…

the swap from interface to network call is still non-trivial. you get to have new problems that are qualitatively different from before like timeouts, which can break the adsumptions in the rest of your code about say, whether state was updated or not, and in what order. you also then get to deal with thundering herds and circuit breakers and so on.

Sure is more complex - but as I said key thing is to define those interfaces in a way that can be networked - you are just passing data not behaviour and the calls could fail to complete.

In terms of timing the call is synchronous and either succeeds or fails - the details like timeouts/ asynch underhood etc are hidden by the proxy - in the end the call succeeds or fails and if you surface that as a synchronous call you hide the underlying complexity from the caller.

A bit like opening a file and writing to it - most platform apis throw exceptions - and your code has to deal with it.

Re: Why is everything so scalable?

#365

Post by DrScientist »

goodpoint wrote: post #189
DrScientist wrote: post #27

Isn't it simple as the following? Break your code into modules/components that have a defined interface between them. That interface only passes data - not code with behaviour - and signal the method calls may fail to complete ( ie throw exceptions ). ie the interface could be a network call in the future. Allow easy swapping of interface implementations by passing them into constructors/ using factories or dependenc…

Yes, you are missing the cost of complexity and network calls. You are describing a distributed monolith. It does not help.

Not sure I understand. What is a distributed monolith?

I'm not suggesting that the distributed bit is still coupled behind the scenes ( ie via a data backend that requires distributed transactions ) - the interaction is through the interface.

In the end you are always going to have code calling code - the key point is to assume these key calls are simply data passing, not behaviour passing, and that they can fail.

What else is need to make something network friendly? ( I'm suggesting that things like retries, load-balancing etc can be hidden as a detail in the network implementation - all you need to surface is succeed or fail ).

Re: Why is everything so scalable?

#366

Post by Thiez »

jeffrallen wrote: post #293
gampleman wrote: post #31

Hilariously written but also too true. One start up I worked at we had 2 Kubernetes clusters and a rat's nest of microservices for an internal tool that, had we been actually successful at delivering sufficient value would have been used by at most a 100 employees (and those would unlikely be concurrent). And this was an extremely highly valued company at the time. Another place I worked at we were paying for 2 dev o…

I work at a place with 8 k8s clusters. We needed to evolve from generation 2 to generation 3 because of "manageability" or something. Gen 3 needed two clusters instead of one. Now we have 8 * (1 + 2) = 24 clusters. Happy days.

Are they aware that namespaces exist? Surely you're getting more out of your clusters by having few clusters running many pods instead of many clusters running few pods?

At my job we also have some redundant clusters but that's because we're in the middle of a transition (really two transitions, the first of which was never completed), of the 10 clusters that fall under my responsibility 6 will hopefully be gone by the end of this year.

Re: Why is everything so scalable?

#367

Post by cadamsdotcom »

Author talks about enforcing internal code boundaries within their monolith.

There is a very simple solution. Ask your AI to write you a little python script that checks which modules are imported by which other ones, and validates against a set of rules.

Prompts go something like: “we should prevent code in web route handlers from directly importing the database, make it print an error saying only repository classes can use the database directly”. It will write code that visits the python AST or maybe that uses wild regexes. The result is the same: your prompt, codified, turned into a repeatable deterministic tool you can use any time for zero tokens and that runs in under a second.

Put the script in pre-commit and husky. Keep adding rules over time. If it gets too slow, ask your AI to optimise it for you.

These tools codify the tacit knowledge needed to work in your codebase. Which is a boon for onboarding (new colleagues get blocked by it during development instead of code review.) And because it runs just before everyone commits, you have one less thing to think about when reviewing.

Re: Why is everything so scalable?

#368

Post by cadamsdotcom »

Tach, mentioned in the article, seems to be in maintained. But I dug around and found this comment:

https://github.com/gauge-sh/tach/issues/791#issuecomment-338...

> since nobody else has done it yet, i've forked tach and updated it to work on python 3.14 - https://github.com/DetachHead/dtach

Re: Why is everything so scalable?

#369

Post by jeffrallen »

Thiez wrote: post #366
jeffrallen wrote: post #293

Earlier quoted context omitted.

I work at a place with 8 k8s clusters. We needed to evolve from generation 2 to generation 3 because of "manageability" or something. Gen 3 needed two clusters instead of one. Now we have 8 * (1 + 2) = 24 clusters. Happy days.

Are they aware that namespaces exist? Surely you're getting more out of your clusters by having few clusters running many pods instead of many clusters running few pods? At my job we also have some redundant clusters but that's because we're in the middle of a transition (really two transitions, the first of which was never completed), of the 10 clusters that fall under my responsibility 6 will hopefully be gone by t…

Ah yes, transitions. Ours will also finish soon. Enjoy. :)

Re: Why is everything so scalable?

#370

Post by hedora »

daxfohl wrote: post #278
hedora wrote: post #138

Earlier quoted context omitted.

The counterargument to this point is also incredibly weak: It forces you to have clean interfaces to your functions, and to think about where the application state lives, and how it's passed around inside your application. That's equivalent to paying attention in software engineering 101. If you can't get those things right on one machine, you're going to be in world of hurt dealing with something like lambda.

I'd say the real advantage is that if you need to change it you don't have to deploy your monolith. Of course, the relative benefit of that is situationally dependent, but I was recently burned by a team that built a new replication handler we needed into their monolith, and every time it had a bug, and the monolith only got deployed once a week. I begged them to put it into a lambda but every week was "we'll get it…

That’s orthogonal to microservices. They could deploy the monolith multiple times a day.

Of course, that’d require CI, which clearly wasn’t working well in your example.

Post reply on HN