The Cloud Holy Grail

I went to the Oracle Enterprise Architects Club yesterday which was titled Enterprise Cloud: Hype or Reality, with talks from 3 perspectives: Customer (I have a private Cloud), Partner (I build and run Public/Private Clouds for customers), and Oracle (We have a full stack to deliver PAAS).

It helped me clear up in my own mind that the Cloud is really only a cloud to the consumer. To the cloud provider, it is not cloudy at all, but a very specific set of scoped services delivered by a H/W and S/W stack. i.e. The consumer does not need to know how or what sits inside the cloud, simply that it delivers a reliable service using self-service provisioning with predictable and transparent pricing.

It is the job of the Cloud provider to build an infrastructure that supports the user expectation of a Cloud service. For some reason Cloud architectures seem to immediately become a VMWare sales guy's dream. The definition of Cloud as a set of systemic qualities by its nature has no specification for HOW that could be delivered, and there are countless ways of building a technology stack that delivers Cloud services. I think I could make a strong case for a Cloud Infrastructure being composed of a pair of clustered M9000-64s with thousands of Solaris Containers connected to an array of S7410s.  It would exhibit the same systemic qualities as any of the other cloud architectures out there.

The point is, the technology stack bit is easy, and your architectural choice is about where you want the orchestration of multi-tenancy to live. In the middleware layer with a Weblogic grid? In the DB layer with an Oracle RAC grid? In the O/S layer with Solaris Containers? Or in the Server layer with OVM? My answer? All of the above. Doing ONLY the last is hugely inefficient. Having an agile and efficient infrastructure is key to minimising your running costs.

The 2 hard parts are self-service and billing. In the IAAS and SAAS worlds, the delivered service is sufficiently constrained to make this solvable.

The self-service delivery of PAAS requires a much more rich and complex set of interfaces for the user to be able to articulate and deploy the required "service". This could be simplified by providing pre-configured models and simply allowing the customer to select the ones they want. 

The HARDEST part of delivering PAAS is the cost model. This is simple economics: The cloud provider has an investment in infrastructure that needs to be paid for over its lifetime, and has running costs that tend to be relatively stable whether customers are using the service or not. The cloud provider has to provide a commercial proposition to the customer that delivers the service cheaper than if the customer did it himself, while still being able to cover his costs and make a profit.  Obviously in the IAAS world I can simply charge per allocated resource, and in the SAAS world I can simply charge per transaction or per user. What is the PAAS model? Transaction? Resource? User? A combination of them all? Do I need to have a reservation charge as well as a usage charge? How does/can the customer compare the cloud cost against his own? 

The solution to the PAAS billing problem? Make it a Private Cloud and you can skip the billing piece. :-)

In summary, the Holy Grail of PAAS is to come up with a commercial model that allows customers to use the service at a lower cost while still allowing the Cloud provider to make a profit. When someone comes up with an answer, please let me know. 



In terms of the solution to the PAAS billing problem, you still run into how the PAAS is viewed - is it a cost center or a profit center? In many instances, this becomes a transfer cost to the internal customer, which is still a part of the overall company/organization. I've seen projects have to allocate X% cost to paying for the internal PAAS service (i.e. 8 man hours per month at $100+ per hour OR 5% of total project budget). In this case, they simply pass along that billing to the true end customer such as the Federal government that hires a consulting company that has their own Private Cloud for testing and development purposes. I kind of like this model to some extent as it does allow the consulting company to improve their own internal service provisioning and still recoup some of the cost by billing customers via a standard project budget. Down the road, it becomes cheaper to develop and test systems and hopefully these savings are passed along as well.

Posted by Colin Stevenson on June 27, 2010 at 06:52 PM BST #

Post a Comment:
Comments are closed for this entry.



« January 2017