Hacker News new | past | comments | ask | show | jobs | submit login

“Scalability” seems to be perceived to be the most important thing for startups. It’s dream-driven development.





Also "scalability" is multi dimensional. I've seen, in the same company, infinite scalability in one downstream system whereas the upstream system it depended on was manually feed by fragile human-driven processes because there was not time to fix it. And at the same type the daily ops were "brain frying" because the processes were not automated and not streamlined and the documentation was ambiguous.

So, you had technical scalability in one system but if the customer base grew quickly every other bottleneck would be revealed.

There is more to business operations than technology, it seems.


We often forget that scalability doesn't mean just scaling up. It also means scaling down to avoid wasting money on overprovisioned infrastructure when you don't need it.

All businesses need to think about scalability, regardless of their size. If you're a startup, you likely want to be frugal with your infra costs, while still having the ability to quickly scale up when you need it. Those "simple" approaches everyone loves to suggest have no way of doing this.


A single Hetzner bare metal server is going to be a few times cheaper than all of these scalability gimmicks while offering a significant productivity.

A single server of any kind is not a proper production environment, unless you're building a toy or demo service. You want at least one application and one database server, since they have different operational requirements. You might even want to have a separate web server, so that you can isolate your internal network from the internet. This is all web hosting 101, and has been standard practice for several decades.

But wait, don't you want some form of redundancy/failover in case one of these servers catches fire? Alright, let's double this then. Make sure to setup your load balancer as well, which should probably run on a separate server.

But wait, don't you also want some kind of staging environment, so that you can certify your releases before deploying them to production? Alright, let's double this again.

And so on, and so on... Eventually you'll end up rebuilding the same features of those complex gimmicky tools, but do a much worse job at it, and you'll also have to maintain your custom tooling mess.

Of course, if your company fails after a few months, none of this is worth considering. But if you plan to exist for the next few years, I would argue that your productivity would be considerably higher if you had just chosen that gimmicky tool from the start, or a very short time after it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: