We have talked about a number of the technologies that make up cloud computing and the general value proposition behind the cloud. Before we move into building systems in the cloud, we should take a moment to understand a variety of cloud infrastructure models. I will spend the most time on the one most people will be working with, Amazon Web Services. But I also touch on a few of the other options.
It would be easy to contrast these services if there were fine dividing lines among them, but instead, they represent a continuum from managed services through something people call Infrastructure as a Service (IaaS) to Platform as a Service (PaaS).
PaaS environments provide you with an infrastructure as well as complete operational and development environments for the deployment of your applications. You program using the vendor’s specific application development platform and let the vendor worry about all deployment details.
The most commonly used example of pure PaaS is Google App Engine. To leverage Google App Engine, you write your applications in Python against Google’s development frameworks with tools for using the Google filesystem and data repositories. This approach works well for applications that must be deployed rapidly and don’t have significant integration requirements.
The downside to the PaaS approach is vendor lock-in. With Google, for example, you must write your applications in the Python programming language to Google-specific APIs. Python is a wonderful programming language—in fact, my favorite—but it isn’t a core competency of most development teams. Even if you have the Python skills on staff, you still must contend with the fact that your Google App Engine application may only ever work well inside Google’s infrastructure.
The focus of this book is the idea of IaaS. I spend a lot of time in this book using examples from the major player in this environment, Amazon Web Services. A number of significant AWS competitors exist who have different takes on the IaaS problem. These different approaches have key value propositions for different kinds of cloud customers.
AWS is based on pure virtualization. Amazon owns all the hardware and controls the network infrastructure, and you own everything from the guest operating system up. You request virtual instances on-demand and let them go when you are done. Amazon sees one of its key benefits is a commitment to not overcommitting resources to virtualization.
AppNexus represents a different approach to this problem. As with AWS, AppNexus enables you to gain access to servers on demand. AppNexus, however, provides dedicated servers with virtualization on top. You have the confidence in knowing that your applications are not fighting with anyone else for resources and that you can meet any requirements that demand full control over all physical server resources.
Hybrid computing takes advantage of both worlds, offering virtualization where appropriate and dedicated hardware where appropriate. In addition, most hybrid vendors such as Rackspace and GoGrid base their model on the idea that people still want a traditional data center—they just want it in the cloud.
As we examine later in this book, there are a number of reasons why a purely virtualized solution might not work for you:
Regulatory requirements that demand certain functions operate on dedicated hardware
Performance requirements—particularly in the area of I/O—that will not support portions of your application
Integration points with legacy systems that may lack any kind of web integration strategy
A cloud approach tied more closely to physical hardware may meet your needs in such cases.
I am not a great fan of the term private clouds, but it is something you will often hear in reference to on-demand virtualized environments in internally managed data centers. In a private cloud, an organization sets up a virtualization environment on its own servers, either in its own data centers or in those of a managed services provider. This structure is useful for companies that either have significant existing IT investments or feel they absolutely must have total control over every aspect of their infrastructure.
The key advantage of private clouds is control. You retain full control over your infrastructure, but you also gain all of the advantages of virtualization. The reason I am not a fan of the term “private cloud” is simply that, based on the criteria I defined earlier in this chapter, I don’t see a private cloud as a true cloud service. In particular, it lacks the freedom from capital investment and the virtually unlimited flexibility of cloud computing. As James Urquhart noted in his Urquhart on Barriers to Exit, I also believe that private clouds may become an excuse for not moving into the cloud, and could thus put the long-term competitiveness of an organization at risk.
And then there is Microsoft Azure. Microsoft Azure represents all aspects of cloud computing, from private clouds up to PaaS. You write your applications using Microsoft technologies and can deploy them initially in a private cloud and later migrate them to a public cloud. Like Google App Engine, you write applications to a proprietary application development framework. In the case of Azure, however, the framework is based on the more ubiquitous .NET platform and is thus more easily portable across Microsoft environments.