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:

  1. 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?
  2. 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.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

29 Nov 2014, 12:33 a.m.

Interesting perspective, it's always good to hear why organizations are NOT moving to cloud. I can't speak to all aspects of your argument and certainly don't advocate for or against cloud, but I think your perspective on cloud pricing is not accurate. Sure, you have 37 servers with 560 CPU cores, 12 terabytes of RAM, and 314 terabytes of redundant magnetic storage across a 10 gigabit internal network. But when moving to cloud it shouldn't be apples to apples comparison. What is your utilization per application, are you at 100% utilization on all 37 of your servers, what is your storage iOPs, what is the network utilization per server. The company I work for has an analytic application that analyzes full IT infrastructures before moving to cloud for organization and we NEVER find an organization that needs to buy exactly what they have on-premise in the cloud. We actually find that most organizations can save more than 66% on cloud cost by simply understanding the usage profile of each server and application in their environment. Price if of course just one variable to consider when looking at Cloud, but I think if you looked at the usage of your infrastructure and then bought based on that vs. buying what you have (inventory based purchasing), you might get a different view on price. I am sure the other areas you addressed still would be issues, but your pricing could be optimized no matter what cloud provider you were considering. Also, NEVER buy reserved instances when first making the move to cloud. From our experience, you should run your workloads in the cloud provider for several months before you consider reserved instances. Just some food for thought .


4 Dec 2014, 11:06 a.m.

More than 66% saved on Cloud storage? That's a bit of a nebulous figure. In any event the article describes a saving of 400% ( "5X our current spend") by *not* using the Cloud. Can your company match that? Anyway, as you accept, cost is just one factor. The major factor for us is that if you are using a US Cloud company then be prepared to share your date with the US Government.