A VPS, caddy, sqlite and livestream is really all you need in my experience. Help's if your language has decent support for real and green threads (java/go/clojure).
Why is everything so scalable?
211–220 of 383 posts
Re: Why is everything so scalable?
#212> The first problem every startup solves is scalability. The first problem every startup should solve is “how do we have enough money to not go bust in two months” Why is the second question the devs' responsibility? Shouldn't it be the founders'?
Because how the devs decide to build the system influences whether you will have enough money to not go bust in two months.
Good point, but unless the only dev is also a founder, I'd think they aren't the ones with the responsibility to come up with a business model.
They definitely have the responsibility to write software so it most efficiently serves that business model.
Re: Why is everything so scalable?
#213Earlier quoted context omitted.
> This argument comes up a lot, but it feels a bit silly to me. If you want a beefy server you start out with renting one. $150/month will give you a server with 24 core Xeon and 256GB of RAM, in a data center with everything you mentined plus a 24/7 hands-on technician you can book. What's the bandwidth and where can I rent one of these??
Hetzner [1]. Bandwidth is 1 GBit/s. You can also get 10 GBit/s, that's hidden away a bit instead of being mentioned on the order page [2] 1: https://www.hetzner.com/dedicated-rootserver/matrix-ex 2: https://docs.hetzner.com/robot/dedicated-server/network/10g-...
Not ideal when a large part of your userbase is in APAC.
Re: Why is everything so scalable?
#214I've seen startups killed because of one or two "influential" programmers deciding they need to start architecturing the project for 1000TPS and 10K daily users, as "that's the proper way to build scalable software", while the project itself hasn't even found product-market fit yet and barely has users. Inevitably, the project needs to make a drastic change which now is so painful to do because it no longer fits the…
> 1000TPS and 10K daily users I absolutely agree with your point, but I want to point out, like other commenters here, that the numbers should be much larger. We think that, because 10k daily users is a big deal for a product, they're also a big deal for a small server, but they really aren't. It's fantastic that our servers nowadays can easily handle multiple tens of thousands of daily users on $100/mo.
Users/TPS aren't the right metric in the first place. I have a webhook glue side project that I didn't even realize had ~8k daily users/~300tps until I set up Cloudflare analytics. As a go program doing trivial work, the load is dwarfed by the cpu/memory usage of all my seedbox related software (which has 1 user, not even every day).
Re: Why is everything so scalable?
#215Earlier quoted context omitted.
> AWS takes that away and makes you focus on the product. Issues arising from AWS only requires you talking to support. Not my experience at all. e.g. NLBs don't support ICMP which has broken some clients of the application I work on. When we tried to turn on preserve-client-ip so we could get past the ephemeral port limit, it started causing issues with MSS negotiation, breaking some small fraction of clients. This…
I agree that building your backend on Lambda is terrible for many reasons: slow starts, request / response size restrictions, limitations in "layer" sizes, etc. RDS, however, I have found to be rock solid. What have you run into?
The parent compares RDS to baremetal, which I think isn't a fair comparison at all. Especially since we don't know the specs of either of these.
I found RDS to be rock solid too, although performance issues are often resolved by developers by submitting a PR that bumps the instance size x2, because "why not". On baremetal it's often impossible to upgrade CPU just like that, so people have to fix performance issues elsewhere, which leads to better outcome at the end.
Re: Why is everything so scalable?
#216>The first problem every startup solves is scalability.
I don't think this is true at all. The first problem they solve is typically finding product market fit, which startups will do by sacrificing scalability and quality for speed of execution.
Re: Why is everything so scalable?
#217Earlier quoted context omitted.
> 1000TPS and 10K daily users I absolutely agree with your point, but I want to point out, like other commenters here, that the numbers should be much larger. We think that, because 10k daily users is a big deal for a product, they're also a big deal for a small server, but they really aren't. It's fantastic that our servers nowadays can easily handle multiple tens of thousands of daily users on $100/mo.
Users/TPS aren't the right metric in the first place. I have a webhook glue side project that I didn't even realize had ~8k daily users/~300tps until I set up Cloudflare analytics. As a go program doing trivial work, the load is dwarfed by the cpu/memory usage of all my seedbox related software (which has 1 user, not even every day).
> Users/TPS aren't the right metric in the first place.
This was my initial point :) Don't focus on trying to achieve some metrics, focus on making sure to build the right thing.
Re: Why is everything so scalable?
#218If you’ve ever been in a situation where you do suddenly face scale and have to rip apart a legacy monolith that was built without scale in mind, you’ll chuckle at this article. It’s extremely painful.
Legitimately asking, how? The only bottleneck should be the DB, and if you can saturate a 128-core DB, I want to see your queries and working set size. Not saying it can’t happen, but it’s rare that someone has actually maxed out MySQL or Postgres without there being some serious schema and query flaws, or just poor / absent tuning.
For e-commerce, sure. But for telecom or IoT, it doesn’t take a large company to easily overrun the limits if what Postgres can do.
Re: Why is everything so scalable?
#219>Modules cannot call each other, except through specific interfaces (for our Python monolith, we put those in a file called some_module/api.py, so other modules can do from some_module.api import some_function, SomeClass and call things that way.
This is a solution to a large chunk of what people want out of microservices. There are just two problems, both of which feel tractable to a language/runtime that really wanted to solve them:
1. If the code implementing the module API is private, it must all be colocated in one package. If it is public, then anyone can import it, breaking the module boundary. You need a visibility system that can say "this subtree of packages can cooperate with each other, but code outside the subtree can only use the top-level package."
2. If a change module A has a problem, you must roll back the entire monolith, preventing a good change in module B from reaching users. You need a way to change the deployed version of different modules independently. Short of microservices, they could be separate processes doing some kind of IPC, or you need a runtime with hot reloading (and a reasonably careful backwards compatibility story).
Re: Why is everything so scalable?
#220>Modules cannot call each other, except through specific interfaces (for our Python monolith, we put those in a file called some_module/api.py, so other modules can do from some_module.api import some_function, SomeClass and call things that way. This is a solution to a large chunk of what people want out of microservices. There are just two problems, both of which feel tractable to a language/runtime that really wan…
> 1. If the code implementing the module API is private, it must all be colocated in one package. If it is public, then anyone can import it, breaking the module boundary. You need a visibility system that can say "this subtree of packages can cooperate with each other, but code outside the subtree can only use the top-level package."
This is easily achieved in Scala with a particular use of package paths. You are allowed to make some symbols only visible under a package path.