Picture the scene — you’re a shit hot developer working as a corporate monkey for some soulless Fortune 500 evil giant. You’re sick to death of the technical debt. The shitty source control. The horrendous infrastructure. The bureaucracy.
If only I had my own startup, you’d dream. I’d have unit tests coming out my fucking eyeballs. My reactive shadow DOM components would be so slick, I could just connect them up to a super performant serverless microservices architecture and wait for the money to roll in.
Scalability issues would be a thing of the past. You’d sling 400 different AWS products together in high availability, spanning multi availability zones across multiple regions with an automatic failover to Google Cloud Platform just in case there’s another S3 meltdown. Forget the days of lobbing everything on a single box, your startup will be rocking a load balanced multiple Web server config with continuous deployment meaning you can deploy your new ninja code to customers with a simple
Running long running tasks on a Web server? Not in your startup — you provision a bunch of workers to crunch images and transcode video like a boss, with multiple queues and load balancers making sure your asynchronous jobs finish in nanoseconds. You use Amazon SNS hooked up to a web socket implementation that shows your users how fucking awesome you are by sending them updates about their cat video in real time as it transcodes into a dozen formats with automatic subtitles in ten different languages. Who gives a fuck if Meow is universal — if cats ever get their shit together and start localizing in different markets, you’ll be ready.
Of course now that you’re rocking a multi web server environment, file based sessions aren’t gonna cut it anymore. What’s better than a Redis or Memcached instance to store your session data? A motherfucking high availability Redis or Memcached cluster — that’s what! Why have a single expensive cache instance, when you can have a cluster of three instead?
For the first few months it’s plain sailing. That startup accelerator you went to that offered you six weeks of cliched advice for 10% of your company came with $10k in AWS credits, so you’re golden. You signed up some customers and they’re blown away by how fast and reliable your app is. Little do they know that it has sweet fuck all to do with your monstrous cloud infrastructure and more to do with the fact that you just have a minuscule number of customers using it right now.
One day your cofounder who looks after the money comes in with a concerned look on her face. “I thought AWS was free?” she says. You take the bill and faint. Turns out one of your six customers uploaded a cat video that went viral and your S3 data transfer ended up costing $6k last month. And your $3k a month scalable infrastructure had already bled your credits dry faster than you can say the words Amazon Web Services Simple Storage Service. The color drains from your face and you realise that you’ve just pissed away most of your angel investment, when all you needed the whole time was a $5 a month Linode or DigitalOcean box.
Reading this, you may think that I’m trying to spark a debate about AWS and similar cloud hosting versus more traditional dedicated and VPS options. In fact, I love AWS. If you’re in the growth phase, running on AWS can probably save you the cost of multiple salaries, making the extra expense worth it.
When you’re starting out, however, the key is to know when to use various AWS services and when to not. Storing data in S3 is incredibly cheap at less than 3 cents per gigabyte. But it’s the 9 cents a gigabyte data transfer that will fuck you. Making use of services like Lambda, Elastic Transcoder and SES can save you a ton of time, money and headaches when done effectively — but a badly configured auto scaling EC2 setup can also cost you a small fortune for no good reason.
More often than not, growth takes time. At the very beginning, your energy is better placed figuring out what your product needs to do to sell it to real customers. Technical debt and scalability issues are a reality for almost all successful tech companies — because they hustled to fuck when they had to in order to make some money. Your mega optimised setup is just going to bleed your bank balance unless you have real customers taking advantage of it. As an engineer, it’s hard not to want to do things the right way and build everything as it exists in your dreamy perfect view of the world. But the cold harsh reality is that more often that not, it’s likely a complete waste of time and energy.
On the plus side, you’ll be so well versed in AWS at the end of it all that you should have no problem finding a job unfucking the unholy mess and scalability nightmare the startup next door created when they started out. That is, if you can get over the dark depression caused by the simple fact that their company still exists and yours doesn’t.
This is a series of tongue in cheek posts about some of the common fuck-ups startups make during their typically short existence. It’s inspired by a combination of my own experience and monumental cockups as well as those I’ve seen in other startups along the way.