[mattmanser]

Reliability wise, do you actually use these services, as in my experience that's a complete myth.

One of my clients on a dedicated server has never gone down. The site is blazingly fast, barely touches 5% CPU and pages have sub 50ms response times. Deploys take 10 seconds or so, I could make it faster but it's not really worth the cost/benefit.

My client on Azure, with a significantly lower visitor count, pays 3-10 times as much, the site is sluggish, takes a long a time to spin up after deploys, hangs ocassionally, we've caught the whole site being offline a couple of times then it mysteriously starts working again with nothing in the logs, had a deploy to one site take down other sites and on top of that there's a 3-5ms delay between the database and website which causes all sorts of performance problems when a page makes too many DB requests.

They've had to "scale up" to premium database in the past to handle loads I know a much cheaper dedicated server would have handled without even thinking about it.

On top of that, Azure's management portal is super slow, regularly fails to execute commands and is incredibly frustrating to navigate and use.

The claimed machine you get on cloud aren't anything like as performant as supposedly similar machines on dedicated.

I'll admit I've generally found AWS to be significantly better than Azure, but still very expensive.

And AWS went down a couple of weeks ago too.

[gravypod]

> on top of that there's a 3-5ms delay between the database and website which causes all sorts of performance problems

Yea that's something I don't get too. With all of that IPC going over amazon's network for all of their services how much time are programs wasting sending and waiting for messages from other amazon services?

I never really thought about that. If someone could measure this it would be interesting.

[rbranson]

I can't comment on Azure, but most of the complaints about networking issues in AWS went away when they redesigned their networks around an SDN model with VPC. We see consistent <1ms RTTs within region, and <300µs within availability zone (datacenter).

[mattmanser]

I've got a reply from Google Compute before after complaining about how bad Azure was saying they'd has similar problems but solved the latency between servers and databases. It basically just sounds like the Azure guys have severely mucked up their infrastructure.

We have a test page that runs 100 "SELECT 1" SQL queries ON THE SAME CONNECTION between an Azure website and an Azure database and it takes a whopping 250ms to complete at best. That's literally all it does. And their infrastructure is so bad that it'll vary from 250ms to 600ms in the space of 20 seconds in peak periods. That's damning, cloud infrastructures are there to part you from your cash, nothing more.

It's ridiculously bad, in my opinion no professional should EVER recommend Azure. My client is enamoured with telling people the system runs on Azure, with its "secure" network, nothing I've told him makes a difference, but he'd have a much better service if he moved it off Azure.

Because we develop with the entity framework it's quite easy to muck up and forget an include or two and then suddenly the queries spawn a hundred or two hundred basic SELECT queries to populate a `Order.OrderItem` or something as trivial. On a standard dedicated server setup or even your worst 5 year-old crappy dev laptop that's a ms or 2 extra, but on Azure it's performance death.

There are advantages to using Azure, I admit, the easy deploy from github for example, but that's more because setting up deploying from a repo to IIS is such a bad workflow at the moment and the IIS management too. They don't want to make it easy. With other clients I've setup moderately complicated deployment scripts, and once the initial work is done, it's much better than Azure, you run a bat, boom, deploy much faster than Azure manages. 10-20 seconds without even pre-compiling the pages, Azure will take 5 or 10 minutes to finally get round to doing it and woe betide you doing it at peak times as it will use up your memory allocation and simply hang for 20 minutes while you frantically try and restart it while the azure management portal has a massive spaz (yes, we unfortunately deployed a serious bug, fixed it, tried to re-deploy while under heavy load, cue website down for a ridiculous amount of time while their management portal threw a ton of weird and inscrutable errors before we finally managed to restart it).

[rbranson]

Yikes. I've only really had true production experience with AWS. I guess all clouds aren't made the same.

[djchen]

I have used AWS at a couple work places and I personally use Google App Engine. My sites on App Engine have less than 5 minutes of downtime per year as measured by Pingdom. Deploys to App Engine take a few seconds (though it can depend on your app).

You can choose to run your DB servers on top of generic compute instances in Azure or any other cloud provider. You aren't stuck using their database services.

> The claimed machine you get on cloud aren't anything like as performant as supposedly similar machines on dedicated.

This is true, I don't think anyone will dispute that.

[vacri]

> One of my clients on a dedicated server has never gone down. The site is blazingly fast, barely touches 5% CPU and pages have sub 50ms response times. Deploys take 10 seconds or so, I could make it faster but it's not really worth the cost/benefit.

One of your clients... where? Without even giving a location, this doesn't even qualify as 'anecdata'.