The age of cloud computing is fast approaching. Or at least that's what the numerous vendors of cloud computing would have you believe. The challenge that you (and all developers) face is to determine just what cloud computing is and how you should take advantage of it. Not to mention whether you even should take advantage of it.
While there is little agreement on exactly what constitutes 'cloud computing', there is a consensus that the technology is a paradigm shift for developers. And like pretty much every paradigm shift there is going to be some hype involved. People will recommend moving immediately to the technology en masse. People will suggest that cloud computing has the ability to solve all that is wrong with your Web site. Not surprisingly, neither of these statements is true.
And, as with many other paradigm shifts, the reality is less impactful and slower to arrive than the hype would have you believe. So before you start down this supposedly obvious ‘path to the future of computing’, it's important to have a good sense of what the gains will be. Let's consider some of the benefits that cloud computing offers.
Instant Scalability
If you are tasked with building a customer-facing Web site, then one of the main concerns is scalability. Regardless of the type of site being created, there will be considerable intellectual energy spent determining how to configure the Web servers to maximize the up-time. And in many cases the infrastructure design must also consider issues not related solely to reliability. The ability to handle peak times, which can be a large multiple of the normal level of activity, must also be designed into the architecture.
These spikes in usage come in a couple of different varieties. Sometimes, the spikes come at predictable times. Think of the holiday season for a retail site or a price sale for a travel site. Sometimes the spikes cannot be predetermined, such as a breaking news event for a current events site. But regardless of the type of spikes, the infrastructure architect must create an infrastructure that is capable of absorbing these variations in stride. The result, especially if the peak is 10 times or higher than the average load, is that extra (and mostly unused) capacity must be built into the design. Capacity that must be paid for, yet remains idle.
Into this picture comes cloud computing. Regardless of the cloud platform for which you develop, the ability to scale up and down with the click of a mouse is readily available. For Windows Azure, there are a number of different scalability points, including the number of virtual machines assigned to the application, the number of CPUs in each of the virtual machines, and so on. Within the application itself, you as the designer would have already partitioned the application into the various roles that are then deployed onto the virtual machines.
As the demand on the Web site increases, additional machines, CPUs or roles can be added to ensure a consistency of responsiveness through all of the loads. More importantly, when demand decreases, the resources can be removed. Since these settings form the basis for price paid for the cloud computing service, companies will end up paying only for the capacity that they require.
The price to be paid for this flexibility is that mostly that the application needs to be designed with the necessary roles in mind. As well, there are other constructs (such as the AppFabric and the ServiceBus) and technologies (such as WCF) that need to be mastered and integrated into the application. As a result, it is easier to build a Web application that works with Windows Azure right from the start. This is not to say that existing Web applications can’t be refactored to take advantage of the cloud…they certainly can. But starting from scratch allows you to take full advantage of the benefits offered by Azure.
Expandable Storage
The ability to avoid idle resources is not the only appeal of cloud computing. Another resource that can be virtualized for most applications is the database. Just like the CPU, database usage can rise and fall with the whims and patterns of the user base. And the fact is that the vast majority of business databases do little more that grow in size as time goes one. Again, infrastructure architects need to consider both growth rate and usage patterns as they allocate resources to the database servers. As with the machine-level resources, over-capacity must be designed into the architecture. By using a database hosted in the cloud, the allocation of disk space and processing power can be modified on an as-needed basis. And you, as the consumer, pay only for the space and power that you use.
There are some additional thoughts that need to be given to the use of a cloud database. In order to provide the described flexibility, cloud database providers freely move data from one server to another. As a result, there must be a fairly high level of trust in the provider, particularly if the data is sensitive in nature. For the traditional non-cloud database, the owner of the Web site maintains physical control over the data (by virtue of their physical control over the database servers). Even if the server is hosted at a co-location facility, the Web site owner ‘knows’ where the data is at all times.
When the data is persisted to the cloud, however, this is no longer the case. Now the data is physically in control of the cloud provider. The owner has no idea on which server the data is stored. Or even, when you get right down to it, which city. For some companies, this is a level of trust well beyond what they might have been comfortable with in the past.
As a person who lives abroad, (I’m from Canada), there is one more consideration: privacy. Data privacy laws vary from country to country. When data is stored ‘in the cloud’, there is little weight given to the physical location of the data. After all, the actual location has been virtualized out through the cloud concept. Information can (and does) move across national boundaries based on the requirements of the application. And when data resides in another country, it may very well be subject to the privacy laws of that country. If those laws are significantly different than your own, you might need to modify your corporate policies or the Web application itself to address whichever requirements are more stringent. This sort of situation brings rise to a common approach to cloud storage – data segregation.
In data segregation, the data required by the Web application is stored in multiple locations. Data that is static and/or not particularly sensitive is stored in the cloud. Data that is sensitive is stored in a traditional (and more subject to owner control) location. Naturally, the Web application needs to be structured to combine the data from the different sources. And the traditionally located data needs to be stored in an infrastructure that is reliable and scalable…with all of the problems that the implementation of those features entail.
The functionality offered by cloud computing will be enticing to some, but definitely not all, Web sites. For those who fit the target audience (Web sites that have a wide fluctuation in usage patterns) or just those who want to outsource their Internet infrastructure, cloud computing is definitely appealing. For developers of these sites, platforms such as Windows Azure represents a significant change in the necessary development techniques. And even with the inherent complexity, the shift to cloud computing is beneficial to developers (the resulting applications tend to be more modular, composable and testable), enough to make further exploration of the details worthwhile.