With the introduction of Windows Azure Connect, many options for an on-premises application to integrate with or migrate to cloud at an infrastructure level are available. The integration and migration opportunities will become apparent by examining how applications are architected for on-premises and cloud deployments. These concepts are profoundly important for IT pros to clearly identify, define, and apply while expanding the role and responsibilities into a cloud or service architect. In Part 2, let’s first review computing models before making cloud computing a much more exciting technical expedition with Windows Azure Connect.
Then Traditional 3-Tier Application Architecture
Based on a client-server model, the traditional n-tier application architecture carries out a business process in a distributed fashion. For instance, a typical 3-tier web application as shown below includes:
When deployed on premises, IT has physical access the entire infrastructure and is responsible for all aspects in the lifecycle including configuration, deployment, security, management, and disposition of resources. This had been a deployment model upon which theories, methodologies, and practices have been developed and many IT shops operated. IT controls all resources and at the same time is responsible for the end-to-end and distributed runtime environment of an application. Frequently, to manage an expected high volume of incoming requests, load-balancers which are expensive to acquire and expensive to maintain are put in place associated with the front-end of an application. To improve data integrity, clusters which are expensive to acquire and, yes, expensive to maintain are configured at the back-end. Not only load-balancer and clusters increase the complexities and are technically challenging with skillsets hard to acquire, but both fundamentally increase the capital expenses and the operational costs throughout the lifecycle of a solution and ultimately the TCO.
Now State-of-the-Art Windows Azure Computing Model
Windows Azure Platform is Microsoft’s Platform as a Service, i.e. PaaS solution. And PaaS here means that an application developed with Windows Azure Platform (which is hosted in data centers by Microsoft around the world) is by default delivered with Software as a Service, or SaaS. A quick review of the 6-part Cloud Computing for IT Pros series, one will notice that I have already explained the computing concept of Windows Azure (essentially Microsoft's cloud OS) in Computing Model and Fabric Controller. Considering Windows Azure computing model, Web Role is to receive and process incoming HTTP/HTTPS requests from a configured public endpoint, i.e. a web front-end with an internet-facing URL specified during publishing an application to Windows Azure. A Web Role instance is deployed to a (Windows Server 2008 R2) virtual machine with IIS. And the Web Role’s instances of an application are automatically load-balanced by Windows Azure. On the other hand, Worker Role is like a Windows service or batch job, which starts by itself and is the equivalent middle-tier where business logic and back-end connectivity stay in a traditional 3-tier design. And a Worker Role instance is deployed with a virtual machine without IIS in place. The following schematic illustrates the conceptual model.
VM Role is a definition allowing a virtual machine (i.e. VHD file) to be uploaded and run with Windows Azure Compute service. There are some interesting points of VM Role. Supposedly based on separation of responsibilities, in PaaS only Data and Application layers are managed by consumers/subscribers while Runtime layer and below are controlled by a service provider which in the case of Windows Azure Platform is Microsoft. Nevertheless, VM Role in fact allows not only Data and Application, but also Runtime, Middleware, and OS layers all accessible in a virtual machine controlled by a subscriber of Windows Azure Platform which is by the way a PaaS and not IaaS offering. This is because VM Role is designed for addressing specific issues, and above all IT pros need to recognized that it is intended as a last resort. Information of why to employ VM Role and how is readily available elsewhere, and not repeated here.
So, with Windows Azure Platform, the 3-tier design is in fact very much applicable. The Windows Azure design pattern employs Web Role as a front-end to process incoming requests as quickly as possible, while Worker Role as a middle-tier to do most of the heavy lifting, namely execute business logic against application data. The communications between Web Role and Worker Role is with Windows Azure Queue and detailed elsewhere.
With Visual Studio and Windows Azure SDK, the process of developing a Windows Azure application is highly transparent to that of an on-premise application. And the steps to publish a Visual Studio cloud project are amazingly simple to simply uploading two files to Windows Azure Platform Management Portal. The two files are generated when publishing an intended cloud project in Visual Studio. They are a zipped package of application code and a configuration file with cspkg and cscfg file extensions, respectively. The publishing process can be further hardened with certificate for higher security.
Compared with on-premises computing, there are noticeable constraints when deploying application to cloud including:
These constraints are related to enabling system management of resource pooling and elasticity which are part of the essential characteristics of cloud computing.
Two important features, high availability and fault tolerance, are automatically provided by Windows Azure. Which can significantly reduce the TCO of an application deployed to cloud compared with that of an on-premises deployment. Here, details of how Windows Azure achieves automatic high availability and fault tolerance are not included. A discussion of this topic is already scheduled to be published in my upcoming blog post. Stay tuned.
An Emerging Application Architecture
With Windows Azure Connect, to integrate and extend a 3-tire on-premises deployment to cloud is now relatively easy to do. As part of Microsoft PaaS offering, Windows Azure Connect automatically configures IPSec connectivity to securely connect Windows Azure role instances with on-premises resources, as indicated by the dotted lines in the following schematic. Notice that those role instances and on-premises computers to be connected are first grouped. And all members in a group are exposed as a whole and at the group level the connectivity is established. With IPSec in place, a Windows Azure role instance can join and be part of an Active Directory in private network. Namely, server and domain isolation with Windows Authentication and group polices can now be applied to cloud computing resources without significant changes of the underlying application architecture. In other words, Windows security model and system management in a managed environment can now seamlessly include cloud resources, which essentially makes many IT practices and solutions directly applicable to cloud with minimal changes.
With the introduction of cloud computing, an emerging application architecture is a hybrid model with a combination of components deployed to cloud and on-premises. With Windows Azure Connect, cloud computing can simply be par of and does not necessarily encompass an entire application architecture. This allows IT to take advantages of what Windows Azure Platform is offering like automatic load balancing and high availability by migrating selected resources to cloud, as indicated with the dotted lines in the above schematic, while managing all resources of an application with consistent security model and domain policies. Either the front-end of an application is in cloud or on premises, the middle-tier and the back-end can be a combination of resources with cloud computing and on-premises deployment.
Start Now and Be What’s The Next
With Windows Azure Connect, both cloud and on-premises resources are within reach to each other. For IT pros, this reveals a strategic and urgent need to convert existing on-premise computing into a cloud-ready and cloud-friendly environment. This means, if not already, to start building hardware and software inventories, automating and optimizing existing procedures and operations, standardizing authentication provider, implementing PKI, providing federated identity, etc. The technologies are all here already and solutions readily available. For those feeling Windows Azure Platform is foreign and remote, I highly recommend familiarizing yourselves with Windows Azure before everybody else does. Use the promotion code, DPEA01 to get a free Azure Pass without credit card information. And make the first step of upgrading your skills with cloud computing and welcome the exciting opportunities presented to you.
Having an option to get the best of both cloud computing and on-premises deployment and not forced to choose one or the other is a great feeling. It’s like… dancing down the street with a cloud at your feet. And I say that’s amore.
<Back to Part 1: Concept>
Personally, I see Windows Azure Connect is a killer app to facilitate the adoption of cloud computing. For all IT pros, this is where we take off and reach out to the sky while dancing down the street with a cloud at our feet. And that’s amore.
What It Is
To simply put, Windows Azure Connect offers IPSec connectivity between Windows Azure role instances in public cloud and computers and virtual machines deployed in a private network as shown below.
Why It Matters
The IPSec connectivity provided by Windows Azure Connect enables enterprise IT to relatively easily establish trust between on-premises resources and Windows Azure role instances. A Windows Azure role instance can now join and be part of an Active Directory domain. In other words, a domain-joined role instance will then be part of a defense-in-depth strategy, included in a domain isolation, and subjected to the same name resolution, authentication scheme, and domain policies with other domain members as depicted in the following schematic.
In Windows Azure Platform AppFabric (AppFabric), there is also the so-called Service Bus offering connectivity options for Windows Communication Foundation (WCF) and other service endpoints. Both Windows Azure Connect and AppFabric are very exciting features and different approaches for distributed applications to establish connectivity with intended resources. In a simplistic view, Windows Azure Connect is set at a box-level and more relevant to sys-admin operations and settings, while Service Bus is a programmatic approach in a Windows Azure application and with more control on what and how to connect.
A Clear Cloudy Day Ahead
Ultimately, Windows Azure Connect offers a cloud application a secure integration point with private network resources. At the same time, for on-premises computing Windows Azure Connect extends resources securely to public cloud. Both introduce many opportunities and interesting scenarios in a hybrid model where cloud computing and on-premises deployment together form an enterprise IT. The infrastructure significance and operation complexities at various levels in a hybrid model enabled by Windows Azure Connect bring excitements and many challenges to IT pros. What a great development in cloud computing. And I realize there’s indeed a place in the world for a gambler and where skies are blue and dreams do come true.
<Next to Part 2: Application Integration/Migration Model>