Main screen for a cloud application.

Developer Jason McEvoy gave us a what’s what on Azure, a Microsoft solution for hosting services to give us an idea of how we may use this internally or for client projects. Basically, Azure is a set of connected computers that install and run services and supports multiple protocols (HTTP, REST, SOAP, XML). It comes as SDK for Visual Studio 2008 and supports both Microsoft and non-Microsoft languages (RubyOnRails, Python and in the near future, PHP). It uses Simple Data storage (tables, blobs, queues) with authenticated access). The pluses? Security is tight, comparative to Medium Trust. Everything is done through a web portal, not an FTP. The portal makes it easy to scale applications as needed (see photos), like adding more processing, which fits the pay as you go policy.  You can tie to your Windows Live ID for accounts too. The downsides? No FTP can be an issue, especially in times when it makes more sense to copy just the files you need rather than pushing the entire site. You can’t VPN into it, which is a problem for companies like ours where you may need access from virtually anywhere outside the physical office. A cool feature is the differentiation between staging and production environments. You can set a region for your services to reside for times you don’t want to run the website on one side of the country and have the database at the other side of the company. For example, you can specify all your services to run from servers from the Pacific Northwest. All in all, it seems that Azure is more suited to serve potential client needs than for our internal work. As a company that does both design and development for agencies located geographically far away, hosting in the cloud could be a great option for some project. Internally, the lack of VPN access and the need to rewrite existing processes would keep us from using Azure for much of our internal needs. But we think options are good, especially when you understand what can (and can’t) be done with them.