VMworld 2010 Session Content Part 2 - Internal vs. External Cloud

Per my previous post, this is part 2 of a series of posts to provide the content of my recent VMworld technical session.

As I said in my previous post, the impending data explosion will produce huge challenges for the Oracle database community, in that the amount of scaling of Oracle database environments will an order of magnitude greater than the overall data explosion. My unofficial estimate is approximately a 200X increase in data volume managed by Oracle in the next 10 years (as opposed to about 44X overall). This creates the challenge of figuring out how to scale Oracle database environments in order to handle all of that data (as well as the transactional I/O that accompanies it).

In my view, there are two competing ways of scaling an IT workload presently, from a strictly structural standpoint: The external cloud and the internal cloud. (I will further break down the options on the internal cloud in my next post.)

The following diagram gives some insight in what I am talking about here:

 
Those of you who know me well know how fond I am of this type of diagram: The so-called "magic" diagram. Here the vertical dimension represents virtual vs. physical and the horizontal represents internal vs. external (from the perspective of the customer data center). A typical multi-layered application environment is shown with three layers: Web, App and Database. As is typical with most environments, the entire workload starts out in the customer's data center. Further, there is ratio of 9:3:1 for Web vs. App vs. Database. This is somewhat contrived, but fairly typical and real-world in my opinion. Thus, the initial workload when originally deployed looks like this:

For a while, the capacity of internal data center is able to handle the growth in this workload. I call this the period of normal growth. At the end of this period, the web server farm is beginning to exceed the capacity of the traditional data center. This looks like this:

At this point, the customer has a decision: They can either move the web server farm into the cloud, or they can move it out to a traditional external service provider (i.e. co-host location). Perhaps a progressive or farsighted customer would go ahead and move into the cloud. But most folks in my experience have not done so. Instead, they go through a period of scaling where the web server farm is located on a service provider's data center, and then continue to scale the rest of the workload internally. This enables the second period which I call accelerated growth. At the end of this period, the workload looks like this:

Growth has now become somewhat unmanageable. You can see that the co-location model is breaking down. Also, the capacity of the internal data center to absorb the App server farm is now being stressed. Again, the customer has to make some hard decisions. The easiest decision is to move the Web layer into the external cloud. This is easy, cost effective and very mainstream. The App server farm may be either moved into an external or internal cloud, or possibly moved out to the co-location facility. We will assume the latter.

At this point the customer begins the final period of growth, which I call explosive growth. The external cloud provides virtually infinite growth capacity for the Web server layer, but the co-location in an external service provider can now no longer handle the demands of the App server layer. And, finally, the Database server layer is now exceeding the capacity of the internal data center. At this point, the workload looks like this:

Another doubling of the workload, and the customer will be in big trouble. Hard decisions must be made. It is likely at this point that the customer will move the App server layer into the external cloud. Doing so is now fairly mainstream. The decision remains of what to do with the Database server layer.

Understand that I have personally engaged in these discussions with many customers. I think I know the mind of the DBA (as I have been one for many years). Most DBAs when confronted with this choice will make the following calculation:

Am I going to put my precious database, my business's crown jewels, which contain the source data of the business, our very lifeblood, into the hands of an external cloud provider, in what is certainly a very unstable and emerging technology space?

The answer for most DBAs is: No way! Thus, the decision is typically that the scaling of the database layer will be handled as an internal cloud. Many large customers are today launching exactly this type of project which goes by many names, but which is ultimately the idea of creating a Database as a Service (DBaaS) offering which is managed entirely by internal IT. Thus, the final evolution of our example looks like this:

The essence of the internal database cloud is the idea that we divorce the physical database server from any particular project. Rather, database access is provided as a utility service at a cost. The customers (internal IT projects in this case) contract with IT to have this provided. The billing may be on physical storage, transactional I/O, or some other measurement. But the effect is the same. The challenge for DBAs, system administrators, and storage administrators is to provide this service cost-effectively and reliably. But the payoff is huge. Only by providing this type of offering can the customer have any hope of scaling the workload in a period of explosive growth.

My next post will provide a breakdown of the approaches to creating an internal Oracle database cloud, and the choices that customers are making in that regard.

Finally, please remember that I will be at Oracle OpenWorld which is only a couple of weeks away. Please join me in the EMC booth, and I hope to see you there.

Comments

[Jonas Irwin]

Very interesting take on where things are going. I've thought about this too and, like you've suggested here, the story always starts to fall apart when the I get to the idea of co-locating or moving the database layer out to an external provider.

With the way you've mapped things out here, wouldn't latency between the external provider and the internal database cloud become a big issue? Does such a model suggest metro level locality between the various application tiers? Perhaps some kind of a database caching mechanism at the external cloud provider would make sense?

I haven't seen a customer acctually do something like this yet - either everything is hosted in one place or they use platform as a service offering that provide a sort of generic (usually open source based) database service.