Microsoft Azure Web Sites Ready to Take on Public PaaS Leaders
With the software update announced last week, Microsoft nearly closed the gap between it and other leading Platform-as-a-Service offerings. With refined pricing, free SSL support, global DNS load balancing, and the introduction of Java support, Azure Web Sites appears to be a strong competitor for Heroku, Google App Engine, OpenShift Online, Cloud Bees, and Engine Yard.
Microsoft VP Scott Guthrie recently blogged about a set of updates to the Microsoft Azure platform. Among them were four updates to the Azure Web Sites PaaS service. First, the “Standard Tier” of Azure Web Sites – which is the most expensive tier but lets users deploy an unlimited number of websites – now includes 5 free SNI-based SSL certificates and 1 IP-based SSL certificate at no charge. For those running in different a Web Site tier or when the free allotment is exhausted for Standard customers, those certificates cost $9 per month and $39 per month, respectively. Speaking of tiers, Microsoft added a new “Basic Tier” that’s missing features like Auto Scale, staged applications, and background Scheduler access, but is 25% cheaper than the Standard Tier. Microsoft also added support for mapping wildcard DNS and SSL certificates to sites running in Azure Web Sites. Guthrie pointed out that this feature would be useful to those running custom SaaS applications on the Azure platform.
Another update to Azure Web Sites was the added support for Azure Traffic Manager. This service routes DNS requests to different Azure endpoints based on geography, endpoint availability, or a simple Round Robin algorithm. After this change, users can add “Web Sites” as a valid service endpoint type for Azure Traffic Manager profiles. This service acts like a global load balancer that lets developers deploy their web application in data centers around the world and efficiently route traffic to the ideal host.
Finally, developers can now deploy Java applications to Azure Web Sites. The default, supported version of Java is 1.7.0_51 and developers have a choice between Tomcat 126.96.36.199 or Jetty 9.1.0 as the Java container. In a blog post about this particular update, Microsoft Program Manager Chris Compy pointed out some service extensibility, and some constraints.
Beyond what is offered in the portal UI or in the web application gallery, customers are also able to upload their own versions of Java, as well as Java based applications. For example, a customer could choose to upload Java 6 and Tomcat 6 instead of using what is available on Azure Web Sites.
Because many enterprise class Java applications require substantial memory, there is also the ability to run the 64 bit version of Java 1.7.0_51. For now developers will have to choose the 64-bit runtime through configuration in the web.config file – in the future the 64-bit version will also be selectable from the UI.
At least initially all Java applications running on Azure Web Sites only listen for incoming HTTP traffic. This means currently no JMX or JMS messaging and no JDWP or JDI remote debugging at this time.
Also note that all Java processes must run as applications and not as services.
How does Azure Web Sites stack up to some long time providers of web application PaaS services? In the table below, InfoQ compared the built-in functionality of Azure Web Sites to 5 other PaaS platforms including Heroku, Google App Engine (GAE), OpenShift Online (OS), CloudBees (CB), and Engine Yard (EY).
|Built-in application scaling||x||x||x||x||x||x|
|Load balancing – single region||x||x||x||x||x||x|
|Load balancing – multiple regions||x|
|Deploy from source control||x||x||x||x||x||x|
|OS virtualization containers||x|
|Custom background jobs||x||x||x||x||x||x|
|Add-on, service ecosystem||x||x||x||x||x||x|
This Azure update signals an aggressive push by Microsoft to be a top tier provider of cloud-hosted web applications. The PaaS market itself continues to evolve as a mix of public and private providers refine the nature of application hosting at scale. Previous InfoQ articles such as “What is Going on With PaaS?” look at the slow adoption of PaaS and how the definition itself is changing. A recent InfoQ roundtable by this editor gathered four cloud experts to talk about the future of PaaS and how it’s changed since services like Google App Engine and Heroku first burst on the scene.
Elastic BeanStalk is very close to some automation on top of IaaS. You can get quite close with Chef/Puppet +EC2 from a very simplistic view point. It basically spins up VMs in your account and deploys the app you provide. They've obviously smoothened the edges and productized it well with associated APIs etc. It's essentially very thin automation layered on top to make their IaaS easier to consume.
Google App Engine, Azure Websites and Heroku are a little more sophisticated. It' not just spinning up VMs and then deploying a WAR or something similar. They are environments that are designed to be multi-tenant and there are some associated differences that ensue as a result.
Just wanted to call out these "PaaS"es are not exactly apples-to-apples. EC2 is climbing up the stack from IaaS -> PaaS and their environments are more VM centric. The others are more app centric and climbing down the change from PaaS -> Iaas (GAE, Azure etc).
Just my two cents.