On Thursday 7th, Microsoft launched a new version of Windows Azure. The launch included a new management interface (to replace the old Silverlight one), Linux VMs and a new caching feature. One of the more interesting features however, is the new Azure Web Sites. Web Sites addresses the lacklustre deployment experience that plagued Azure, one of the problems that AppHarbor set out to solve.
We’re excited to see Microsoft adopt a deployment approach so similar to AppHarbor’s. Microsoft launching Azure Web Sites validates the approach to deploying .NET applications that we’ve been pioneering for the past year-and-a-half.
Are we worried about the Azure Web Sites launch? Not really: When building AppHarbor, we set out to build a better platform than Azure. With Web Sites, Azure got slightly better, but the situation is the same: We’re still committed to making AppHarbor the best place to deploy and host .NET applications in the cloud.
Looking at the Web Sites feature in greater detail, there are some interesting things to note:
- Azure Web Sites has no equivalent to AppHarbor background workers to handle background processing for your app.
- Azure Web Sites has no way to add your own SSL certificates at all. If your app needs SSL, you’re stuck with running on the Azure subdomain and piggy-backing off their certificate.
- Naked domains are not supported for sites running on Azure.
- You can only add custom hostnames to apps running on reserved instances, not to apps running on shared infrastructure.
- There’s no free database option that you can use for test- and staging-apps
- Microsoft announced a few external service providers at the launch (ClearDB MySQL and Cloudant), but Cloudant is not yet available in the interface and it’s at any rate a rather limited selection compared to our add-on catalog
- Unit tests are not run before your code is deployed to Web Sites, leading you to potentially push faulty code
- While Azure Web Sites have a free option during the test period, there’s no permanently free option like on AppHarbor.
- Azure Web Sites has no notion of several developers collaborating on an application.
Other than the slick and responsive user interface on the new Azure, we’re also rather impressed with the performance monitoring, logging and error reporting features built into Web Sites. On AppHarbor, you can get detailed logging and performance monitoring courtesy of New Relic, but we’re working on augmenting this with better built-in platform support.
The way we think about Azure Web Sites is summed up very well by Marco Arment when writing about Apple launching a service similar to Instapaper, a service he built:
My biggest challenge isn’t winning over converts from my competitors: it’s explaining what Instapaper does and convincing people that they actually need it. Once they “get it”, they love it, but explaining its value in one quick, easy-to-understand, general-audience sentence is more difficult than you might imagine.
Now that Microsoft has launched Web Sites, they’re going to spend tons of time and money educating .NET developers that the AppHarbor way of deploying and scaling .NET applications is the best one. This is great for us since more developers will want to use source-code based deployment services and we’re confident many will choose AppHarbor when they realise the limitations inherent in Azure Web Sites.
While Azure Web Sites is an improvement on the previous Azure deployment experience, we strongly feel that AppHarbor has lots of advantages, and we’ll work hard to make sure things stay that way. We look forward to welcoming lots of new developers, educated by Microsoft that source-code based deployments is the way to go, onto AppHarbor.