The pros and cons of cloud hosting
devblog.supportbee.com
devblog.supportbee.com
Finally, hosting on Amazon is not only about EC2, it is about the whole ecosystem. You can take advantage of many other services, such as their offerings for MySQL (RDS), memcached (elastic cache), CDN (CloudFront), monitoring (CloudWatch), etc.. Like any other technologies, they have their shortcomings, but can save a significant amount of time and effort vs. doing it yourself and they are way ahead of anybody else in the space (specially traditional hosting companies)
As a side note, EC2 costs can be significantly reduced with reserved instances if you are willing to commit to 1 or 3 year terms.
I think that very high level PAAS providers like Heroku, DotCloud, and CloudFoundry are the future, at least for what I would like to do. If I am working for customers, spending effort on plain AWS or hosted servers is OK if that is what they want, but for my own projects I prefer to spend a little more money and save a lot of my own time.
Adding to that, AWS does have its own PaaS: Elastic Beanstalk. We've been using it for several months now without a single hiccup. It's Java only, but it just works: load-balancing out-of-the-box, auto-scales beautifully and replaces dead instances in a couple of minutes. You can easily launch new environments for testing new features and app updates are a breeze. And you're still close to all the AWS services like S3 and CloudFront which adds a lot of value to the package.
This sounds almost like a commercial but, yes, being used to manage our own servers, this was one of the greatest moves we did. We still have a server hosted at Hetzner (mentioned by the OP), but have moved pretty much everything to the cloud. It's good to know that updating MongoDB is now just a matter of sending an e-mail to the guys at MongoHQ (which also runs on AWS) and they do it in a few seconds.
It may not work the same for everyone but from our experience it does pay off even if we're burning a few more dollars every month, as we're not spending long unexpected hours on server management anymore. And for a small team trying to focus on product development, that's gold!
VMware? Assuming you are limited to on-premise options, isn't this kind of flexibility addressed with in-house virtualized instances? At a previous employer (who was too paranoid about cloud) I could easily pull a snapshot of prod into a test/dev environment with a few clicks and coffee-break worth of lagtime (likely possible with command line too), then use my deployment process to push changed code/metadata changes back out to prod if need be.
The only downside to this approach is you need to have IT ops that's up to snuff on virtualization (not guaranteed)... with cloud you cut this out, and your devops guy can manage everything.
For anything requiring real IO performance or tons of memory, stick with your own hardware.
Prgmr.com is no longer offering co-location ... the margin on co-location is such that I can't justify setting aside time and space that could otherwise be used for my xen VPS hosting business at this time. (note what this implies about the relitive pricing of these two commodities; quite often, owning your own hardware and co-locating it saves you money over renting virtual servers, especially once you start approaching 16 or 32GiB ram)
That said, I rent a VPS from him because I just need a small, always-on server in the cloud that I don't have to administer.
1) Run on dedicated hardware.
2) Run on EC2, or another "Infrastructure as a Service" provider.
3) Run on Heroku, or another "Platform as a Service" provider.
For smaller companies, it really comes down to a few questions: Who's worrying about your database backups? Who handles security patches? What happens when a critical machine fails on Christmas week?
Many smaller companies will be happiest with option (3), because somebody else worries about backups, security, and machine failure for you. Sure, it's expensive. But it's a lot nicer than calling your senior programmer back from vacation because of a catastrophic RAID failure.
Option (1) certainly looks cheaper on paper. But many small companies are skimping on something critical, and they'll get burnt within the next 5 years.
The breadth of options becoming available is fantastic; it's not that long ago that hosting options were:
* sharing a single physical machine with a group of unknown other customers
* renting one or more single physical machines with preselected hardware/OS
* Purchasing your own hardware and co-locating it in a data center
* Building a data center
I think, if I were building the infrastructure for a company today (which I am helping with, for a lot of companies), I'd definitely eat the additional cost (can be offset quite a bit by reserved instances) and idiosyncrasies (instance degradation, unexpected performance characteristics) of Amazon.
I spent years toiling over hardware quirks, flakey SCSI adapters, power outages, failing or aging machines. If you rent boxes, you're relying on SLAs (if you can get them) and sometimes insane costs for an onsite engineer to fix something you broke (I mucked up a firewall config once on leased dedicated hardware. Don't do that. Ouch.)
There are similar outages with cloud providers, but depending on which rung of the abstraction you're on, (IaaS, PaaS, etc) you might be in a much better position to redeploy your infrastructure elsewhere if it's a real disaster.
The bigger your product/service gets, the more expensive your downtime is (and the more you're spending on engineers to make sure it doesn't go down. Oh, and your hardware has quirks, and your engineers know them - if they leave, they take that knowledge with them).
Of course, there are situations where you'll want to minimize financial outlay, run something that's not a "web app", don't mind getting your hands dirty, willing to risk hardware failures, etc. Hopefully PaaS providers will continue to bridge the gap for most people.
Of course, you can also build and colo your own servers with IPMI--pretty much every brand supports it.
Once you're VAT registered, you can claim back VAT on allowable purchases (eg servers, hardware, software, etc). You will have to charge VAT on services you provide, but seeing as most businesses you sell to are also VAT registered, it makes little difference to them.
In the UK, you have to register if your turnover is more than £73,000, and the benefits for registering even if you're under that threshold are compelling (except if you almost exclusively provide services to non-registered entities)
The only thing I've ever found close to hetzner.de in the US with good customer feedback is (though there servers aren't that close): http://joesdatacenter.com/Dedicated_Servers.html
1. The default Debian OS load I specified, had their custom /etc/apt/sources.list. So when I spec'ed Debian 5 (for compatiblity with specific stuff I had to run), then ran "apt-get update && apt-get upgrade" -- it automatically upgraded everything to Debian 6. Not cool.
2. They buy bandwidth from cheaper providers like He.net, Cogent, and I think some other provider. They may not be as low-latency and as well-connected as you like.
I have servers in the NorthEast on Level3 - bandwidth between JoesDC and this location was unusable (under 1Mbps). However, I did open a ticket and gave them traceroutes, pings, etc. and a few days later it was fixed, I can now get over 30Mbps between the 2 locations.
But, you might never know what response times are for your clients, as you can't measure speed from their end.
excellent point about the $150 fee.
the ram and disk seem very cheap. I haven't seen raid-1 3TB and 16Gb ram in the states for anything less than $150+ a month.
They may be a good DR site.
Another perk is that incoming bandwidth is not tracked.
The actual cost for a planned _Reserved Instance_ on EC2 is much lower and is a much more realistic scenario for hosting : it cost about 27$/month for a 3 years reserved small instance (425$/36 months + 14.64$), not 60$/month.
No one knowing it will use an instance 100% time should opt for On-Demand instance, because yeah, it costs a lot.
https://aws.amazon.com/ec2/#pricing http://calculator.s3.amazonaws.com/calc5.html
And even not taking in account the setup fee and the commitment, at 27$/month, you get a lot of power for your buck comparing to the cheapest dedicated server available at maybe something like 60$/month.
Cheapest dedicated box I could quickly find is at 59$/m, and even with a 2 years commitment you get "only" a 25% reduction which put you price at ~45$/m:
I agree that PaaS is a different story all together. It frees you up from doing most tasks. However a vanilla EC2 instance or dedicated are almost the same in that respect but quite different pricing and performance wise.
At least in Europe Amazon has only one datacenter, quite at the outskirts in Ireland. We could save some 20% in load time by moving to Germany, where our customers are!
Really, it is a rabbit hole that can lead to thousands of dollars each month very quickly. EC2 becomes efficient when talking about hundreds of thousands of customers if not more.
You can end up with an impressively robust system but at a large of upfront cost: for startups probably not worth the ROI.
I definitely agree. That said, I think people seem to forget something.
Amazon says: "your instance may go down and if it does we may just terminate it, reclaiming your ephemeral disk. All data not on EBS will be lost."
Every other host (at least implicitly) says: "your instance/machine may go down, we will attempt to recover your data. The ability and speed depends largely on why the machine went down and whether we run RAID/etc on the machine."
I've waited weeks for a disk repair from very well known/regarded non-Amazon hosts. Redundancy is needed everywhere, not just on Amazon. Bare metal still dies, controllers flake out, networks go down.
No messing with support tickets or waiting (sometimes hours) on someone to talk out to the data center to troubleshoot it. Its just fixed.
With EC2 my approach has always been that if you've got enough traffic to justify it, you should move rather quickly to a load-balanced solution. This really forces you to stop relying on what's stored on any particular server, and focus your energy on making sure you can boot new ones and get them seamlessly into the rotation.
Obviously this doesn't work for stuff like databases (for which I definitely recommend RDS or SimpleDB if they suit your needs), but even there, if you're hosting your own and make sure that the data goes on to EBS volumes instead of the instance stores, you can set things up so that you snapshot those volumes regularly and can boot up new database servers without trouble.
Services like Rightscale can help manage stuff like this pretty easily, too, though they're probably a bit expensive for startups (and you've got to be willing to put in a little setup time, I've always found that their templates needed pretty substantial customization to suit my needs); in any case, Amazon is starting to pull more of that type of functionality into AWS itself, with stuff like CloudFormation and Elastic Beanstalk, so if I was starting now, I'd probably give those a closer look.
You have an interesting definition of "all the time". In my experience, EC2 instances fail less often than dedicated servers.
We have had three instances degrade within a week. So far, we have had five instance degrade. At current degradation rate, nearly 100% of our production servers would degrade every year.
It took a lot of work to try and get, from Amazon support, the expected degradation rates of their servers. Their response was as I described: implement redundancy. They never did let me know their expected degradation rate.
Admittedly, we have not seen any degradation in a few months. However, this doesn't make me feel any better.
The nice thing about the fact that EC2 instances are at least to some degree ephemeral is that it forces you, from the start, to have a solid backup/restore plan. And when an EC2 instance goes down, you can have another one booted within minutes, compared to the days/weeks that it might take to get another physical machine set up.
That's not even to mention scaling issues; right now I'm managing a stack of over 50 EC2 instances, and it's easily manageable by a single person (most of those are in a load balanced array, and they'll come up and go down automatically as load dictates). I have no idea what I would do if I had to physically set up servers to handle this type of shifting load...
Whaaaa?
What does 50 EC2 instances correspond to in the hardware world, appwise (not environment)? Each of my Rails/Apache processes are about 75M (unoptimized, natch), which means 50 will sit OK in 4G RAM. Since that is laptop-caliber hardware capacity, I'm still not seeing the benefit in the server world (or even an 8G PC). From where I sit it seems to involve a lot of domain knowledge that is not relevant once you stop using EC2.
Naturally, EC2 is totally great for spinning up and prototyping, but from my research its most compelling benefit is geographic dispersal, which can also be accomplished otherwise.