Do your applications have a pCard yet? Given the hopes of some industry people one day they may.
Whats a pCard? pCard is a concept that James Urquhart (Cloud marketing at Cisco and Wisdom of Clouds blogger at CNet) is developing as a means of describing your workload to the Cloud providers.
Here is how James describes it in his CNet post "Payload descriptor for cloud computing: An update" to introduce pCard.
[A] pCard is a calling card for a software payload--whether simple single container payloads, or complex multi-container distributed payloads--that contains the information needed by a service provider to determine
a) if they can meet the needs of the payload, and
b) what kind of services are required to do so (and their costs).Rather than having to deliver the whole payload of the workload you can just deliver the requirements via a pCard to determine if the provider can deliver your requirements.
Here is an idea of the structure which James has proposed.
[image from James Urquhart @ CNet]
The process would be that you send the pCard to a service provider, they process it and respond with the details as to their ability to meet your request. The response could include confirmation of those requirements which can be met and details of those that can not.
I really jumped on this idea as a great one, here is some of my thinking on it.
- Cloud Brokers
This is something that James has not mentioned yet but I am sure he has thought of it as well. Many people are predicting that a natural evolution in the Cloud marketplace is the rise of Cloud Brokers or what some call Cloud Arbitrage. You can read a bit more about these here.
For a Broker to work they need to be able to process in an automated fashion your workload request, pass that to multiple providers and process the results to feed back your options. For this to work you you don't want to be passing the actual work load around. The type and amount of information may be different to the actual work load and you want it to be much smaller. - Security
How much information do you want to give away about your application before setting up a trust relationship with a provider? There are certain items you may not wish to reveal about your application to a list of untrusted parties at this stage of the process. You want to throw out the question, "Hey, I have this workload that looks like this, has these mandatory and these desirable characteristics, can you handle it?" You may get many positive responses but its only after you make a selection that you increase the trust level up a notch to actually start sharing data. - Returned information
In addition to a simple response to the requested attributes I propose that there will be additional information which needs to be returned by the provider, such as financial information or time frames. Therefore more than just acknowledging ability to execute the payload you can find out the cost of running that workload with a time commitment. "Yes we can run that application and its 90c per hour with a minimum of 60 hours and we can commit the resources for up to 30 days." Having a descriptor separate to the workload allows these different types of information exchanges to take place. - cCards
The conversation does not have to be one way. You can imagine a Broker having to send a lot of requests to providers to have pCards processed. Its my idea that there should be an equivalent of the pCard for the provider, call it a cCard for the want of something better. A provide can describe the capabilities of their service in a cCard and this can be loaded into the your system or the brokers. Of course cCards would need expiry information and you would still actually need to send the request to the provider for the final processing. However if there were thousands of providers the broker could quickly filter that list into a sufficient subset based on the matching of data from your pCard and its set of cCards, so that your pCard only needs to be sent onto the relevant providers. For example, if you have a mandated requirement for geographical location of the service there is no point in sending the request to providers who can't provide a service in that geography. - Efficiency
There is lots of effort going into creating a standard for workloads, through OVF, vApp and others. However vendors are always going to try and keep their edge and there is only so much standardization that can be done within the elements that have to actually do the grunt work of the actual workload. Having a separate and lighter construct could make things a lot easier. Certainly a pCard could be generated from the packaged workload or even before its packaged up. You could see an analysis system working through your existing workloads running scenarios of how they could be efficiently restructured, running some ROI scenario,s before any actual work was actually done.
These are certainly some long term concepts that we are contemplating here, but that is where these things start, somewhere. After all, someone had to wake up one day and consider that there should be a standard structure for portable virtual machines.
If you are interested in such things, if you think you may be a large consumer of pCards or if you are a service provider who may want to process and respond to pCards, or if you are a vendor who may need to work with them then I recommend you join in on the discussion on the development of the pCard idea.
James has set up a Google Group with a mailing list and there are a few of us throwing these ideas around. Why don't you visit and give some comments.
You never know, one day our clouds may just be shaking hands whilst they pass pCards around.
Rodos
No comments:
Post a Comment