Windows Azure has historically been a pure PaaS solution with the deployment unit for compute being a hosted service comprising an optional web role and zero or more worker roles. Each role is deployed as one or more virtual machine instances. A hosted service formed a security boundary, with the only way to access role instances being through the load-balanced public input endpoint. Role instances inside a hosted service can communicate directly using internal endpoints which provided lower latency because they didn’t go through the Windows Azure load balancer.
In June 2012, Microsoft announced previews of Windows Azure Virtual Machines, an IaaS offering, and Windows Azure Virtual Networks. It also brought a name change from hosted service to cloud service for the compute deployment unit. There is a little bit of confusion about the use of cloud services because, to make the deployment of a single virtual machine as simple as possible, a cloud service is implicitly created when a single IaaS Virtual Machine is deployed. This cloud service is only made apparent in certain circumstances such as the deletion of the Virtual Machine or the association of a second Virtual Machine with the first.
Microsoft simultaneously announced a preview of Windows Azure Web Sites (WAWS) which provides a scalable, high-density, web hosting solution. The emphasis in WAWS is on ease of deployment which is far better with WAWS than it was with PaaS web roles. However, this ease of deployment comes with more restrictions on deployments than there had been with traditional PaaS web roles.
At any given time, a cloud service hosts either a PaaS deployment or an IaaS deployment – but not both. Either a PaaS service or an IaaS service can be deployed into an empty cloud service. Some of this functionality is not exposed on the Windows Azure Portal, and can only be achieved using either PowerShell or script cmdlets.
The (awesome) Windows Azure Platform Training Kit contains a hands-on lab (Windows Azure Web Sites and Virtual Machines using ASP.NET and SQL Server) which uses a Windows Azure Web Site as the front end for a Virtual Machine hosting SQL Server. This HOL uses a public endpoint for the SQL Server Virtual Machine – which consequently means there is a raw SQL Server endpoint sitting on the public internet.
Hanu Kommalapati has posted an interesting example which hosts a Cassandra cluster in 3 Virtual Machines with a front-end provided by a another Virtual Machine running a web server developed in Node.js. This example also uses a public endpoint for the Cassandra cluster – which consequently means there is a raw Cassandra endpoint sitting on the public internet.
Virtual Networks improves the composition of cloud services by allowing one or more of them to be added to a Virtual Network. Note that when a Virtual Network is used to host cloud services, the security boundary is extended to comprise all the cloud services in the Virtual Network. A cloud service in a Virtual Network can directly access individual instances in a second cloud service contained in the Virtual Network without going through the load balancer hosting a public input endpoint for the second cloud service. This means that once a traditional PaaS cloud service is added to a Virtual Network the cloud service no longer forms a security boundary and any open port on its role instances can be accessed by any instance of any cloud service in the Virtual Network. This is regardless of whether the cloud service is IaaS or PaaS.
A back-end data service, hosted on virtual machines in an IaaS cloud service, can be kept off the public internet but remain accessible to role instances hosted in a front-end PaaS cloud service. Similarly, an IaaS cloud service can access the role instances of a PaaS cloud service without any need for the latter to have (input) endpoints exposed to the internet.
The first example described earlier – a WAWS front end to a SQL Server back end – cannot use this technique because a WAWS website cannot be added to a Virtual Network. However, the example would work were the front-end website to be hosted by a PaaS web role located in the same Virtual Network as the back-end SQL Server Virtual Machine. The latter would not need a public endpoint it would only need an appropriately configured firewall. The second example can use this technique, with the Node.js cloud service having a public endpoint and the Cassandra cluster having no public endpoint.
A very important point is that the Virtual Network MUST be created before any cloud services are created in it since once a cloud service has been created it is not possible to migrate it into a Virtual Network.
Michael Washam describes this technique in one of the excellent posts on his blog.
Creating the Virtual Network
A Virtual Network is created using the Networks item in the preview Windows Azure Portal. This brings up a wizard which requests the following information:
The Virtual Networks page requests the following information:
- Affinity Group
The Address Space and Subnets page requests the following information:
- Address space (for the network) in the format a.b.c.d/x. For example:
- Address space for the subnets in the format a.b.c.d/x. For example:
- FrontEnd: 10.10.10.0/24
- BackEnd: 10.10.11.0/24
The DNS Servers and Local Networks page can be passed through without providing any information.
Once the virtual network has been created, its configuration can be viewed as follows:
Adding a Virtual Machine (IaaS cloud service) to the Virtual Network
An IaaS cloud service is added to the virtual network by creating it from the gallery and specifying the appropriate virtual network when asked for the Region/Affinity Group/Virtual Network. The appropriate subnet is selected on the VM Options page in the wizard, as follows:
Once the virtual machine has been created, remote desktop can be used to access it. The Window Firewall with Advanced Security application can then be used to modify the firewall as needed.
Adding a PaaS Cloud Service to the Virtual Network
A PaaS cloud service is added to a virtual network by adding a NetworkConfigurationsection to its Service Configuration file. This is located after the end of the Role section. For example:
<NetworkConfiguration> <VirtualNetworkSite name="SampleNetwork" /> <AddressAssignments> <InstanceAddress roleName="ContactManager.Web"> <Subnets> <Subnet name="FrontEnd" /> </Subnets> </InstanceAddress> </AddressAssignments> </NetworkConfiguration>
Services on role instances can be exposed to other virtual machines in the Virtual Network by modifying the firewall on each role instance.
The Windows Azure Virtual Network feature, currently in preview, provides the ability for cloud services to interact with each other without exposing services to the public internet. This is a significant enhancement since previously cloud services could not be grouped into composite services without exposing required endpoints to the public internet.