Why no mention of Windows Azure?

Windows Azure provides many features supporting PHP. They also haven't had the outage problems experienced by Amazon. Amazon's main outage had to do with their Elastic Block Storage (EBS). Which, as readers of Reddit can tell you, has had quite a few unreliable moments, and in the latest outage actually lost some data. The problem is that EBS is not automatically replicated to multiple availability zones. So the companies that did not handle replication themselves, had the longest outages and some lost data.

In comparison, Azure Storage is automatically replicated into multiple availability zones. So if one, or even two zones go down, data will still be available. Further, as soon as a zone goes down, replication into new zones starts automatically.

For further info on Azure Storage, check out these videos from Microsoft's Professional Developers Conference:
------------------------------
Windows Azure Storage Deep Dive:
channel9.msdn.com/Events/PDC/PDC10/ ...
Windows Azure Blob and Drive Deep Dive:
microsoftpdc.com/2009/SVC14
------------------------------

For further info on PHP in Azure:
------------------------------
Developing PHP Applications on the Windows Azure Platform:
channel9.msdn.com/Events/PDC/PDC10/ ...
Developing PHP and MySQL Applications with Windows Azure:
microsoftpdc.com/2009/SVC51
------------------------------

About Me: I'm currently a Microsoft Intern working on Azure Storage. Please feel free to ask me any questions about Azure Storage in this thread.

We already know about Azure. Actually we talked about it several times here:

phpclasses.org/blog/post/100-PHP-on ...

phpclasses.org/blog/post/85-What-is ...

The discussion on this podcast was not about specific cloud solutions, but the promises of reliability of the cloud in general that are failing in the real world situations.

Now it was Amazon, but nothing tells us that in the future it may not be Azure as well.

What you said about Azure reliability and falling back to backup availability zones was the same as what Amazon used to say.

In practice we see that there is a long way to go for cloud solutions to prove themselves as reliable as the vendors claim them to be.

Other than that, what this Amazon episode teach us is that relying on proprietary database or file systems provided by some cloud vendors leaves you trapped with a solution to which you do not have access to backup data so you can restore the site elsewhere on your own.

Maybe relying in clustered MySQL or some other Open Source solution would have been better for all those sites that loss with outages.

We also commented that we could consider multi-cloud solutions to be more reliable, but even if technically feasible, that would up to be too expensive to most of our sites.

The bottom line, is that the problems of the cloud solutions are not so much vendor related but rather with the way cloud architectures are implemented.

Thanks for your reply. I see that Azure has been mentioned before. I just thought since App Engine was mentioned in the current article, Azure should be there somewhere too since it supports PHP =)

As to the reliability of the cloud, not all AWS applications were equally effected, even if they had instances running in the availability zones that went down. As an example, SmugMug had very few problems:
don.blogs.smugmug.com/2011/04/24/ho ...

In fact, what happened to SmugMug is exactly what's supposed to happen. They had a slight slowdown because some of their compute instances were not currently available, and about 5 minutes of outage due to a load balancer problem. In contrast, had they been on a typical server, they wouldn't have had multiple instances running. And so they would have experienced a complete outage. For SmugMug, the cloud worked exactly as advertised.

The Amazon outage isn't really a general "cloud" architecture problem. The outage was restricted almost completely to Elastic Block Storage (EBS). EBS is specifically noted to have low durability (http://aws.amazon.com/ebs/), and so they recommend making S3 snapshots of EBS volumes. Each EBS volume is replicated to multiple servers within the same availability zone, but not across multiple availability zones. So, by design, EBS is not completely reliable or durable. In contrast, applications not using EBS, and instead using only Amazon Simple Storage Service (S3), which is much more durable and has higher availability guarantees, had almost no issues.

My point is, let's not overgeneralize this particular outage as a problem with cloud computing architecture -- it was a problem with the EBS architecture. Nor do you need to replicate your system across multiple vendors (which as you said is complicated and expensive). The current problem with cloud computing is that it's not as simple as, put your application in the cloud, and now it'll never go down. Developers of cloud based applications need to understand the underlying reliability of each service in a cloud system as well as we understand self-managed and remotely deployed servers. We can't go for the cheapest and simplest solution in the cloud, which is a single instance in a single availability zone storing data on EBS. If you put up 3 instances, each in a different availability zone, and stick with highly reliable and durable storage, then chances are slim that your service will ever go down -- even when something as catastrophic as Amazon's latest outage happens.

Right, not all cloud solutions had serious problems, but my point is that it does not mean they will never have. That is OK, except for the fact that the cloud has been hyped as the robust solution that we know it isn't.

The vast majority of the sites is still too small to justify moving to a cloud structure. But the cloud marketing is trying to push everybody to the cloud as if you will ever reach to the point that you need an elastic infrastructure.

Furthermore, once you adopt a cloud solution, you are stuck with its provider. If you want to switch to a provide that offers better prices, better resources, etc.. you can't because each cloud solution provides an incompatible proprietary API.

The cloud may be great for provides that attract customers, but for most of us it is a step backwards.