Live data from Hacker News

Why we moved away from AWS

blippex.github.io

41–50 of 102 posts

Re: Why we moved away from AWS

#41
post #4

EC2 was designed for elastic computing. On demand high computation (low memory) that are elastic. With that in mind, pure EC2 is a terrible choice for general web application hosting. If using the complete AWS set (S3, simpleDB, etc) then it makes more sense as stuff like db hosting can be pushed out to their services designed for it, but if you're gonna fire up a windows box, stick SQL server on there and use it as…

pure EC2 is a terrible choice for general web application hosting "Terrible" is seriously overstating it. There are a lot of advantages to AWS (I understand you said "pure", but that really makes no sense in the context of AWS) that can justify the price premium -- ELB, elastic IPs, the ability to spit out AMI images (and machines from them) at will, the private networks, the firewall, etc. The fantastic network capa…

> I am always wary of services like OVH that offer "unlimited" anything, because it is always limited, and unlimited means that your peers will be saturating switches because it's "free"

Comparing bandwidth between OVH and AWS is a little cheeky. Bandwidth on AWS costs an absolute fortune, not remotely economical for bulk transfer.

The switch saturation problem doesn't even necessarily go away if you instate X TB/month data caps. I would have thought local switches could handle it anyway, with cheap boxes typically only having 100Mb ports.

Some data centers don't even charge for internal traffic, which means you're still exposed when cheap VPSs and dedis are used as P2P file sharing nodes and are exchanging a lot of traffic within the building.

In any case, I'm just grateful the multi-terabyte range is so affordable, bulk transit costs in the data center has been falling year-on-year for a decade, and lots of hosts don't seem to have passed on the benefits.

Incidentally, OVH do have different SLAs across their server range. The low end stuff is "best effort", the more expensive options are supposed to be "guaranteed". They even tell you what switches they use.

> OVH is very, very bare bones, and you'd better have an escape hatch because the simplest configuration error can leave your machine incapacitated and beyond reach

Their network boot facilities are pretty handy. As long as you use a sensible filesystem you can always network boot their recovery option and access your files (and I think chroot in?). The lack of KVM is annoying though... especially when you're like me and compiling and running custom kernels (but you can network boot one of their kernels as well).

Re: Why we moved away from AWS

#42
Amazon's win is elasticity, moving your servers up and down often. It's not as big of a win if you have a known quantity of resource utilization over a long time period.

Actually, there is a win to be had there too. If you can spin down your instances with load in an intelligent way, you can save A LOT of money using a combination of reserved instances an on demand instances.

However, if you had a program that was smart enough about dealing with load and spinning up/down instances and managing cost relative to reserved instances, on demand instances, and spot instances, that could save a ton of money.

That kind of optimization is tricky so it's a lot easier to just switch providers like the OP.

Re: Why we moved away from AWS

#43
post #37
post #6

AWS isn't really a solution for people trying to run a "small" project on a fixed amount of servers 24/7. It's great if you want to be able to: - provision lots of machines without delays - launch and terminate new instances to cover load spikes - do geo-redundant failover (aka: a datacenter in Europe, Australia, the US, ...) - have 'plug and play' components like load balancers (ELB), storage (S3), databases (RDS),…

I'm running a small project on a fixed server 24/7 and AWS makes sense for me. Why? I'm a one man team supporting a research project. I have no ability to self host. I have no time to look around at a lot of options and trying to figure out all the details of every offering. I need a server that has good uptime and good performance. Most of all, telling my users that we're hosted on Amazon makes them feels secure - i…

A dedicated host would most certainly be a better (and cheaper) option for you, but hey, if you don't have time to look around, I suppose it's a reasonable trade-off.

>I need a server that has good uptime and good performance.

Then a single EC2 instance is not a good option for you. Terrible up-time, and terrible performance.

Re: Why we moved away from AWS

#44
post #4

EC2 was designed for elastic computing. On demand high computation (low memory) that are elastic. With that in mind, pure EC2 is a terrible choice for general web application hosting. If using the complete AWS set (S3, simpleDB, etc) then it makes more sense as stuff like db hosting can be pushed out to their services designed for it, but if you're gonna fire up a windows box, stick SQL server on there and use it as…

[deleted]

Re: Why we moved away from AWS

#45
post #13

If you move to Rackspace, stay away from DWS, the dallas datacenter. It's over-booked, the network has constant issues, vm's on the same host machine as you are able to cause your vm network issues, the list of problems never stops. We recently switched to Azure from Rackspace, but we're still evaluating if it will work for us long term. Azure's issues are that you have to request number of core increases, and you ca…

I too have had issues with connectivity with Rackspace. Also anecdotally I've heard that the main recommended solution by the article in the OP, hetzner, is one that crashed non stop for someone in the past.

You just can't beat AWS right now for reliability, feature set and speed. We started using them recently and they are a tiny bit more expensive. But it's the difference between fresh air and breathing carbon monoxide.

At least so far.

Re: Why we moved away from AWS

#46
post #37

Earlier quoted context omitted.

I'm running a small project on a fixed server 24/7 and AWS makes sense for me. Why? I'm a one man team supporting a research project. I have no ability to self host. I have no time to look around at a lot of options and trying to figure out all the details of every offering. I need a server that has good uptime and good performance. Most of all, telling my users that we're hosted on Amazon makes them feels secure - i…

A dedicated host would most certainly be a better (and cheaper) option for you, but hey, if you don't have time to look around, I suppose it's a reasonable trade-off. >I need a server that has good uptime and good performance. Then a single EC2 instance is not a good option for you. Terrible up-time, and terrible performance.

Can you supply more details - maybe I am missing something. My EC2 instance has been up for 249 days now and my node.js webserver instance seems very responsive. I still think it's a reasonable trade-off in terms of cost. My time is expensive, and to be honest even a few hundred dollars a month extra in server cost is not important. This is a research project, not a commercial website, so my needs may be different than most.

Re: Why we moved away from AWS

#47

>there are also downsides when moving it to your server, more system administration, you have to build your own firewall, take care of security & backup, et Startup idea right there. But then if I thought of it so quickly, somebody probably already does this.

Yea, we have a global public IaaS cloud that puts a real Cisco firewall / load balancer in front of your subnet(s): https://nacloud.dimensiondata.com/

Re: Why we moved away from AWS

#48
AWS is a great place to start if you're not yet sure what resources and scale you need. You can play with various solutions and easily scale up.

It makes developing so much more efficient when you don't have to make major choices up front, and can buy yourself some breathing room by throwing temporary resources at most performance issues while you review your architecture.

That either stabilizes to a point where you have an architecture that you can implement cheaper and more efficient using more traditional hosting solutions, or you come to a point where you really need AWS's flexibility.

One caveat though: don't make your architecture too dependent on AWS-specific services until you are 100% AWS is the right choice for the long term.

Re: Why we moved away from AWS

#49
post #13

If you move to Rackspace, stay away from DWS, the dallas datacenter. It's over-booked, the network has constant issues, vm's on the same host machine as you are able to cause your vm network issues, the list of problems never stops. We recently switched to Azure from Rackspace, but we're still evaluating if it will work for us long term. Azure's issues are that you have to request number of core increases, and you ca…

I'd stay away from Rackspace London as well. Horrible horrible experience. 1. Noisy neighbours impact you all the time 2. The staff are really poorly trained and don't know how to troubleshoot. 3. They're expensive. 4. Their control panels are really bad, constantly being updated and migrated, and are just a complete mess. 5. They've had several major network outages that have lasted for quite a long time (hours) tha…

Was this on the 1st-gen and/or 2nd-gen Rackspace cloud servers?

Re: Why we moved away from AWS

#50
post #16
post #10

Earlier quoted context omitted.

As i said in the blogpost, we still love AWS, its awesome, we used it for many other projects and S3 is great in combination with EC2, but in some cases it makes sense to think about it, maybe it saves you something! As i said, we really miss the simplicity of AWS, one mouse click and you have a loadbalancer, ec. PS: trust me, AWS EBS volume can die, and this is a pain! :)

I think the trick here is figuring out how much day-to-day workload you can host in a more traditional cost-effective way and how much elastic workload you can use EC2 for.

Yes, the beauty of that is that if you can handle spikes with EC2 (or any other cloud provider) quickly, then you can load the servers that handle your base load much, much higher.

You might not even need to spawn EC2 images very often - many sites have daily variations that are too small for it to really be worth it. If your hosting is cheap, spawning EC2 images for more than 6-8 hours per day might already be ineffective compared to renting more servers on a monthly contract. But just having the ability might make the difference between aiming for a peak utilization of, say, 50% of your servers, in case of unusual peaks or server failures, and aiming for a peak utilization of 90%+.

That can make a huge difference in cost.

Post reply on HN