Cloud Computing Model

Thu. Apr. 10, 2008

Probably the best next step for this discussion is to begin to build a top to bottom model of Cloud Computing.  I think there are about 12 major pieces to it so this is going to take a while.  As I mentioned earlier, “Cloud computing”, I believe, may in fact become the basis for most modern IT services in the next few years.  We also put forth this definition with which most folks seem to agree……“Cloud computing” -  packaging of computing resources in a manner that will provide lower acquisition cost of hardware and in a way that provides a set of optimized services to the end user via the Internet in the most cost effective, operationally efficient means possible.   So I took a stab at the model for this which is shown here:

Capture

At this point it is certainly OK to disagree! …. In fact, I have found myself arguing with myself about it already. :o)  So we’ll pause here and let folks take this in.  Then we will start layer by layer to make sure is correct.  My hope is not only can we build an agreeable model at the technical level, but a financial model from which we can get TCO and other information.  Feel free to comment…

 

del.icio.us email this digg digg
Published Thursday, April 10, 2008 03:04 PM
by Jimmy Pike, Director—System Architecture
Filed under: ,

Comments  Comment RSS Feed

Steve Caughey said:

Jimmy,

good to see an effort to formalise the often nebulous concept of the cloud.

I'm a bit surprised to see that SLA's don't feature in your model until way down in layer 4. Aren't SLA's defined within the schema at level 11? Frequently there's a problem with defining 'service' requirements and then trying to map them down to SLAs associated with physical devices. This potential mismatch is something we've been looking at within Arjuna.

Steve

 

April 14, 2008 4:58 AM
Jimmy Pike, Director—System Architecture said:

Steve,

A great question and comment and is worthy of a good discussion.  I have actually been looking at it a bit differently (perhaps shades of my hardware background peeking out :o) 

 

This view portrays the availability manager very early in the stack (if you will) starting at the physical layer and working your way up.  This idea of this model layer is to deal with a key difference between conventional computing and a cloud’s very “loose” dependence on the physical resource.  By placing it just below the Workload Manager and through interaction with this layer, the direct connect to the hardware is eliminated  (or at least managed) as the said workloads are applied.  (This is very dependent on the “statefulness” of any data used and managed in layer 6, but let’s save that for later.)  You bring up a very good point, and I might add, an excellent opposing view.  From the client or service layer (and in schema you call out in layer 11) the client can be a very heavy participant in the SLA.  I am not sure this is the direction that folks who are becoming “Cloudy”  :o) seem to be heading.   At the very least, it seems that any additional SLA management would be below the presentation layer.  However, you may be on to something as Orchestration as I hope we will define it, is responsible for managing the life cycle of any instance of a service. 

 

Could you be  proposing a more explicit SLA component there and do you have an example of it?  I am very intrigued by your question and the perspective  Arjuna may offer. Can you tells us more?

 

April 16, 2008 9:45 AM
Khaz Sapenov said:

Jim,

Very nice model !

Have you thought about stacking some of the components on same level, so they are parallel and still fit your hierarchy? 

May 2, 2008 11:13 AM
Jimmy Pike, Director—System Architecture said:

Khaz,

Well… I was have to admit, I am heavily influenced by the idea of this OSI model:  (Layer 7: Application layer, Layer 6: Presentation layer, Layer 5: Session layer; Layer 4: Transport layer, Layer 3: Network layer, Layer 2: Data Link layer, Layer 1: Physical layer).  That said is it not obvious where the parallelism you cite exists.  What are you seeing that I am missing?
May 9, 2008 3:29 PM
Charlie Bess said:
Nice model to start a discussion, but I am beginning to think that in this age of SOA and SaaS the whole concept of application may be outdated. If the computing is really an aggregation of services and capability, calling it a services layer may be better. Those services are orchestrated into a function that delivers business value through the interface. Networking must permeate the entire model, since it is cloud based. Security must as well, since it needs to be built in at many levels.You know what they say: "all models are flawed but some are useful"

 

May 8, 2008 2:01 PM
Jimmy Pike, Director—System Architecture said:

Charlie,

Yes, I agree with you that the idea of applications may be an outdated concept, but I didn’t know what else to call it and we need to keep some familiarity and connect to the work being done.  I am open to this however, servers layer seem to lack that idea.   What would you say about something like .. “workload service or application service”?
May 11, 2008 12:25 PM
Steve Caughey said:
Jimmy, Sorry I’ve taken so long to respond but I’ve been on the road for a couple of weeks. The fundamental problem Arjuna is addressing is how service users can specify their service requirements without having to talk about the physical resources which might be used to satisfy those requirements, and the behaviour of those resources. (This is particularly important in the cloud as service users will have no idea of the actual IT used to provide services). Our model is one of interacting peers who are Service Consumers and/or Service Providers. Service Consumers express their requirements purely in terms of the required service and the non-functional qualities of that service e.g. its  availability, reliability, responsiveness etc. Service Providers may choose (guided by Policy) to enter into Service Agreements in which they contract to provide the services and to satisfy the non-functional requirements. Service Providers ensure they meet their Service Agreements by obtaining (including potentially deploying), and maintaining, the necessary resources. These resources might be hardware or software components which the Service Provider has under their direct management, but might also be further services, in which case the Service Provider, acting now as a Service Consumer, interacts with some further Service Provider or Providers. As a consequence the services, and service requirements (or SLAs), which are defined by the originating Service Consumer are decomposed and translated into supporting services, with their own service requirements, potentially through a number of steps. Whilst the original SLAs might talk exclusively about services, once physical resources have been assigned, the SLAs associated with those resources will be expressed in terms of the resources’ behaviour e.g. availability, reliability, responsiveness etc. I guess these lower level SLAs are the ones you are considering in level 4. We’ve written a white paper on our approach which you can read at http://www.arjuna.com/agility I guess our position is somewhat in line with Charlies Bess' comments. 
May 12, 2008 8:18 AM
Chris Marino said:

Jimmy, this isn't working for me.  Sorry.  Seems like a lot of things piled on top of each other without too much regard for what each layer actually provides.  Couldn't you have at least stopped at 11?

May 15, 2008 11:19 PM

Leave a Comment

Compose
Preview
(required ) 
(required , not published) 
(optional )
(required ) 

Note: Conversation is encouraged and expected. However, moderation of comments is necessary to prevent spam, personal attacks, profanity, mentions of legal action or off-topic commentary. We will not publish comments that advertise shopping sites or ones that violate our terms of service.

Comments related to specific product support or customer service issues will be addressed separately rather than posted here. Please use the links in Contact Us for product and customer service assistance.

About Cloud Computing  |   Contact Us Creative Commons License Powered by CommunityServer