At a recent meeting of the NYC/NJ Windows Azure Users Group I presented on the subject of Moving Applications to Windows Azure. At the end of the presentation I had a slide that covered potential Showstoppers that might prevent moving applications to Windows Azure and we discussed how to get around them. Some of these were:
- Fear of change/risk
- Security of data in transit, at rest & in use
- Regulatory impediments (SOX, HIPAA, PCI, etc.)
- Trans-border data issues
- Coupling to other internal systems
- Single-tenancy design of existing on-premises applications
- Unpredictability of costs caused by the OpEx model
Not everything has to be moved to Windows Azure!
First of all, let me shock you by stating that I do not believe that everything has to be, or should be, moved the the Cloud. 
There are strong reasons why some applications cannot be so moved. Even in those cases however there may be advantage to moving some application components into the cloud while keeping some application components safety behind the firewall. In the previous posts in this series I discussed a methodology for selecting applications to move to Windows Azure. I stated in those posts that the methodology was only a first level approximation to a decision process that could get you started in the evaluation and planning process.
We started the first post in the series by applying the decision process to your application portfolio to determine applications that are Fit For the Cloud. You will remember that we discussed typical application characteristics to look for. That post talked about doing this on a whole application basis. As a first level approximation that might be good to determine the low hanging fruit applications that could benefit from a complete move. Even in those cases where that is not an option it may still be the case that there may be benefit in moving some application components.
For instance: Lets take the case of an eCommerce site. Making your product catalog widely available by publishing it in the cloud would seem to be a no-brainer. That would give you maximum reach and scalability. On the other hand credit card processing might have to reside safely behind the firewall or in the hands of a third-party credit card service provider. (Or maybe not. There are other interesting potential solutions to this problem.) The same decision process could be applied to your Shopping Cart and other application components. My point here is to think at a more granular level and place application components where they will do you the most good.
Window Azure supports these Hybrid architectures in many ways. You can build distributed applications involving Cloud and data center resident components using basic PaaS Compute Services such as Windows Azure Web and Worker Roles, PaaS Data Services such as Windows Azure Blobs, Tables, Queues and Drives as well as other PaaS services such as the Windows Azure Service Bus (which allows you to integrate cloud-based resources with other resources behind the firewall), Access Control Service (which provides a secure token service in the cloud that can be used to federate Windows Azure security with other claims-based security providers), and SQL Data Sync (which allows you to synchronize on-premise SQL Server databases with in-the-cloud Windows Azure SQL Databases) and other very useful Windows Azure PaaS services.
You can also mix and match PaaS services such as those above with the newer IaaS features such as Windows Azure Virtual Machines, Virtual Networks and other IaaS services that even let you operate as if your cloud storage and compute components were located in a “branch office” in Windows Azure, complete with a Cloud extension of your own Active Directory domain.
To reiterate, Not everything has to be, or should be, moved the Cloud. In fact most of the interesting enterprise level applications in the foreseeable future will be of this Hybrid nature. The Cloud just represents a deployment option for some or all application components. Use it where it makes good business and architectural sense.
With that positioning out of the way lets talk about some of those Showstopper.
Fear of change/risk
When I was at a previous company we used to joke about being in the “payroll continuation program” No-one wants to loose their job by taking unnecessary risks. However, talking prudent risks in the pursuit of business objectives should be what your job is all about. To be blunt, those companies that do not pursue new technologies and new ways of doing business run the risk of being left behind by their competitors. Witness what has been happening in the brick and mortar retail store world, video rental world, the publishing industry and others impacted severely by newer technologies such as the Internet and Mobile Computing. (My high school motto was “He who does not advance falls behind”. Enough said.)
There are ways to take prudent risks where the cloud is Concerned. And you should be exploring them if your business is to stay relevant. A very simple process flow for getting into the Cloud safely is described below. In a way it is sort of a Cloud maturity Model.
Another thing that I recommend highly is a paper that I co-authored while at Microsoft on the Software as a Service System Development Life Cycle which addresses IT as a service and how to modify the standard SDLC methodology when approaching your first (or subsequent) Cloud opportunity.
Proceed cautiously, but proceed.
Security of data in transit, at rest & in use
Some companies blatantly refuse to allow use of the Cloud in any form. Even those companies however probably do not do their own payroll processing , preferring instead to utilize the service of a “cloud service provider” such as ADP. So in effect they are using “The Cloud” in some way whether they realize it or not.
Once past the blind “No Cloud here”mandate we can look at where Security issues exist and how to mitigate them in order to take advantage of the Cloud.
Security is a matter of providing data security while data is in transit (normally over the Internet), at rest (usually in cloud storage) as well as in use (while being processed in the cloud). Let me state that I am not a security expert but I do know that there are potential ways to insure the security of your data in all three modes.
Data in transit can be, and normally is, secured by SSL/TLS protocols involving Public/Private key encryption.
Securing data at rest is a matter of either encrypting or tokenizing data such that no personally identifiable information, credit card data, or other sensitive data is at risk.
Securing data in use is concerned with not exposing that data while it is being processed. That is a bit harder but still there are still ways, for instance, to search and compare encrypted data items without actually decrypting them.
So do not give up on the Cloud just because you are concerned about Security. Of course you need to proceed cautiously. In the final analysis where Security turns out to be a real showstopper you may still be able to resort to a Hybrid design that keeps the sensitive data behind the firewall while still taking advantage of the Cloud.
Let me close this discussion with a reference to the Windows Azure Trust Center that will tell you pretty much everything that you need to know about Windows Azure where Security, Privacy, Compliance and Trust are concerned. The Compliance section also addresses the following Showstopper as well.
Regulatory impediments (SOX, HIPAA, PCI, etc.)
It is a fact that regulatory agencies always seem to be living in a previous generation. When computers first took off regulations were mostly focused on paper record keeping. Now that the Cloud is upon us regulations, in most cases, have not yet caught up with the Cloud.
Cloud security is a shared responsibility between the cloud service provider and its customers. The Windows Azure trust Center Compliance section (mentioned above) addresses these issues and their current status. The current state of Windows Azure certification (from the Trust Center) is explained in the following table.
If you are in the Healthcare industry and are concerned about HIPAA Compliance in particular I highly recommend this white paper from Sogeti USA, Inc. that discusses how to build HIPAA compliant applications on Windows Azure.
Recently the Cloud Special Interest Group of the PCI Security Standards Council also issued a new PCI Data Security Standard (PCI DSS) covering the Cloud.
Compliant solutions do exist, but need to be investigated carefully as regulations and certifications are still in a state of change.
Trans-border data issues
Many countries have strict restrictions about Data Sovereignty. In many cases refusing to allow data to be stored in other countries and/or to flow across international boundaries. Although these restrictions seem to be decreasing they are still a factor. Windows Azure supports Data Sovereignty by allowing you to control the geographic location where your resources are located.
Coupling to other internal systems
One factor that may work against moving an application to the cloud is the case where there are a lot of inter-system interfaces between the application in question and the other systems in your company. While a bad idea in general this often occurs in practice. Some re-engineering of existing applications to minimize those interfaces may be required. In some cases building a Façade or gateway that reduces the number of interfaces between on-premises and cloud components may be possible.
Single Tenancy design of existing on-premises applications
In the case of moving an application to the cloud one requirement that often comes up is the need to take a single-tenant application that is normally installed in a single customer’s data center and turn it into a service that can then be sold to multiple tenants. There are, of course, multiple ways to do that and a full treatment is beyond the scope of this blog post. A lot depends upon the existing architecture of the application and it’s data. There are three tenancy architectures that can work:
Single copy of the application per Tenant
This is the case where we have an existing legacy applications and we decide to install a cloud resident version of the application and its data for each tenant/customer. This may seem to be an easy approach but often leads to changes in the codebase to accommodate individual tenant and can lead to having to maintain different versions of code for different customers.
Similar considerations exist on the data base and data storage side of things. Having multiple data bases per tenant seems simple but can lead to exorbitant costs as the number of tenants increases. This is not really a very scalable solution.
Multi-Tenant with a common data schema
In those cases where a single user interface can be used to support all tenants you still have to worry about whether there are any application, storage or database customization requirements on a per-tenant basis. (The need to provide different user interface branding for different tenants, called White-Labeling, brings with it a whole additional aspect of complexity. You may have to resort to more dynamically and perhaps database driven creation of your user interface to support that as we did on one project that we worked on.) In many cases per-tenant customization can be accommodated by adding a Tennant-ID to database tables and perhaps adding some extra user definable fields to the schema to account for minor customization requirements.
Multi-Tenant with separate custom schemas.
If conversion of the application and data require major customization capability you may have to bite the bullet and have a different schema for each tenant. This could be separate tables in the same database or even separate databases.
Azure Specific Database Scalability considerations
Windows Azure SQL Database is a Microsoft managed SQL Server database as a service offering (DBaaS?) that can be used for relational storage in Windows Azure. It is highly compatible with on-premises SQL Server and so it provides a streamlined migration path for moving an on-premises application to the cloud.
All of the multi-tenancy discussion above is relevant to this service. One limitation of Windows Azure SQL Database, however, is that it currently has an upper per-database size limit of 150 GB. Even in the case where you can share a single database between all your tenants, as discussed above, improved scalability can be gained by spreading your tenants across multiple physical databases. At one end of the spectrum you have the very expensive solution of one database per tenant. At the other end you can have a single shared database for all tenants. The latter limits your upper scalability limit to 105GB.
Both of these approaches have drawbacks. There is a middle ground called Database Sharding, as implemented in Windows Azure by Microsoft with their Federations feature. It can be used to spread all your tenants across a smaller number of SQL Azure Databases and handle some of the mechanics of accessing and maintaining that configuration.
Refer to Federations in Windows Azure SQL Database for a more detailed treatment of this this subject.
And for more detailed coverage of the subject of Windows Azure Multi-Tenancy you should read the Microsoft Patterns & Practices group blue book: Developing Multi-Tenant Applications for the Cloud.
Unpredictability of costs caused by OpEx model
One of the great features of leveraging the Cloud is that you are no longer required to determine your capacity requirements up-front in order to acquire adequate server, data storage and network resources. As we discussed in Part 1 of this series this pay-as-you-go model is one of the strengths of the OpEx model as opposed to the classical CapEx model where you are required to budget for the high-water mark of your capacity requirements. This very advantage, however, can also prove a disadvantage to corporate executives that want to know in advance what your IT costs will be.
The answer is that, despite the change in models, you are still required to do capacity planning and budgeting. What OpEx gives you is more flexibility to handle unexpected situations and be more responsive when requirements change (either up or down) in an unexpected manner. In particular the scale-down capability, when requirements decrease, is particularly advantageous to save money when capacity requirements decrease temporarily.
Summary
In summary, not everything has to be moved to Windows Azure! The Cloud just represents a deployment option for some or all application components. Use it where it makes good business and architectural sense. Take prudent business risks and proceed cautiously, but don’t get left behind by your competitors.
Bill Zack
Contact me via Email: wzack@live.com
Visit my Blog: Cloudy In New York
Visit me on LinkedIn
Follow me on twitter: @WilliamHZack
Call me at 203 545-2339 (mobile)
) I will continue to post there about “Clouds in General and Windows Azure in Particular” as the masthead says.
) was “Use SaaS if you can… else use PaaS if you can… else IaaS (the last resort!)“
) 
) and I recently did another (updated) version for the New York City Code Camp run by the New York City .NET Developers Group (of which I am also one of the leaders).
) 
Cloudy In New York 