Oh my, is it possible that It’s been more than three months since I posted here? In my defense, I have another blog that I now post on – well, a few actually, including blog.gopivotal.com and blog.cloudfoundry.org. I’ll post a summary of my recent submissions with links soon.

I am, in fact, about to go live with a new post over there and I’m experimenting with embedding some vine. So this is a test.

And not to leave you hanging, this vine highlights a feature of the Cloud Foundry PaaS – one (spoiler alert: of 4!!) way that the platform keeps your apps running. When configured to use two “availability zones”, the elastic runtime part of the PaaS will evenly distribute your application instances over all AZs so that if you loose one AZ you are guaranteed that application instances are still available and serving traffic. This is one of the things that beautifully demonstrates the benefit of PaaS over IaaS.

I’m sure you’ve all heard the stories about an AWS AZ going down and taking with it a bunch of web sites/apps. You know what? That’s not Amazon’s fault; there is no way that Amazon can or would guarantee constant uptime of all AZs – that’s why they offer you more than one. As an application devops leveraging AWS you have the option of deploying your applications across AZs so that if one fails your app is still running. But you are responsible for planning this and executing on it. When an AWS AZ goes down and takes an app with it, you know the option was not exercised. With Cloud Foundry we take care of that for you. You just push your app with multiple instances and we’ll take care of the distribution.

Oh, and I should note that Cloud Foundry availability zones are supported even when running on IaaS other than AWS – in case you didn’t know, Cloud Foundry runs over vSphere, OpenStack, AWS, CloudStack and more.

There’s more to come but that’s enough for this simple test.