Layered Architecture: Deploying to Windows Azure

With the arrival of cloud computing, we may wonder whether the Layered Architecture Pattern would still be relevant. In theory, everything should work as-is if we are leveraging on Infrastructure-as-a-Service (IaaS) because that only involves moving our servers to the cloud, but what about Platform-as-a-Service (PaaS)?

Well, I'm glad to learn that Windows Azure provides a variety of deployment options for enterprise layered applications (provided if the applications were properly layered on-premise).
      [Note:] If you find the text in the diagrams too small, please refer to my previous post for a larger illustration.

      PaaS - Windows Azure Web Sites and Cloud Services

      For new or enterprise applications that can be migrated completely to use the PaaS model, we can leverage on Windows Azure Cloud Services which offer us the options of deploying Web Roles and Worker Roles. Web applications containing the presentation layer can be deployed to Web Roles and the back-end stack containing the service, business and data layers, can be deployed to either Web or Worker roles.


      If the service layer was developed in WCF or WEB API, the back-end stack can be deployed to a Web Role. It is not necessary for the back-end stack to be using Worker Roles unless necessary.

      Web applications can also be deployed to Azure Web Sites if they are simple pages but I would recommend using Web Roles instead because they are more suited for application environment (i.e. network isolation, setting up start-up tasks, support for virtual networks, multi-deployment environments and etc).

      As for the database portion, some rethinking is required. The notion of database clusters is somewhat non existence in a PaaS model and instead, PaaS uses the concept of replicas for sustaining high-availability. Also, large databases may need to be shredded (horizontal partitioned) in to smaller databases and later use Federation to query them.

      Iaas - Windows Azure Virtual Network and Virtual Machines

      For existing layered applications that could not be migrated to the PaaS model, Windows Azure also provides IaaS options through Virtual Network and Virtual Machines. Similar to an on-premise environment; web, application and database servers can be virtualized into Virtual Machines and then configured within a Virtual Network on Windows Azure.


      Notice that we are able to setup database clusters for high-availability in IaaS but unlike PaaS, the tasks and responsibilities of setting up all the servers (Web, App and DB) are on us.

      Organizations may consider the IaaS model to reduce the risk of migrating applications to the cloud as it closely resembles the architecture of existing on-premise infrastructures. It is also a good option for quickly provisioning servers for testing out prototype solutions and applications. Organizations who want to have more control on their servers will also find IaaS more suitable for their liking.

      Paas and Iaas Working Together

      Windows Azure do not limit us to an all-or-nothing option when it comes to deploying applications. Through layering we can leverage on one of its benefits whereby each layer can be developed, migrated and upgraded separately from the others. In this case, we can have scenarios where our web application are migrated to an Azure Web Site or Web Role, while the back-end stack can be hosted on Virtual Machines in a Virtual Network.


      The use of Azure Web Site or Web Roles will surface some differences here. With Web Roles, your web application will be able to join the Virtual Network of the VMs. The Web Sites can only call the App server from external endpoints that we need to configure.

      Hybrid On-Premise and Cloud

      In all enterprises, there will be applications that cannot be migrated to the cloud. This can be due to governing policies, readiness or even the need to support for legacy systems. In such situations, all hopes are not lost as Windows Azure also provides the ability to connect on-premise applications to the cloud.

      A common method may be to deploy certain servers to Virtual Machines in an Azure Virtual Network and then configure VPN to connect back to the on-premise environment. Windows Azure provides Site-to-Site and Point-to-Site VPN connectivity for this purpose.

      However, if the applications are properly layered, we can actually leverage on Azure Service Bus to expose any on-premise service stack to the cloud.


      Service Bus can be used to expose any on-premise services to other external systems (i.e. partner extranets) that are either hosted on other premises or on the cloud. It can also be used to expose services to mobile applications. You can secure your Service Bus endpoints using Access Control Service.

      Summary

      As we can see, the Layered Architecture Pattern stays relevant despite the emergence of cloud computing. In fact, having a carefully layered design may assist in easing the migration to the cloud. Even, if you are not developing applications for the cloud today, I would still strongly encourage you to consider layering your applications.

      Arguably, we can still deploy monolithic web applications (everything in a server) to the cloud and abuse use the elastic scaling capabilities of the cloud by throwing in more instances but that will not provide us with the option to provide isolation and perform granular tuning or scaling i.e. 4 Web server instances serving content and 2 App server instances processing logic.

      You can check-out samples of layered applications developed for Windows Azure in Layered Architecture Sample for Azure.

      This the third article in the series of exploring the layered architecture pattern in modern systems. You can check out other posts in the series:

      No comments:

      Post a Comment

      Popular Post