Subject: [clouds] A cloud ref. framework for your review and comments

From: Bhumip Khasnabish <[email-masked]>
Date: Fri, 30 Jul 2010 06:37:59 -0400

Dear All,

After the Clouds bar BoF yesterday, a few of us got together to work on
developing a simple Cloud reference framework.
Attached pls find the output of that discussion.

We look forward to your constructive comments and suggestions to improve
and finalize the ref. framework. Thanks  a lot.

Best Regards.
Bhumip

Bhumip Khasnabish (Mobile:+001-781-752-8003, [email-masked])

---

From: "So, Ning" <[email-masked]>
Date: Fri, 30 Jul 2010 14:12:20 +0000

Bhumip and all,

Thanks for the excellent work as a starting point.  Here are a couple of
my suggestions,

1.	Need at least one layer to represent the underlying networks.
What you have shown so far is the view of cloud purely from the data
center point-of-view.  The fact is that you need to have simple network
infrastructure to connect data centers to data centers (assuming the
data centers cluster is within a short distance, such as a metro area),
and to connect data centers to carrier networks (IP/MPLS/VPN).  In
addition, you need a complicated network to connect data centers with
the users.  
2.	Before inter-Cloud reference model framework, there should be a
reference model showing the inter-data center.  This should be a cluster
of data centers that can share the common resources and share the
protection with each other in case of failure.  Of course the networks
need to be a part of the model. 

Regards,

Ning So

Lead Engineer

Global Data Network Traffic Planning

Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bhumip Khasnabish
Sent: Friday, July 30, 2010 5:38 AM
To: [email-masked]
Subject: [clouds] A cloud ref. framework for your review and comments

Dear All,

Best Regards.

Bhumip

---

From: "Fargano, Michael" <[email-masked]>
Date: Fri, 30 Jul 2010 09:41:29 -0600

Bhumip:

I was not at the BoF. I was just wondering how the proposed framework relates to commonly understood Cloud terms like IaaS, PaaS, SaaS...??? For example see NIST Definition of Cloud: http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

I'm sure you discussed this at the BoD. Perhaps an explanation in the slide deck would help.

Thanks,
Mike

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhumip Khasnabish
Sent: Friday, July 30, 2010 4:38 AM
To: [email-masked]
Subject: [clouds] A cloud ref. framework for your review and comments

Dear All,

Best Regards.
Bhumip

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Sam Johnston <[email-masked]>
Date: Fri, 30 Jul 2010 18:55:27 +0200

Every man and his dog is trying to [re]define cloud so I would be quite
happy for us to leave this well alone, which is to say I don't accept the
opening premise that "*Currently there is no Standard Reference Framework
for Cloud Services, so first we need to develop a Reference Framework*".

If we must then I would suggest working with the already well accepted 3
layer stack:

   - Application
   - Platform
   - Infrastructure

If you want a *functional* taxonomy (that is, one which is capable of
categorising everything in the space without polluting these
*service*layers with
*products*) then you can add server and client layers ala:

   - Client (Android, iOS, etc.)
   - Application (Gmail, Salesforce.com, MS BPOS, etc.)
   - Platform (Azure, App Engine, Heroku, etc.)
   - Infrastructure (Amazon EC2, EBS, VPC, etc.)
   - Server (Cisco UCS, SGI CloudRack, etc.)

Note that these two additional layers are typically products (hardware
and/or software) while the three main layers are always services.

There's no need to find/create complexity where there need be none.

Sam

-- 
*Sam Johnston*
*Technical Program Manager*
Site Reliability Engineering
Google Switzerland GmbH

w: +41 44 668 16 79
h: +41 44 536 55 78
m: +41 79 631 25 16

On 30 July 2010 17:41, Fargano, Michael <[email-masked]> wrote:

> Bhumip:
>
> I was not at the BoF. I was just wondering how the proposed framework
> relates to commonly understood Cloud terms like IaaS, PaaS, SaaS...??? For
> example see NIST Definition of Cloud:
> http://csrc.nist.gov/groups/SNS/cloud-computing/index.html
>
> _______________________________________________
> clouds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clouds
>

---

From: Paul Unbehagen <[email-masked]>
Date: Fri, 30 Jul 2010 20:20:41 +0200

Along that vein of thought the network components are just as important as more and more private clouds get built. 

Not saying that we need to invent a new term, but we should not forget the components being built to support the connectivity and flexibility of the cloud. 

--
Paul Unbehagen

from my iPhone 

On Jul 30, 2010, at 6:55 PM, Sam Johnston <[email-masked]> wrote:

> Every man and his dog is trying to [re]define cloud so I would be quite happy for us to leave this well alone, which is to say I don't accept the opening premise that "Currently there is no Standard Reference Framework for Cloud Services, so first we need to develop a Reference Framework".
> 
> If we must then I would suggest working with the already well accepted 3 layer stack:
> Application
> Platform
> Infrastructure
> If you want a functional taxonomy (that is, one which is capable of categorising everything in the space without polluting these service layers with products) then you can add server and client layers ala:
> Client (Android, iOS, etc.)
> Application (Gmail, Salesforce.com, MS BPOS, etc.)
> Platform (Azure, App Engine, Heroku, etc.)
> Infrastructure (Amazon EC2, EBS, VPC, etc.)
> Server (Cisco UCS, SGI CloudRack, etc.)
> Note that these two additional layers are typically products (hardware and/or software) while the three main layers are always services.
> 
> Sam Johnston
> Technical Program Manager

---

From: Sam Johnston <[email-masked]>
Date: Sat, 31 Jul 2010 11:33:15 +0200

> more and more private clouds get built.

Again this is the tail wagging the dog (and assumes you accept the premise
that "private" cloud is even cloud given it lacks multi-tenancy and
therefore requires significant capex, engineering for peak loads, etc.).
Once there is some sanity around emulating legacy (e.g. virtual machines) in
the infrastructure space the focus will quickly shift to platforms (app
runtimes, databases, queues, etc.). The sooner the better if you ask me.

For now let's keep it simple at the upper level and drill down where & when
we need to.

Sam

---

From: Paul Unbehagen <[email-masked]>
Date: Sat, 31 Jul 2010 11:57:53 +0200

Think the semantic of "private" is a bit overloaded. Private may be multi-tenant environments of IaaS within traditional providers VPN for specific customers or different dept's within a larger corporation that run a IaaS or DCaaS separately. 

--
Paul Unbehagen

from my iPhone 

On Jul 31, 2010, at 11:33 AM, "Sam Johnston" <[email-masked]> wrote:

> Again this is the tail wagging the dog (and assumes you accept the premise that "private" cloud is even cloud given it lacks multi-tenancy and therefore requires significant capex, engineering for peak loads, etc.). Once there is some sanity around emulating legacy (e.g. virtual machines) in the infrastructure space the focus will quickly shift to platforms (app runtimes, databases, queues, etc.). The sooner the better if you ask me.
> 
> For now let's keep it simple at the upper level and drill down where & when we need to.
> 
> Sam
>