I can understand that a company wants to do away with the distraction of having to worry about running a datacentre but is using one of the major cloud services cheaper than running your own? Amazon and Microsoft seem to be making healthy profits off their cloud services. That's part of your cost.
Now it may be that even if more expensive, it is a better use of your capital (renting instead of owning so that you can invest your capital in higher return investments like hiring better people). But is it cheaper, at an equivalent level of service / redundancy?
> but is using one of the major cloud services cheaper than running your own?
At list prices? Pretty much never. Nobody sane with installations like Evernote are paying remotely close to the published prices, though.
The cloud providers rarely make sense in terms of cost for smaller businesses unless you heavily rely on batch jobs (spinning servers up/down) or other of their more advanced services. There are many valid reasons for smaller companies to consider cloud deployments, but I've yet to see one where it was the cheaper alternative.
> The cloud providers rarely make sense in terms of cost for smaller businesses unless you heavily rely on batch jobs (spinning servers up/down) or other of their more advanced services. There are many valid reasons for smaller companies to consider cloud deployments, but I've yet to see one where it was the cheaper alternative.
The cost of a server isn't just the hourly/monthly fee for running it. It's also the cost of waking up at 3am to turn it back on. If you're managing your own bare metal then you have to deal with that one yourself and I can assure you it's never cheaper than the cloud unless you value your time at $0.
Sure you can save some money by running a server yourself but if your business it as the point where that's the deciding factor in being solvent than you might as well close shop.
This is why you should run your entire application on bare metal (colo or dedicated) with failover to the cloud.
The benefit of the cloud is its elasticity. You can handle a 2000% traffic increase by spinning up VMs instantly; no need to wait a day or week or month for bare metal provisioning.
And you should do this! But once you've structured your application this way, you are already horizontally scalable. There is no reason the core of your capacity cannot be on bare metal, especially now that container orchestration platforms are bringing feature parity to cloud and bare metal. Only provision VMs for handling temporary traffic spikes.
You can generally predict traffic costs for next 1, 2, or 3 months. You can't predict traffic spikes as easily.
So why not invest in dedicated servers or collocated hardware, just enough to cover your expected traffic? Send any excess capacity, whether due to traffic spike or hardware failure, to dynamically provisioned cloud services. This way you capture the economic advantage of elastic cloud pricing while achieving full utilization of your capex investment.
I've heard this burst-to-cloud story for many years now - Paul Maritz pitched it heavily as the pillar of VMware's value/strategy when he took over there.
I've yet to ever see or hear of it properly executed in practice. I think it's a really hard thing to try and bolt on to a legacy system, and if you build a new ground-up app this way going full cloud to start is easy and cheap for a while until you're successful and then the economics are.. complex.
I think there's also the weird angle to it that the folks who have the skill to architect apps like this are very hard to come by.
Would love to be proven wrong and hear about folks who've seen burst-to-cloud work out in practice though!
> I've yet to ever see or hear of it properly executed in practice.
Isn't Netflix the poster child for this, and haven't they been for a very long time now? Not the content, which resides in their and others CDNs, but the back-end, webservers, databases and management systems are all supposed to be in the cloud now (after a long time migrating).
> I think it's a really hard thing to try and bolt on to a legacy system
There are different levels. Architecting a sharded database solution before you need to might be a bit excessive, but designing for multiple web, storage, or processing servers, etc from the start even if using bare metal is smart, and allows (relatively) easily adding capacity even if you are just colocating somewhere. At the point where you are already able to add capacity by scaling hardware, the cloud is a fairly attractive target, especially since automating the steps you take to add/remove hardware is likely trivial if you've already been doing it manually for a while, as the rough edges have likely been smoothed away somewhat already..
Netflix is not a good example for one big reason: their cost of running servers is dwarfed by their other costs, possibly by two orders of magnitude. Netflix can and does waste money on servers.
At the dollar spend for the infrastructure for most apps, the labor costs of dealing with physical servers is not worth it. Saving $1K/month on infrastructure is meaningless if it costs me $10K in labor costs.
Your numbers only work for the little guy when labor costs are discounted to zero.
Renting a dedicated server requires no labor cost of your own (if a drive fails, your provider replaces it), and is almost always cheaper than the equivalent cloud resource, especially when it comes to bandwidth.
That still leaves sysadmins that you no longer need when using the cloud. The cloud allows your developers to run free without the need for infrastructure and sys admin teams to worry about the servers.
Very little sysadmin needed if you go with a managed dedicated server provider. They pretty much take care of most of that for you. A little more expensive than a non-managed dedicated server but oftentimes still much cheaper than the cloud. Plus, you can't really completely get away from sysadmin when working with the cloud either. You actually get a lot less support than you do with a managed dedicated server provider.
Note: I heavily use AWS and managed dedicated servers.
> That still leaves sysadmins that you no longer need when using the cloud
Looking at our timesheets, managing cloud setups takes more time on average than managing bare metal server setups, and the amount of time spent handling hardware issues make up ~1%-2% of ops time spent on the bare metal setups for our systems. We "save" that on the cloud setups, but end up having spend more to account for dealing with crappy APIs to do all kinds of things we have much more direct control over instead.
You'd have to price in the cognitive load for engineering for that setup, and the recruiting costs / turnover costs for anyone that had to be exposed to the colo center. Also, the colo center! Speed & reliability are features, so you'd have to make sure to pick a colo center that had a competitive setup in terms of peering & backbone speeds, power redundancy, etc. Ideally you'd also be in more than 1 colo unless the cloud is acting as a backup datacenter, so you'd need staff in more than 1 region, lest you fall victim to something like the flooding in NYC and the colocated services that fell down during hurricane sandy.
You'd need to price in continued investment into that colocated hardware too, parts break down, cyclical improvements to hardware happen, etc. It's not simplistic at all, maybe there's money to be saved, but unless your hosting costs are really dragging down profit, I'd pinch pennies elsewhere personally.
> You'd have to price in the cognitive load for engineering for that setup, and the recruiting costs / turnover costs for anyone that had to be exposed to the colo center.
All of which tends to be more expensive if you replace the "colo center" at the end with "cloud provider".
Operating a cloud setup is by no means free of operational issues.
> so you'd need staff in more than 1 region
If you're too small to need that, you use managed hosting, pay a tiny premium over bare metal colo providers, but still far less than a cloud setup.
> It's not simplistic at all
Yes, it is, it is trivial to model, and for companies that don't have the experience, there are consultancies everywhere that will do it for you (that's part of what I do for a living - it's always the easiest jobs to get paid for, because there are hard numbers that shows them how much more they'll be saving that year than what they'll be paying me).
> but unless your hosting costs are really dragging down profit, I'd pinch pennies elsewhere personally.
I regularly deal with clients where hosting costs are measured in tens of percent of total operating costs. For a lot of internet related business, hosting is a massive drag.
Data has weight. You'd need to duplicate some portion of your data between on premise and cloud. I feel the better approach is doing 100% on cloud compute with bare metal CDN / reverse proxy
That can certainly be cost effective if bandwidth is your main cost. Bandwidth cost is the most atrociously overpriced part of the big public cloud providers, so it's certainly worth pricing out, in particular for people who already are on a cloud provider and where moving would be complex.
Exactly. The beauty of this is that building to scale to cloud as needed makes bare metal even more cost effective compared to cloud, because suddenly you can plan for far higher utilization rate for your fixed hardware than you could before.
One note: you don't even necessarily need your own colocated equipment. If you're in a location with expensive real estate and/or power it is often hard to beat dedicated rented servers for smaller installations, because you often have more flexibility in renting servers further from wherever you have staff than what would work if you colo and need to be able to reach your setup in person.
Rented managed servers still tends to beat cloud with good margins.
> The cost of a server isn't just the hourly/monthly fee for running it. It's also the cost of waking up at 3am to turn it back on. If you're managing your own bare metal then you have to deal with that one yourself and I can assure you it's never cheaper than the cloud unless you value your time at $0.
You have to deal with outages when using cloud providers too. So you design for availability in either case, and pay someone to wake up at 3am when there's an actual emergency.
We're the ones taking the calls if our customers systems goes down at 3am, and it eats into my profits if it happens because they pay us monthly fees that are structured so they're far more profitable for us if nothing goes wrong.
Guess what's most profitable for me? Bare metal setups. Despite the fact that we end up charging my customers less to manage them, because it's harder to justify high fees when the overall costs are so much lower.
> Sure you can save some money by running a server yourself but if your business it as the point where that's the deciding factor in being solvent than you might as well close shop.
I had a client last year where we cut the hosting costs including the hourly rates for operational tasks by 90% by moving them off AWS.
While they were on AWS their hosting fees made up ~30% of their burn rate. It's an extreme example, but there are a lot of companies out there for whom hosting makes up a sufficient portion of their cost that it is a matter of survival for them to cut them.
"> but is using one of the major cloud services cheaper than running your own?
At list prices? Pretty much never. "
???
It's almost always 'cheaper' for small companies to use the cloud.
It costs a lot of money to pay people to figure what hardware to buy, install servers, networking gear, maintain it, pay for bandwidth, backup etc.
But the cost becomes 'non starter' when you start to access all the nice things that cloud offers: Lambdas, S3, easy backups, etc. etc. and the fact that it 'scales on demand'.
Then of course there are the financing aspects: you don't pay for expensive servers up front, you 'lease' them effectively - which has serious working capital benefits.
All those things have considerable business value.
So sure - if you want to compare only 'server instance costs' - maybe 'buying your own instance' - specifically on a server by server basis ... maybe it's cheaper to buy a server.
But for most small businesses - the advantage of the cloud far outweighs the cost.
I'd argue that 'rolling your own infrastructure' would be risky and costly initiative that boils down to a 'cost optimization' only, and can't really be considered until a business reaches an operational degree of maturity and visibility wherein someone could really sit down and plan quite far into the future.
And even then I'm not so sure - this is why so many big and successful companies still use the cloud.
> It costs a lot of money to pay people to figure what hardware to buy, install servers, networking gear, maintain it, pay for bandwidth, backup etc.
> Then of course there are the financing aspects: you don't pay for expensive servers up front, you 'lease' them effectively - which has serious working capital benefits.
There are solutions other than cloud and going to the extreme of owning servers, switches, maintenance, bandwidth and space in a datacenter.
OVH (an example due to my familiarity) will sell you a dedicated server with 2 x E5 2650v3, 256GB of RAM, 4TB of disk and 500Mbit guaranteed bandwidth (1Gbps burst) for $269/mo. This includes most of the annoying stuff, like replacing failed components, dealing with network issues and such. The bandwidth, conveniently, is also not limited aside from the speed you're given. You can use 500Mbit/s for every second of a month if you want. That's 164TB.
The cost of a n1-highmem-32, which is the closest alternative I could find on GCE is $1030/mo, plus disk ($348/mo for 2TB), plus bandwidth (164TB is $13k from Google).
Also, the cost of owning and running your own hardware isn't necessarily expensive, particularly if you're small. When you're running a fleet of thousands, yes, you definitely want dedicated people for that. When you can fit all your infrastructure in a single rack, it's not much trouble to call up Dell and ask for a quote, install it in a local DC then forget about it. Most DCs give you "remote" or "smart" hands that can do basic maintenance like swapping a failed HDD for low or no cost.
Dedicated/colocation aren't for everyone but they're certainly not as scary as some people around here seem to think. And in terms of cost, I daresay that if you're doing anything bandwidth heavy, the cloud is near-certainly costing you insane amounts of money. You can get decent gigabit transit (~300TB/mo) these days for $400/mo while Google, Amazon etc. charge in the thousands for that kind of traffic.
There is some variance in how people interpret "cloud". Does colocating your own machine at a remote ISP constitute being in the "cloud"? What about leasing a server? What about a virtual server, but a traditional one where it's essentially no different than a single leased server? What if your multiple real and/or virtual leased servers are in the same private network at the remote location? What if there's an API available to you (even if it deploys hardware servers)? What if extra services, such as storage, can be attached?
Different people will likely consider "cloud computing" to apply at different thresholds with different features. I also consider "in the cloud" (handled remotely in the internet) to be different than "cloud computing" (handled by a cloud service), and "cloud services" to me could mean either one depending on context. I find most your statements apply truthfully to what I consider "in the cloud", that is, remote hosting. I don't think they necessarily apply when used with "cloud services" platforms. All of a sudden, all the money you save not having to deal with hardware and paying someone to configure and maintain it is either back (you need someone to deal with the craziness of each cloud services platform, and they might cost more), or offset by higher costs, if you don't have a business case that requires you be able to scale later, or add network storage, etc. Better yet, if all you need is a website, there's plenty of services that do away with all that to just provide hosting of various sizing and shapes. Is that a "cloud service"? Is that a cloud service? Probably, but in a conversation about GCE and AWS, maybe it's not actually what's being talked about.
> It costs a lot of money to pay people to figure what hardware to buy, install servers, networking gear, maintain it, pay for bandwidth, backup etc.
That's part of what I do for a living, yet my clients tends to have recovered my fees in 2-3 months from the savings they make on reduced hosting costs. Those savings include factoring in the ongoing operational costs.
50%+ savings is not unusual. We've achieved 90% in rare cases (high bandwidth requirements - bandwidth costs are extreme at the cloud providers).
> But the cost becomes 'non starter' when you start to access all the nice things that cloud offers: Lambdas, S3, easy backups, etc. etc. and the fact that it 'scales on demand'.
Nothing in a bare metal setup precludes you from using cloud functionality when/where it makes economic sense to do that rather than implement an alternative. I have plenty of hybrid setups running.
> Then of course there are the financing aspects: you don't pay for expensive servers up front, you 'lease' them effectively - which has serious working capital benefits.
That's what we do when we use colocated servers too. There is no difference there.
> So sure - if you want to compare only 'server instance costs' - maybe 'buying your own instance' - specifically on a server by server basis ... maybe it's cheaper to buy a server.
I'm not comparing only server instance costs. I'm comparing total cost of operating fully managed environments, including total staff costs including staff overheads.
> I'd argue that 'rolling your own infrastructure'
You don't need to roll your own infrastructure - you can go to managed hosting providers, or the multitude of consultancies like mine that will do it for you. Heck, I'll happily sign deals with people where I'm paid in a given percent of the saving I generate, because the savings are large and predictable.
> And even then I'm not so sure - this is why so many big and successful companies still use the cloud.
Big, successful companies don't pay the published rates. I have direct knowledge of companies with 75%+ discounts from major cloud providers. At those rates: yes, it is cost effective.
First of all it is important to understand that building/running your own cloud isn't only huge investment and high risk but also comes high cost of opportunity because every cent you spend in infrastructure you hope will be cheaper is not spend to increase the real value of your product. Not making this investment until your organisation and IT are "cloud-ready" decreases this risk. I have seen companies invest more than double the cost of a cloud provider to build their own cloud without having access to the features that a public cloud provider provides.
For me the questions come down to the proportion of resources to revenue and how "cloud-ready" you are.
Hm, but how much of those features they don't have access to would actually be used? After a few decades in the trenches, I've come to (mostly, kind of) accept that on average, most companies do not push the leading edge, and settle for relatively baseline feature sets of all of the software they use. As long as a deployment hits those feature points, they don't aggressively push for learning, testing, deploying and using new features.
This is of interest to me because no matter how I slice it, when analyzed from this "baseline feature" perspective, cloud solutions of conventional software that require deploying upon conventional platforms are expensive, and I figure I must be missing the picture. I'm much more excited about cloud solutions like AWS Lambda that de novo solutions are built around, as those do seem to have more promise delivering the much-talked-about 2-10X cost improvements compared to conventional software, but still at a high cost of vendor lock-in due to lack of cloud API standards adoption by vendors.
There were a lot of basic features missing. After 2 years of initial Openstack deployment there was no DNSaaS available and the loadbalancer solution was very unstable. This was partly caused by the organisation because nobody knew how to build a cloud system and first first few iterations of this private cloud were build like traditional bare metal infrastructure. If the investment for the private cloud had been used to adapt a public cloud provider for all non critical applications the benefit of the organisation would be greater.
There are tools like Kubernetes / Mesos that can help abstract the infrastructure layer so you can move between different providers. I have seen kubernetes federations setups between kubernetes clusters on AWS and kubernetes clusters that were hosted inhouse.
Building/running your "own" cloud doesn't require owning bare metal servers. You can rent and lease for a fraction of the price of renting cloud instances. Once you start paying up front of reserved instances, the capital invested tends to start stacking against you.
You certainly can burn through ridiculous amount of money if you insist on purchasing servers outright and pick expensiv brands.
Conversely, the "private cloud" deployment I run are mostly rented servers with month-to-month contracts. No upfront infrastructure spend - we grow them a server at a time. We also run some bare metal setups and they're generally cost-competitive with rented servers, but there it certainly depends on the size of the installation.
I recommend OVH.com. They provide bare metal servers in a semi-automated way and have locations in US, Canada and France.
For the type of application that I run, where our demand is not very elastic, I find it very cost-effective and more flexible (as long as you're comfortable with administrating KVM and ZFS). I also like that with ZFS, I can easily sync snapshots between providers at the filesystem-level.
Hetzner and OVH are my go-to providers if I don't have specific needs that precludes it (in Hetzners case, geography - I don't think they have data centres outside of Germany).
I don't tend to care that much what control I have over the network as most of the systems I deploy are set up to allow us to tie in compute or storage resources "anywhere", which means we put encrypted overlay networks in place for all inter-server traffic no matter what to get a consistent fabric to build on top of. It costs a bit of CPU resource, but I've yet to run into anywhere where's it's been an issue.
It is cheaper for my company. We have very high seasonal demand on one of our websites. Our busy months need 10 times as many servers as the low months. With amazon we pay for the servers only when we use them. When we did it ourselves the servers spent most of the year idle, but using electricity and maintenance but earning us nothing just so we could handle out peak demand. Now we pay nothing for them when we are not using them.
December is one of our low months: those servers we were hitting hard in September are now helping some online store keep up with the Christmas rush. I believe this is factored into the price we pay.
We do a lot of our own work in house. In general we have enough IT staff that it is more cost effective to keep our own servers in house, but that is for loads where the variation is relatively small.
Reminds me of the "buying locally grown food" argument that's premised on the assumption that buying locally grown food requires less carbon emissions because the food doesn't have to be transported from far away. HOWEVER that argument ignores that even after factoring in transportation, those larger industrial farms are farm more efficient than your local farm. So even with transportation the industrially sourced food might be more carbon efficient.
Only if they are so efficient that after they get their cut, it's still more efficient than rolling your own.
Because these cloud services have inherent lock-in, they don't have enough incentive to keep margins low. Indeed, Amazon's margins are extremely high after factoring in bandwidth costs.
Agree, but that's my question. Does the savings achieved by these cloud providers more than offset their margin, or is the motivation to move to the cloud solely a return on capital / removing a distraction?
It seems that their motivation was enabling the use the "machine learning" as they say or the "Big Data Analytics" as the user threeseed recognized in his post here.
25:30 - Rationale, background
53:00 - Discussion of financial models, move from capex to opex
Keep in mind that the volume of data in terms of video assets for broadcast quality linear playout as well as numerous continuous high bitrate outgoing video streams is very large.
As they note in the video, their financial modelling showed that it made financial sense to move to AWS if it was "all-in", allowing them to fully close down a number of large data centres.
If all you are using Amazon/Microsoft for is EC2 style hosting then yes it's expensive.
But if you are interested in Big Data Analytics as well (as Evernote would be) then it is a bargain. It is very expensive to run your own managed Hadoop cluster, build the data ingestion and scheduling components, event store, NoSQL store, machine/deep learning pipelines not to mention AI technologies and have them all integrated and cohesively packaged.
As one author once wrote "Whenever a company says 'In order to serve you better', you can be pretty sure they're about to do something that will make your life more miserable." I like the point of xkcd 1150 too. But Evernote actually does take money from their note taking customers.
Except, I get to share one person across several systems.
Simplified example:
$100k/year for a Linux engineer
That same person can upgrade 10 Linux servers (on-premise company) or 1000 linux servers (cloud provider). It may take the 1000 linux servers slightly longer, but the cost to service is still significantly lower.
There's also a lot less variability in skills of the Linux engineer.
I don't think people quite understand that cloud computing is a consolidation and elimination of backend computing jobs, not the increase. The only reason there is an increase in the market, is because the overall pie is growing.
You know Facebook, Apple, Microsoft, Google, etc and other major companies use CDN's like Akamai to deliver their content to users right?
Building a few data centers may not be not be hard and may be cheaper, what's hard is serving content fast and as close to your users as possible in the world. For that how many data centers could you really build?!
> is using one of the major cloud services cheaper
> than running your own?
Depends on the size and to some extent the distribution. Above a certain size (and this varies based on the mix of memory, storage, and CPU cycles) it is cheaper to run your own stuff in a space leased from a data center. However that size generally has to be achieved at every data center you want to run in. For example, if your function was that it saves money above size 10, And you need 7 units in the US and 7 units in Europe, it is probably not cost effective to run your own even though your up to 14 units of capacity, but if you're running 15(US) and 12(EU).
That said, you still have to have the the operational expertise to run it and with that expertise will come an understanding of the actual costs. For example, at Blekko we were running 1500 machines in a data center and had just over 12,000 hard drives. Those drives are going to fail over time so you need build process around continually renewing the drives. You assume that you'll be able to get some replaced under warranty but you should also simply depreciate the cost of drives over 3 years. So you spend $110 on a drive, you depreciate it at cents per day. That is an "expense" you incur as you buy replacement drives. So your storage is "costing" you $36,000/month ($0.10 * 12,000 drives * 30 days). At the time it was the 2TB generation and our system used simple triple replication for data protection so it represented 8PB of data protected storage, of which, at any given time we were utilizing roughly 5PB. S3 from Amazon [1] is .021/GB per month so 5 petabytes (just what we were using) would be $105,000 per month (so roughly triple the cost). And there is the network 'in/out' costs which raise the prices further and you don't pay for your own storage. Most of our storage management costs (detecting bad drives, reformatting, scheduling for RMA) was done automatically but it did take an data center engineer one day each weak to work through the list of drives that had been determined to be bad, swap in replacements from the 'incoming' drive box, and put the outgoing into the 'rma' box (40 drives in the box) and once the outgoing box was full, print out the list of serial numbers and generate a standardized RMA to Western Digital and to then put the shipping label on the box. So in addition to the depreciation cost you add 20% of the cost of a date center engineer who is doing the mechanical work of moving dead drives out.
So you can cost it out this way for your own infrastructure and figure out which is cheaper, and for a lot of people it will be cheaper to run it in the cloud because you really don't need multiple petabytes of data or thousands of cores on line or terabytes of RAM. And some people build their systems in efficiently so that they are spending way more on people keeping them running than they might if they had designed them differently. glindahl had honed a set of scripts and tweaked Nagios bits that made running lots of machines fairly efficient but not everyone has someone like that on staff.
But the place where it is a real win, and I think this was the economic story that got Evernote to move, is that when you downsize your infrastructure needs it is trivial when you are in the cloud, and it is non-trivial when they are your own assets. Data center leases are generally multi-year and they are loath to let you sublet space or reduce space.
Since Evernote has been shrinking this makes a lot of sense for them, when their user base shrinks their costs shrink with it. And that is the "killer app" for cloud based infrastructure.
Perhaps phrase the question differently, to challenge the premise it is 'cheaper':
"Could they set up a datacentre as an independent subsidiary that they were client to, but that was run on a commercial basis for other customers too?" i.e. commercially viable.
If the answer is "Yes" as it was for Amazon years ago, then it seems like a no-brainer - do it yourself. Otherwise, such decisions calls for greater scrutiny. For example, should HR services be run internally, or outsourced. Outsourcing some functions don't work even they're more expensive on first analysis, like the network effects internal HR can have, or the answer may be "No" for some services, Payroll a common example.
Arguably their core business is synchronized notes and well-done applications. The storage, hosting, networking, electricity etc are all implementation details.
I think economy of scale will kick in at some point allowing the cloud providers to profit while being a cheaper service than what the clients could have done themselves.
Now it may be that even if more expensive, it is a better use of your capital (renting instead of owning so that you can invest your capital in higher return investments like hiring better people). But is it cheaper, at an equivalent level of service / redundancy?