Heads in the Cloud: Why we keep our data on the ground
With all the hype about cloud-based data hosting and the variety of options available, some developers may find it surprising that we’ve never put a single data bit in a cloud server. These days our approach may seem a little anachronistic, after all, surely the cloud is essential to scaling a modern business?
There are several reasons why we've never taken the leap into the cloud:
- The estimated cost for using popular services like Amazon Web Services (AWS) is projected at 5x current running costs.
- Cloud pricing is disassociated from the underlying costs and actual performance.
- Managed services lock developers into proprietary frameworks which often makes migration impossible and hampers IP development.
A matter of cost and its costs
Let’s start from the top. Imagine for a moment that you've built up your stack gradually over the years from just a handful of servers, you’ve kept a solid scaling schedule, and you’ve monitored the traffic coming in to make sure your forecasts are on track. Yes, this is a little bit of work, but the rewards are handsome.
There is a place for cloud-hosting in many verticals, and it does bring down the barriers to entry to start and run a tech company today.
For us, we spend roughly $450,000 per year for a system structure that includes 37 servers with 560 CPU cores, 12 terabytes of RAM, and 314 terabytes of redundant magnetic storage across a 10 gigabit internal network. If we build up a hardware equivalent in AWS’ price calculator, then it comes out to a massive $2,300,000. That equates to a whopping 5X our current spend.
Additionally, we find that cloud-hosting costs are disconnected to the underlying costs of infrastructure. This can also be expected, but when these costs are in the size of millions it will distort your internal incentives. In our engineering division, we can relate performance optimizations in our software to decreased hardware requirements and thus lower costs. We’ve just completed a year-long scaling project where our IT ops, database engineers, and backend teams worked together to bring down key resource hogs whilst simultaneously increasing hardware capacity (an exercise well worth the resources and effort.)
If the link between your hardware costs and underlying resource requirements of the software is broken; your incentives are suddenly distorted. Do you make it run faster and leaner, or do you cut corners to save some money and put that towards more hardware elsewhere? Unfortunately, this trade-off is a construct of the cloud business.
The managed service conundrum
What about managed services like Redshift or BigQuery? When you build your stack into a vendor’s particular system, you end up building software to interface with those proprietary frameworks and wrappers. This draws two major concerns:
- The dependency you’re constructing is beneficial for your provider, but not so much for you. Lock-in is common among many software providers, but the issue is exacerbated when you build your own products on top of proprietary foundations as opposed to say collecting e-mails for your newsletter. Migrating an app designed to interface with a proprietary database - with its own quirks and benefits - is difficult in the first place, but a nightmare in production. What if the vendor shuts down or forces a breaking update?
- If you’re running a software company, your product is software. This is what your clients buy into, and perhaps closer to home, that’s what you’re investing in. You’re building an intellectual property, and when this IP is leaning on a single provider, so is your entire business.
Additionally, in a business where you are responsible for safeguarding and warehousing sensitive data, cloud hosting cannot provide a guarantee to where and how your data is stored. That’s not just key for our clients, but for their users and the jurisdictions that we operate within.
Keeping our feet on terra firma
Today there are many companies who don’t take an issue with the areas that are problematic to us. There is a place for cloud-hosting in many verticals and it does bring down the barriers to entry to start and run a tech company today, in fact, many of our friends, clients and colleagues’ side projects rely on the cloud.
For us, the question of cloud hosting versus on-premise hosting of our data was a no-brainer from the start. We weighed the pros and cons of costs with our growing business as well as the security and long-term viability of relying on external vendors and found our answer.
Looking into the future, we anticipate that some companies will come along and find ways to alleviate the issues I’ve outlined above, and we will then reconsider our stance. Yet, for now, the solutions don’t meet the hype, and there’s still an awful lot of heads in the cloud.
Have you considered the potential pitfalls of moving to the cloud? Let us know in the comments.