5 ms·
A friend of mine recently launched a side-project that does heavy processing of audio. He decided to invest ~2-5 hours properly setting up auto-scaling, a job q
by herval 7y ago
A friend of mine recently launched a side-project that does heavy processing of audio. He decided to invest ~2-5 hours properly setting up auto-scaling, a job queue, etc, before releasing v1.
Fast-forward two days later, his service and a competitor were both featured on Product Hunt. He's now making a profit on the service, as he managed to scale it up very fast, while the competitor buckled and completely lost momentum.
If you're talking about spending _a long time_ preparing a perfect infra, then your argument makes sense. Spending a few hours? It's both a great learning exercise and can literally save your project, so why not?
- thiagocsf 7y agoBecause you don’t have to. The few hours you used on infrastructure can be better used fixing a bug, polishing/adding a feature or even giving yourself a break so you can be better focused the next day. A Heroku-like platform will literally do the scaling for you. The non-financial cost is that you need to develop your application in-line with their framework/platform. If you make this decision at the start, this cost in practically nil.
- meesterdude 7y agoThis is how I see it as well. Start making cookies with the kitchen oven before planning to start a bakery. Heroku lets you do both.
- hartator 7y agoAuto-scaling doesn’t take 3-5 hours to set up. Or come work for us!
- pojntfx 7y agoWith a Kubernetes autoscaler, this takes you ~20 Minutes to setup pod autoscaling. If you run your k8s on say GKE, setting up node autoscaling is another 5 Minutes.
- nrb 7y agoI totally agree with you, once you've factored in the dozens of hours gaining knowledge of k8s and hundreds+ of hours of experience dealing with it in production. You can get by with far less, but it's going to be pretty stressful when things go sideways in prod without knowing exactly why.
- pm90 7y agoThis is sort of a strange argument. If your argument is that we need to factor in prior knowledge, naturally I will ask: how MUCH prior knowledge? * do i need to factor in experience with VMs? * do i need to factor in OS and networking theory learnt in college? * do i need to factor in high school algebra? * do i need to factor in learning the english language? Of course you need to factor in learning k8s. Before, it was learning VM's+ {ansible, chef, salt}, before that it was prob something else.
- koffiezet 7y agoIn theory maybe. In practice - the application running in the pod has to be aware of this, and the most intensive part are rarely the bottleneck. Most of the time this is an architecture issue, not a resource issue. This takes time and experience, and overhauling a platform to remove a bottleneck is usually very painful if you have a bit more complex setup.
- collyw 7y agoWe put everything in Kubernetes to scale. Now large uploads and downloads fail more often than before.
- mkarnicki 7y agoAre you saying k8s is to blame for large file upload/download failures? Maybe your infra needs a tweak?
- herval 7y agoHe used GCP, setup a pubsub topic and a cloud function. It took less than an hour to setup, the rest of the time was rewriting a portion of the code to write to the queue, etc. There’s other ways in other platforms as well (eg if you’re using Kubernetes)
- fogetti 7y ago> completely lost momentum I am sorry but you are really talking about 2 days of time interval and projecting predictions based on that? Unbelievable... So what's to stop the competitors to do the same thing that your friend did to invest 2-5 hours and catch up on the third day??? I wish I was good at ascii art, then I would draw a nice facepalm here.
- henrikschroder 7y ago> So what's to stop the competitors to do the same thing that your friend did to invest 2-5 hours and catch up on the third day??? Pride, a refusal to accept vendor lock-in, misaligned incentives, sunk cost fallacy, etc, etc.
- yardstick 7y agoMy take: depending on the nature of the business, and how the publicity was done, they may only have had one shot at gaining the customers. In 2-3 days time you might have fixed things, but by then the prospects moved on to the site that worked. I’m not convinced that you need to superscale your infrastructure first. I think it’s normally a waste of time and money. But for the example listed this is a likely benefit.
- herval 7y agoThe competitor didn’t know what he was doing, pretty much. He hacked an MVP together with Rails in Heroku, then when people flooded in, he couldn’t scale up and the site kept crashing. By the end of day two, there were articles and publicity about my friend’s site, and then it became a flywheel. He eventually made it work, of course, but the botched launch gave my friend a HUGE advantage (and paying users). I bet he’s paying a ton of money and still trying to scale on Heroku (I made a considerable amount of money as a consultant fixing cases like that too) Welcome to the web?
- makstaks 7y agoNot knowing much about your friend's service, it sounds like the value of his product is "heavy processing". Therefore, I also would have included scalability as part of a v1 deliverable and wouldn't consider it as an optimization task. Great that your friend identified that.
- AlchemistCamp 7y ago> Fast-forward two days later, his service and a competitor were both featured on Product Hunt. He's now making a profit on the service, as he managed to scale it up very fast, while the competitor buckled and completely lost momentum. That's an incredible story! Could you please link to the two products on PH?