Engineering
I’m excited to be a panelist at Digital Ocean’s TIDE SF: The Power Of Simplicity next week.1 Preparing for the panel gave me an opportunity to organize my thoughts on how we scaled HubTran. In particular, I’m going to focus on server scaling today. I’ll write more about scaling other parts of the organization in the future.
Day 1
One of the biggest mistakes I see startups make is worrying about scaling too early. Sure, there are a small number of domains where you might need to worry about scale from the start, but that’s probably not you. At this point, the most important task is to validate the idea of your business. It typically takes longer than you think to get your first customers, so worrying about scale is misguided. You are also targeting early adopters. These folks are more willing to deal with an incomplete product. Your product may be more enjoyable to use if it’s faster, but if you’re providing enough value, people will wait.
Beyond Early Adopters
So you’ve got a market! You’re starting to sign up new customers. Now’s the time to build that autoscaling cluster with Kubernetes, right? Probably not. At this point, you don’t have a ton of customers. You’re more likely to be able to just move to a bigger server and worrying about scaling later. This is the time where you want to focus on building a full featured and valuable product.
Time For More Servers
Okay, so now you’ve outgrown your single server. Autoscale it is! Or, not. You’ve outgrown your single server and moved to a cluster, but do you really need to autoscale? Can you just figure out the approximate required number of servers and then double it? From my experience, until you get to 100 servers, your server cost is significantly lower than the cost of an engineer. It’s far cheaper to just have too many servers than to deal with the time and complexity of more advanced solutions.
100+ Servers
So when is the time to start looking at complex automation? We chose to wait until the savings from dynamic sizing would pay for the engineering cost to build it. At our current size, we can afford to have a full time person working on auto scaling. As we grow, that advantage goes straight to the bottom line.
In Summary
Obviously, this isn’t scientific, but it’s worked for us. We’re very happy with the tradeoffs we made. We believe that waiting to worry about scaling has enabled us to feature more of our energy on building the features that attract customers. Just as importantly, we haven’t had to drag the baggage of a complex server architecture with us as we learned more about our product. If you’re in San Francisco, I hope to see you next week!
-
Are you in San Francisco? You should come by! It’s free! ↩