Using the cloud, your own servers, or both should be a deliberate decision based on cost and your real business needs. Not thinking about this seriously is doing yourself a disservice.
> OVH actually supports running the Proxmox* virtualization distro on their servers
But often times those cost-benefit analysis don't take into account how quickly you can improve and work on your infrastructure. The performance or cost improvements need to be a lot to slow down your team even a bit.
Especially for startups this can hit them very hard.
I think engineering for 'The Cloud' can be just as time consuming if not more so for start-ups. For Amazon at least you have to engineer for failure. With a dedicated server configuration you still do need to engineer for that, but you aren't worrying about if depending on the solution providers block storage is going to take certain aspects of your architecture offline when it goes down (yet again), or if the portal won't allow you to bring up/down new instances during a very critical period of time, etc.
Generally speaking, most sysadmins at small places do a horrible job engineering for failure. Or, worse, they don't have professional SA's, just devs who know enough to be dangerous.
So while you don't run into a US-East EBS failure every now and again that affects millions of servers, you are subject to random unforseen failures because somebody didn't do X correctly. (Where X could include: disk configuration, HA configuration, DR plan, backup/restore plan, os management, firewall management, etc)
There's no one right answer here. I've rolled specific hardware solutions managed by a single team for certain applications, and everything was fine. I've been stuck working within the bounds of a managed services provider, and things worked too. Cloud is just another model.
EC2 lets you roll a globally distributed solution with good tooling for low cost.
This is the Crux. There are other options available, but going cloud makes it very easy to roll out something big without the necessity to have experts in all the lower level parts of your infrastructure. It lets you focus and the price for that is absolutely reasonable
1. If you're using tons of servers, you might benefit from hosting your own hardware on a large scale. But even then you can probably negotiate with the cloud service for a better price (like Netflix did). If you're a big customer and you think you should move off the cloud, the provider can beat your expected costs and still make a profit. Your team doesn't have thousands of years of combined hardware experience, and you're not buying hardware at a better price than Amazon got.
2) You don't want The NSA snooping on your company's data. This is a moot point because they will obtain the data anyway, with a gag order, if they really need to.
Most small companies aren't going to benefit from the elasticity that the cloud provides. The administrative overhead will be similar on each except in the case of the cloud you need to worry about the persistence of data either via EBS, replication or having an acceptable loss level.
The question is whether or not you're paying up-front for hardware, and managing it locally somewhere. If you lease a $10/month VPS, you're using cloud services.
The cloud is not the definitive answer for all teams, but leaving all the power cloud computing gives for a little cheaper hosting at the beginning of a project seems wrong to me.
This is a critical point. In every recent hardware project where we've deployed big, beefy servers to colocation, the first step was deciding on the virtualization platform and the automation tools to manage it, as the flexibility, scaling, and reliability concerns are principal now. I have to hope that no one thinks of in terms of a physical box that is the database server, etc, any more.
And worth noting that on a couple of medium-range Dell servers you literally can spin up and down hundreds of virtual machines, obviously depending upon size and scale.
Even on a recent low end OVH server I requisitioned, the first thing I did was configure libvirt. The base image becomes almost irrelevant.
Given the EC2 Small instance type of 1.7GB/VM that would be over 600 VM's you could run on that kind of stack. Pricing for a half cabinet with power and bandwidth (you can find places with un-metered gigabit connectivity) will run you no more than about $2500/month (Much less if you are good at negotiating). So you have an outlay of around $40k for total hardware costs and recurring monthly of $2500/month. Amortizing this over expected lifespan of three years for the servers (worst case scenario), you can estimate per month costs somewhere in the range of $3600/month.
With EC2 to reach parity with those 600 'Small' instances would be an initial deposit of $57,600 (for three year term) and a recurring monthly of $11,826 for a total 'recurring' of $13,426/month.
Now, I should point out that these are obviously not apples-to-apples if you have: Huge CPU requirements on those 600 instances, or need lots of disk. Your up-front hardware costs increase (perhaps substantially) once those come into play. More I'm just trying to compare a bare instance scenario. As per one of my comments elsewhere in the thread really it all comes down to workloads and doing a real business analysis.
This is because no virtualization tech likes handling large nodes (FCAL, 48 cores, 256Gb RAM). We lost 20% throughput by sticking our SQL Server primary and replicas on ESX versus physical when running our trials. That's a big hit when you run 150million queries a day.