It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite. I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them.
Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations.
> It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite.
Depends. No one at a unicorn says that, but I've seen plenty of startups that.
The unicorn is the outlier, not the rule.
> I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them.
Were they still in business at the end of all this? Because it turned out you made a bet, and it came through. The odds are against this, though.
> Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations.
A million in what time period, and what are the usage patterns? Because from what I've seen, as long as the backend isn't in Python, Ruby, PHP or similar, a single hosted server easily vertically scaled to handle more than 2m million users, because it a) didn't need to handle 2m concurrent connections, and b) usage patterns were infrequent enough (users interacted only every few minutes at most).
I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare.
You should make architectural choices that CAN be scaled within reason, on demand and ideally incrementally. That doesn’t mean you need to build your app on Kubernetes and automate welcome emails, surveys, metrics, A/B testing etc. But you probably shouldn’t build on top of fundamentally non-scalable systems either.
This is provided you’re in an environment that can reasonably scale to 1M users or whatever, which isn’t true for all domains. Say B2B where that last B is only 10000 people world wide.
It’s difficult to explain to people what you said without the experience of living in the failures of early optimization. K8s from day one, a-b testing, programmatic quality control without any paying clients on the product, scrum master and a PM and a product owner for 5 devs! Whole thing feel like a Ponzi scheme to keep overseas staff employed, perpetrated by the overseas development shop.
Unless you built something absolutely atrocious, scaling it vs getting it ‘right’ or ‘right enough’, is trivial. You couldn’t sign up to Facebook if you weren’t a college student.
Chatgpt overloads daily so what? When your app becomes necessary to enough people, bring in your k8s evangelists and shove into x cloud provider. But by god it doesn’t take 30 people to write a marketable mvp.
Maybe I had the fortunate luck that we never had issues of finding market fit. We also had lots of investment outside of software dev. Fintech for example requires significant investment in compliance(eg: kyc).
Chatgpt doesn’t have competitors. Customers can’t go elsewhere. Twitter had the same protection when they launched, there wasn’t a short form social network so they could have full day outages. Friendster would be the opposite, when they closed signups, customers just went to MySpace.
Scale goes beyond the ability to support traffic. It also means efficiently handle data/traffic. Heap is a good example, great product but they haven’t figured out to provide that level of analytics without significant costs which are passed on to the customer.
Kunerbetes works just fine on a single node. And it provides a lot of good things over docker run scripts or docker-compose. Kubernetes basically is an OS for OCI images. Even if you don't need orchestration, it still provides great experience. And when you would need orchestration, you will grow organically.
Right now I'm using cluster of 2 nodes (master, worker). No reliability, but convenience is good and we have very simple path to more nodes when we would need it.
I strongly agree. Having Docker images of your application is very convenient gor deployment and fairly easy to set up for anyone who has done so before. Then once you have these images anyway, hosting in (managed) k8s in the cloud is a breeze.
I'm not sure why you are getting downvoted. It would be great to hear of some of the bad experiences of those that disagree. Were they running their own cluster instead of a managed one? Or doing k8s with a team where nobody had any experience? Or run into some helm-chart spaghetti from hell?
The claim was that the unnecessary complexity (of which Kubernetes was just one) from day 1 consumes valuable time that could be spent on making the product better.
Kubernetes brings very little unnecessary complexity and does not consume valuable time (if there's at least one person in the team who knows it well enough).
Kubernetes might start consume valuable time if you would start to bring niceties. Like GitOps, CI, and so on. Those things are good but not necessarily justify time spent from the start. So you can start with simple deployment yaml which you can write with 10 minutes and apply it manually whenever you need to update it.
Kubernetes almost out of the box brings to you:
ingress. You don't need to set up your own nginx reverse router. This task alone could consume days of setting up and maintaining. I work with organization which spends 2-3 hours to update their nginx if they need new route. It must be done in off-hours because they break it every single time they touch it and then they need to fix it. Kubernetes ingress is a breeze of fresh air after this nightmare.
cert-manager. Again, I work with organization which failed at setting up certbot. Their certs break all the time. cert-manager just works.
zero-downtime rollout restart. This is absolutely nice thing which works from the box and hard to achieve manually.
kubernetes-dashboard. There're other dashboards as well. I think that lens is very popular although I didn't use it. It allows for people who know very little about kubernetes to interact with it productively. For example in my team we have developers who use kube-dashboard to view logs, to exec into pod and check things, to update deployment, change envs. They just push buttons in GUI, they have no idea about any yamls or kubectl. And it works.
And those things in my experience so far do not bring any unnecessary complexities. Quite the opposite. They solve lots of inevitable complexities for very little cost.
In you're case, you clearly already had Product-Market Fit. Most startups do not. It's far more valuable to build quick than it is to build for scale until you know PMF.
Post product market fit scalability is critical. But a lot of effort is spent on things that will never get traction in startup land. Before you get traction the times at bat is the more important metric.
Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations.