Datacenters and cloudcenters

[Randy Bias]

Hello Folks,


    I was recently spending a lot of time thinking about how GoGrid and Amazon Web Services were different.  I felt that it was more than simple things like UI vs. no UI (now moot) or feature-set comparisons.  The conclusion I came to is that these are two vastly different approaches to building a cloud computing infrastructure.  Neither seems right or wrong, but in the end I believe they show a focus on very different markets.  I think you’ll agree.

    I’m calling the GoGrid approach a ‘cloudcenter’, which is simply the datacenter architecture ‘in the sky’.  It is different from a ‘virtual datacenter’ in that a cloudcenter contains virtual datacenters.  It’s the container in which multi-tenancy is achieved and virtual datacenters are delivered.  I think this has been apparent to folks for a while now, I’m just hoping to give it a name so we’re all on the same page while talking about IaaS models.

    More here in the blog posting:

    http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/


Best,


--Randy


--
Randy Bias, VP Technology Strategy, GoGrid
ran...@gogrid.com, (415) 939-8507 [mobile]
BLOG: http://neotactics.com/blog

[Johan Louwers]

Randy,
I have been reading your blogpost and I have to say it looks very good
at a first glance. I do have some questions however after looking at
your blogpost, maybe it would be answered if I would read all the pages
of your website but you also might be able to answer them right here for
all of us to read.

I have been reading about customers setting up the network, routing,
Vlan's and all in the cloud, how do you manage this? Are all your
routers and such virtual or do you provide access to physical routers so
customers can control them?

How much 'elastic' do you provide in upscaling and downscaling CPU power
and memory to customers? Are customers able to do this on the fly and/or
automatically when a SLA is about to breach?

In your blogpost you talk about failover datacenter and that it is easy
to copy a "virtual" datacenter to a other location, I can understand
this if all of your datacenter in the cloud is completely virtual, how
do you provide the mirroring of your data? Lets say that you have
massive amounts of storage in your databases, do you mirror the data on
your NAS with other failover datcenters and are there customers who are
working like this at the moment?

It looks to me very promising :-)

Regards,
Johan Louwers.

[Miha Ahronovitz]

Thanks Randy,

So, what does it mean in terms of the business model? I have seen the older Cloud Pyramid of of Michael Sheehan that you point us out to.
Where are the end users there? How the business chain from Infrastructure, through CloudCenters , Applications, gets filled  with $?

Otherwise it all looks like a car stranded on side of the road because of lack of gasoline., imho...

Miha Ahronovitz
PLM, Sun Grid Engine

---

From: Randy Bias <ran...@gogrid.com>
To: cloud-c...@googlegroups.com
Sent: Sunday, January 11, 2009 12:31:03 AM
Subject: [ Cloud Computing ] Datacenters and cloudcenters

[Sankar Nagarajan]

It seems GoGrid's Cloud Architecture is based on and integrated to
Appistry Enterprise Application fabric [EAF] ,a partner of GoGrid
http://www.appistry.com/products/eaf/index.html
http://www.gogrid.com/partners/index.php

There is a related News article here :
http://www.on-demandenterprise.com/offthewire/Appistry_Extends_Cloud_Computing_Reach_5552.html


Amzon's Architecture is based on the Opensource Xen Virtual Server
Architecture (Xensource is now acquired by Citrix and commercialised.)

Here comes the differentiation :

Fundamentally , I think , to understand what the blog points to and
What Randy says, A comparison of the Appistry EAF Cloud Platform
Technologies and Architecture and Xensource (or even VM ware for that
matter) should give us better insights.

In essence, my take is that one may create a Virtual CC environment
through a Virtualisation Architecture with Dynamic /Elastic Features,
Where as using Appistry sort of Platforms (which uses Linux and
Windows as the base stack), A " Cloud Data center " could be created
(with the same dynamic/elastic/manageable features)

Another provider to look at perhaps in the same model is 3Tera
(3tera.com) , You can rent and create your own cloud datacenter....!!
( I can subscribe,Rebrand and be the first cloudcenter provider in
Asia -:))

Busines Model :-

Business Model is more or less the same , Pay as you go model with
dynamic scalability and management with specific server
configurations.

Application Layers /App deployment : Several Third-Party vendors
(ISVs) are making their App stack available for Virtual servers and
Amazon EC2 (Example Redhat LAMP stack,Jboss stack so on). Where as
with GoGrid , it looks like they partner with company's such as
GigaSpaces to Appistry to offer SCALABLE Java and .NET Application
stacks.

There are subtle differences,One has to look at the various pros and
cons including portability, vendor lockin,migration efforts and costs
to mention a few...


- Sankar Nagarajan
Vice President
ikas Technologies
http://www.linkedin.com/in/nsk007
http://www.ikastech.com

>    http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the...

[Jan Klincewicz]

A clarification :

XenSource was acquired by Citrix in October of 2008, however XenSource came into existence in 2005 to commercialize Xen, an Open Source hypervisor first developed at Cambridge U. around 2001. 

Xen.Org is now the body which overlooks Open Source development of the Xen hypervisor, and is contributed to by Citrix, IBM, HP, Intel and a host of others.

Thanks,

--
Cheers,
Jan

[Jan Klincewicz]

Sorry - That was October of 2007 when Citrix acquired XenSource.  It was not until 2008 that Citrix hired ME, thus marking  the REAL beginning of the Citrix/Xen era !

--
Cheers,
Jan

[Miha Ahronovitz]

Randy, Sankar,

> Business Model is more or less the same , Pay as you go model with
> dynamic scalability and management with specific server
> configurations.

Hmmm...This is a view from engineering, and not from the customer's preceived value.

Cloud Computing will not be viable unless we see it as a huge CLOUD in which we place new and existing technology at one end, that produces $$$$ at the other end. The purpose is to attract - at the end of the chain - users who will pay for the effort. The Clour Tiers 1 and 3 companies, part of this cloud ecosystem (see below) can only make profits is there is a sound base of end users.

Everybody agrees this Cloud business model is lower cost to operate than having our own Data Centers. But how do we prove it?

On Silicon Valley the more cautious than ever Venture Capitalists would not fund easily a start up that depends upon others in reaching paying customers.

I proposed in my other email on the Personal SuperComputing thread the following model:

- Tier 1 Large HPC site owners with virtualizations offers
- Tier 2 Organizations buying elastic virtual data centers (clouds)
- Tier 3 Applications and support for services offered in the virtual data centers
- Tier 4: The End Users who consume the services provided at Tier 3

Everyone in Tiers 1 and 2, should be aware of the Tier 3 organizations that have largest number of paying users. They should seek and strike partnerships to all primising Tier 3 Companies.

Amazon is a pioneer in cloud computing (at least in the name), Lets ask them: Does Amazon makes $ with cloud computing? Unless somebody proves me wrong,I believe the AWS department within Amazon does *not* make money. It looses money, They can afford it, as they make huge revenues from sales of goods and services to a huge customer base.

So why Amazon (AWS) invests so much money ?

Bacause they have an unprecedented access to largest on-line customers base, world-wide, buying anything from anywhere. Because they have a vision. And Amazon knows that the investment they make in forms of inventing the AWS, if it pays, it will big! Very Big!

I predict the following: One day, Amazon will create a new company (or partnership) to offer Tier 1 and Tier 2 hardware and virtual hardware access.

Then they will recruit Tier 3 applications and services vendors, and all we will see on Amazon.com will be services. Why services? Because this is what the Amazon end users - who pay for everything from a shirt to motor-home or vacations - are accustomed to.

So only Services in form of interfaces from Tier 4 will be visible to the end users, same way as Google users don't care how they have answers to their questions.

2 cents,

Miha Ahronovitz
PLM, Sun Grid Engine

[Randy Bias]

Sankar,

Thanks for the opportunity to clarify. We are NOT based on Appistry.
More details below.

On 1/11/09 10:31 AM, "Sankar Nagarajan" <nagaraj...@gmail.com> wrote:
> It seems GoGrid's Cloud Architecture is based on and integrated to
> Appistry Enterprise Application fabric [EAF] ,a partner of GoGrid
> http://www.appistry.com/products/eaf/index.html
> http://www.gogrid.com/partners/index.php
>
> There is a related News article here :
> http://www.on-demandenterprise.com/offthewire/Appistry_Extends_Cloud_Computing
> _Reach_5552.html
>
> Amzon's Architecture is based on the Opensource Xen Virtual Server
> Architecture (Xensource is now acquired by Citrix and commercialised.)

That is incorrect. We are an Infrastructure-as-a-Service (IaaS) cloud just
like AWS. Our cloud server infrastructure is based on the same Xen
hypervisor technology that Amazon uses. We deploy it in a slightly
different model, leveraging Xen HVM (hardware virtualization) to provide
better performance.

Appistry is a partner. They provide access to Appistry's EAF on top of our
cloud computing infrastructure via virtual machines just as they would do it
on top of Amazon Web Services.

Appistry's use case highlights a major difference between cloudcenters like
GoGrid and AWS however. The Appistry software wants to use 'IP multicast'
to do automated discovery of Appistry servers for clustering. This is
impossible on AWS, which required a work around on their part. Whereas most
cloudcenters provide IP multicast functionality just like a normal
datacenter and hence are more friendly to software that has advanced
networking requirements.

> Here comes the differentiation :
> Fundamentally , I think , to understand what the blog points to and
> What Randy says, A comparison of the Appistry EAF Cloud Platform
> Technologies and Architecture and Xensource (or even VM ware for that
> matter) should give us better insights.
> In essence, my take is that one may create a Virtual CC environment
> through a Virtualisation Architecture with Dynamic /Elastic Features,
> Where as using Appistry sort of Platforms (which uses Linux and
> Windows as the base stack), A " Cloud Data center " could be created
> (with the same dynamic/elastic/manageable features)

Again, we're not based on Appistry. Appistry is one of many software
partners that deliver solutions on top of our platform.

> Another provider to look at perhaps in the same model is 3Tera
> (3tera.com) , You can rent and create your own cloud datacenter....!!
> ( I can subscribe,Rebrand and be the first cloudcenter provider in
> Asia -:))

This is correct. It's possible to use 3Tera to deliver a cloudcenter. The
primary difference would be that cloudcenters delivered using 3Tera might
face certain challenges. The 3Tera platform bakes in all of the
functionality like switches, routers, and storage. So you are reliant on
using only what can be delivered via 3Tera. Cloudcenters that are able to
wrap software and automation around hardware appliances may be able,
ultimately, to provide deeper differentiation and features than one using
3Tera that is restricted to software-only solutions on the 3Tera AppLogic
system.

> Busines Model :-

> Application Layers /App deployment : Several Third-Party vendors
> (ISVs) are making their App stack available for Virtual servers and
> Amazon EC2 (Example Redhat LAMP stack,Jboss stack so on). Where as
> with GoGrid , it looks like they partner with company's such as
> GigaSpaces to Appistry to offer SCALABLE Java and .NET Application
> stacks.

Close. There is no functional difference at this layer from AWS or GoGrid.
Any ISV can provide solutions on either cloud platform. RightScale provides
scalable stacks on GoGrid and AWS. GigaSpaces and Appistry provide scalable
Java stacks on BOTH GoGrid and AWS.

There is no real functional difference here between the platforms. But
we're talking about targeting developers at this layer. When you look at
what the sysadmin, IT professional, and web operator needs, it's more than
simply a PaaS service like RightScale, GigaSpaces, and Appistry. These
folks need to get hands on to the core IaaS functionality to build out
virtual datacenters for their customers (internal developers, etc.). In
this case, a cloudcenter is much more friendly.

> There are subtle differences,One has to look at the various pros and
> cons including portability, vendor lockin,migration efforts and costs
> to mention a few...

Actually, I don't think the difference is that subtle. I think it's
extremely clear. You want a solution that looks like a regular datacenter
or you don't. If the former, a cloudcenter makes more sense. If the
latter, then a web service solution makes sense. Sysadmins/IT are
comfortable with datacenters. Developers are comfortable with web services.

Couldn't be clearer or more stark to me.

What might be confusing is that the SAME types of solutions and PaaS
offerings will be delivered on both cloudcenter and web service IaaS
platforms. The *results* are the same, but the instigators, target market,
and methods are different.

Also worth pointing out here that cloudcenters will wind up being very
similar, so moving your virtual datacenters between them should be much
easier than when trying to move between web service infrastructures, who
will tend to provide completely custom (a la AWS) services that are not
standards or compatible with anything else.

[Randy Bias]

Miha,

Thanks for your insights. My replies inline below.

On 1/11/09 11:36 AM, "Miha Ahronovitz" <mij...@sbcglobal.net> wrote:
> Cloud Computing will not be viable unless we see it as a huge CLOUD in which
> we place new and existing technology at one end, that produces $$$$ at the
> other end. The purpose is to attract - at the end of the chain - users who
> will pay for the effort. The Clour Tiers 1 and 3 companies, part of this
> cloud ecosystem (see below) can only make profits is there is a sound base of
> end users.

I'm not certain I understand your point here. Can you elucidate? The
Internet *is* the 'huge CLOUD'. It's already there. What's being created
now is a more open set of infrastructures and platforms that increase
customer choice, provide new value propositions, and enable whole new models
of computing.

> Everybody agrees this Cloud business model is lower cost to operate than
> having our own Data Centers. But how do we prove it?

I don't think that's true at all. Lots of folks have already weighed in on
both sides of this 'proving' it both ways. The answer is far more nuanced
than you make it out here. Cloud computing is not always 'lower cost to
operate'. That's not been proven at all. The most recent, and relatively
in-depth, writeup I've seen related to this was Geva Perry's:

http://gevaperry.typepad.com/main/2009/01/accounting-for-clouds-stop-saying-
capex-vs-opex.html

> Amazon is a pioneer in cloud computing (at least in the name), Lets ask them:
> Does Amazon makes $ with cloud computing? Unless somebody proves me wrong,I
> believe the AWS department within Amazon does *not* make money. It looses
> money, They can afford it, as they make huge revenues from sales of goods and
> services to a huge customer base.

I think this is a bad assumption. By all measures I've heard of, Amazon is
an extremely prudent business operator. I think it's extremely unlikely
that Amazon is deliberately running AWS as a loss leader for some other
purpose. Whether they are profitable or not now is unknown, but they are
clearly building this as a long term business.

> I predict the following: One day, Amazon will create a new company (or
> partnership) to offer Tier 1 and Tier 2 hardware and virtual hardware access.

I don't really understand what you mean. Can you explain? They already
offer virtualized servers through EC2.

> Then they will recruit Tier 3 applications and services vendors, and all we
> will see on Amazon.com will be services. Why services? Because this is what
> the Amazon end users - who pay for everything from a shirt to motor-home or
> vacations - are accustomed to.

I don't really understand this either, but I think I can possibly shed some
light by explaining something you may not be aware of.

Amazon.com is one of the best run businesses on the Internet. Not only are
they profitable, but in the course of understanding and building a business
that was scalable they did a number of things.

The first was that they built a very efficient and robust supply chain,
warehousing, and distribution system. They did such an outstanding job of
productizing this internally that they were able to resell it as a service:
Amazon Services. You can see it here:

http://www.amazonservices.com/

With Amazon Services you get to use their warehouses, their fulfillment
systems, and payment systems. This was NOT built as a one-off. It's a
reuse of pre-existing infrastructure, internal technology, and capabilities
that they already had.

Amazon Web Services is the same thing, but for Internet infrastructure
instead of supply chain infrastructure. AWS existed, before it was
commercialized, as internal technology that was used by Amazon to build,
run, and scale Amazon.com.

The Amazon folks learned early on that with thousands of products they would
not be able to train their operations staff on how to run those products.
They made a command decision to have the developers of each product be
responsible for 24x7 service delivery. Then they made their operations team
build a common stack of web services that could be used by all of the
developers. This was a way to keep every development team from making up
their own solutions.

The result was that the Amazon ops team built out a bevy of internal web
services that will likely look familiar including:

- Storage
- Compute
- Messaging & queuing
- Payment processing
- Indexing & catalogs
- Search

Each Amazon product development team used these services to build and
deliver their products. The operations team developed these internal
products (aka 'web services') that then formed the basis of Amazon Web
Services. There is some more background here:

http://highscalability.com/amazon-architecture

This is a great Internet business at it's best. Amazon not only figured out
how to scale both their supply chain and Internet business, but *also* how
to turn all of those lessons learned and core competencies into a set of two
more businesses. They are just reusing everything that made Amazon.com
powerful to deliver these two new businesses.

Amazon Services and Amazon Web Services are not just some 'extra' businesses
they tacked on the side to help out Amazon.com.

[Mukund Parthasarathy]

So why Amazon (AWS) invests so much money ?

Bacause they have an unprecedented access to largest on-line customers base, world-wide,  buying anything from anywhere. Because they have a vision. And Amazon knows that the investment they make in forms of inventing the AWS, if it pays, it will big! Very Big!

I predict the following: One day, Amazon will create a new company (or partnership) to offer Tier 1 and Tier 2 hardware and virtual hardware access.

   On the question of Amazon's investment: I'm not sure how much they invested in AWS (other than head count), but in terms of IT infrastructure/capacity, they had a unique advantage coming in to this market:

MOST of their capital costs were sunk costs (meaning, AWS capacity comes from existing/idle infrastructure or smaller/incremental investments). Google comes from a similar position. Almost all other new players (IaaS providers) need to come in with some or significant investments in infrastructure. So, in addition to the economies of scale Amazon enjoys due to their distributed computing platform, they probably have a huge advantage in their cost structure. That will definitely give them more wiggle room, while I'm sure their level of investment is not as high as MS, for example.

   Ultimately, the type of workloads, programming/deployment model, cloud fabric support might drive the segmentation/differentiation. While AWS might be chosen for "High throughput" workloads, at least as of today, no one will chose AWS for "High performance" workloads (as in: optimization the speed of a single task on a parallel computing platform). Even though both markets can be served via cloud delivery business model, the deployment model and the fabric support required have subtle differences, I haven't seen a lot of vendors talking about this yet.

Cheers,

--Mukund

Blog: http://mukundanps.wordpress.com 

[Ray Nugent]

Mukund, I'm not sure they have a unique advantage over, say, Yahoo or Google or MSFT or eBay or name you large scale XYZ internet biz here?  All those companies have spare capacity that is sunk cost, but they are too busy building ad supported businesses or switching to AIR or some other unprofitable thing. Amazon had an advantage in Vision, timing, execution and...balls over most other big internet businesses don't you think?

Ray

---

From: Mukund Parthasarathy <mukun...@gmail.com>
To: cloud-c...@googlegroups.com
Sent: Sunday, January 11, 2009 5:13:29 PM

[Mukund Parthasarathy]

Ray-

  Absolutely. Amazon definitely had the vision/excellent execution....the programming model/deployment model does not incur the cost of a large learning curve. I was just trying to point out that Amazon, Google fall in the same bucket...at least  in terms of sunk costs or just incremental infra investments over their distributed computing model being put in to good use for their new business, given that they were first to market. Other players (like MS) don't necessarily have that advantage, as providers.

Regards,

--Mukund

[Miha Ahronovitz]

Randy, perhaps I was not clear.

1st, Amazon is a great company, with the vision. This is was my
point. You are preaching to the choir.
Because just provisioning Ec2 clouds, is $ negligible revenues,
compared to what money can be collected by placing the services
(applications) on direct access on Amazon.com
Thet EC as a business activity will lead to results longer terms which
will be spectacular when the end users can access services via
Amazon.com

2nd A business model - any business model - is shown as a diagram with
a box in the center (I called it a cloud, to be creative I
suppose :-) ).
One the left input side we put all the activities and capital we need
to invest.
On the right we show what $ we get in forms of profits.
Any company that makes a living from provisioning virtual elastic
cloud, must be sure their customers have enough end users

3rd The Cloud Computing Business model is the reason why we have this
discussion group and Cloud is latest Buzz word in the IT industry.
Cloud computing - and I include some grid computing as part of it -
is ALWAYS the better solution, when compared to the Data Center or in
house large grids

When it appears not to be so, IMHO, either the cloud business
approach must be changed or the inability to explain the ROI to
management in a clear fashion, are the real reasons

See "Forrester's Advice to CFOs: Embrace Cloud Computing to Cut Costs"

http://www.eweek.com/c/a/Enterprise-Applications/Forresters-Advice-to-CFOs-Embrace-Cloud-Computing-to-Cut-Costs/

Miha

On Jan 11, 2:16 pm, Randy Bias <ran...@gogrid.com> wrote:
> Miha,
>
>     Thanks for your insights.  My replies inline below.
>
> On 1/11/09 11:36 AM, "Miha Ahronovitz" <mij...@sbcglobal.net> wrote:
>
> > Cloud Computing will not be viable unless we see it as a huge CLOUD in which
> > we place new and existing technology at one end,  that produces $$$$ at the
> > other end.  The purpose is to attract - at the end of the chain -  users who
> > will pay for the effort. The Clour Tiers 1 and 3 companies, part of this
> > cloud ecosystem (see below) can only make profits is there is a sound base of
> > end users.
>
> I'm not certain I understand your point here.  Can you elucidate?  The
> Internet *is* the 'huge CLOUD'.  It's already there.  What's being created
> now is a more open set of infrastructures and platforms that increase
> customer choice, provide new value propositions, and enable whole new models
> of computing.
>
> > Everybody agrees this Cloud business model is lower cost to operate than
> > having our own Data Centers. But how do we prove it?
>
> I don't think that's true at all.  Lots of folks have already weighed in on
> both sides of this 'proving' it both ways.  The answer is far more nuanced
> than you make it out here.  Cloud computing is not always 'lower cost to
> operate'.  That's not been proven at all.  The most recent, and relatively
> in-depth, writeup I've seen related to this was Geva Perry's:
>

> http://gevaperry.typepad.com/main/2009/01/accounting-for-clouds-stop-...

> ran...@gogrid.com,(415) 939-8507[mobile]
> BLOG:http://neotactics.com/blog

[John D. Mitchell]

On Monday 2009.01.12, at 06:19 , Miha Ahronovitz wrote:
[...]

> 3rd The Cloud Computing Business model is the reason why we have this
> discussion group and Cloud is latest Buzz word in the IT industry.
> Cloud computing - and I include some grid computing as part of it -
> is ALWAYS the better solution, when compared to the Data Center or in
> house large grids

No, it's not "always" better (economically or technologically). Sorry
but you'll need to show a lot more "proof" then just an analyst's
report.

Take care,
John

[Randy Bias]

Miha,

    In terms of the business model it simply means that cloudcenters are better suited to sysadmins, operators, and IT staff.  And less well suited to software developers.  And vice versa for using web service infrastructures like AWS.

    Michael Sheehan is working on an updated Cloud Pyramid that will more clearly show how there are two types of IaaS provider: cloudcenters and web service infrastructures.

    Not sure what you mean by a car stranded on the side of the road.  I’m simply outlining the differences between two types of IaaS provider.  AWS is absolutely the #1 player in this market, but all of the other IaaS players are currently seeing fantastic growth and most of those are cloudcenters.  So, this car is already revved up, in motion, and burning rubber.  I’m simply pointing out that the cloudcenter car is a different kind of car than the web service infrastructure car.  Both are on the track and moving.


--Randy

On 1/11/09 8:14 AM, "Miha Ahronovitz" <mij...@sbcglobal.net> wrote:

So, what does it mean in terms of the business model? I have seen the older Cloud Pyramid of of Michael Sheehan that you point us out to.
Where are the end users there? How the business chain from Infrastructure, through CloudCenters , Applications, gets filled  with $?

Otherwise it all looks like a car stranded on side of the road because of lack of gasoline., imho...

[Randy Bias]

Johan,

Thanks for your questions and an opportunity to clarify. My responses
follow inline.

On 1/11/09 5:58 AM, "Johan Louwers" <sun...@dds.nl> wrote:
> I have been reading about customers setting up the network, routing,
> Vlan's and all in the cloud, how do you manage this? Are all your
> routers and such virtual or do you provide access to physical routers so
> customers can control them?

Right now all customers share routers, loadbalancers, and (soon) firewalls.
These are standard hardware devices (Cisco, F5, and Fortinet) that we have
written automation around to provide in a multi-tenant fashion. So, for
example, as the customer you are allocated your own VLAN dynamically and can
then add a 'loadbalancer' to your virtual datacenter (aka 'grid'). Soon you
will be able to do the same with your firewall. In essence, from the
customer perspective you have a dedicated switch (VLAN), router (default
gateway), loadbalancer (VIP), and firewall (virtual firewall domain).

> How much 'elastic' do you provide in upscaling and downscaling CPU power
> and memory to customers? Are customers able to do this on the fly and/or
> automatically when a SLA is about to breach?

Customers can scale up or down their virtual machines on the fly just as in
AWS. As in AWS currently it's up to the customer to use our API and related
to bake this functionality into their application. Or to work with an
organization like RightScale, one of our GoGrid partner's, to do so.

> In your blogpost you talk about failover datacenter and that it is easy
> to copy a "virtual" datacenter to a other location, I can understand
> this if all of your datacenter in the cloud is completely virtual, how
> do you provide the mirroring of your data? Lets say that you have
> massive amounts of storage in your databases, do you mirror the data on
> your NAS with other failover datcenters and are there customers who are
> working like this at the moment?

We don't provide functionality like this currently. What we do is enable it
as replicating your datacenter architecture is much easier with a
cloudcenter. Most cloudcenters, whether GoGrid or someone else like
ElasticHosts or FlexiScale, look more like a 'regular' datacenter.

With regards to mirroring of data and related, there are a number of folks
looking at solving the data replication problem right now and we're going to
see some very novel approaches in 2009.

> It looks to me very promising :-)

GoGrid is an outstanding business, but my primary interest in writing this
article was to highlight what I think is a divergence in architecture and
target market for the IaaS segment of the Cloud Pyramid. There are two
types of IaaS provider. The Amazon type and the GoGrid type. Your needs
will dictate which one makes sense. I believe there is a large segment of
the marketplace that wants cloudcenters and not web service infrastructures.

[Miha Ahronovitz]

Randy,

 

    In terms of the business model it simply means that cloudcenters are better suited to sysadmins, operators, and IT staff.  And less well suited to software developers.  And vice versa for using web service infrastructures like AWS.

We are in total agreement.

 

Not sure what you mean by a car stranded on the side of the road.  

 

It’s a metaphor to say that that the whole cloud business cannot exist without end users adopting the model and using it.  IDC projects $42 Billion per year business for Cloud  Computing. By comparison,  the entire operating systems market is $30 Billion and it is dominated by Microsoft (22 Billion, I believe). There is no way we can make in cloud computing  $42B worldwide, simply by selling and buying cloudcenters and web service infrastructures.

 

We must have end users to adopt massively the application services and pay for the that service, instead of buying of the shelf software or installing classical  data centers in small and medium companies.

The more users we have at applications level, the more demand for cloudcenters and web services infrastructures from the providers of such services .

 

One area of Interest  for me is HPC computing. See the Personal Super Computing thread I contributed. This  can only happen if the concept of cloud computing is applied commercially to High Performance Computing. We are not there. We are getting there. The first proto-cloud computing ventures in HPC are very successful. See the vision of Complete Genomics:

 

http://www.completegenomicsinc.com/corporate/vision.aspx

 

Complete Genomics (CG) democratized the complex DNA sequencing  applications. Only  extremely large organizations could use this tool before, as they need tens of thousands of multi-core processors plus an army of sysadmins. Now CG made accessible DNA sequencing to the smaller organizations and individuals, making a substantial profit in the process. They only started 2 years ago, and they turn substantial profits. The users adoption has been beyond expectation, and we are talking of a very specialized field. They created a totally new market, impossible to exist before .

 

2 cents,

 

Miha Ahronovitz

PLM, Sun Grid Engine

 

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Randy Bias
Sent: Sunday, January 11, 2009 1:34 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re: Datacenters and cloudcenters

 

Miha,

[Sankar Nagarajan]

Randy,

Thanks for the clarifications.Based on your below mentioned comments,
Would you considerghtScale as a competitor to GoGrid? (apart from the
fact RightScale is also functioning as a cloud intermediary)

RightScale's value added layer and operations on top of the EC2/ AWS
model is more or less like a 'cloud center' and System admin
friendly.

Also, what is the added value of using RightScale for GoGrid ,if by
default GoGrid provides a cloudcenter model? Is it just another
channel for augmenting your business?

"Actually, I don't think the difference is that subtle. I think it's
extremely clear. You want a solution that looks like a regular
datacenter
or you don't. If the former, a cloudcenter makes more sense. If the
latter, then a web service solution makes sense. Sysadmins/IT are
comfortable with datacenters. Developers are comfortable with web
services.
Couldn't be clearer or more stark to me"

-- Sankar
http://www.linkedin.com/in/nsk007

On Jan 12, 2:50 am, Randy Bias <ran...@gogrid.com> wrote:
> Sankar,
>
>     Thanks for the opportunity to clarify.  We are NOT based on Appistry.
> More details below.
>

> On 1/11/09 10:31 AM, "Sankar Nagarajan" <nagarajansan...@gmail.com> wrote:
>
> > It seems  GoGrid's Cloud Architecture is based on and integrated to
> > Appistry Enterprise Application fabric [EAF] ,a partner of GoGrid
> >http://www.appistry.com/products/eaf/index.html
> >http://www.gogrid.com/partners/index.php
>
> > There is a related News article here :

> >http://www.on-demandenterprise.com/offthewire/Appistry_Extends_Cloud_...

[Randy Bias]

RightScale can be considered a Platform-as-a-Service (PaaS) provider. They
leverage multiple IaaS cloud providers including GoGrid and AWS. We do not
compete with them.

Cloudcenters != PaaS. Cloudcenters are an alternative delivery model for
IaaS from the AWS delivery model. You can compare cloudcenter very
favorably to a datacenter in terms of what's in it. But in the same way
that a datacenter doesn't automatically come with MySQL clustering, neither
does a cloudcenter.

But MySQL clustering comes with RightScale. That's what they do. Their
value add is to provide a platform on which your application runs. Our
value is to provide the infrastructure on top of which a platform runs.

I thought that Geva Perry's recent post was pretty insightful in drawing a
further distinction:

http://gevaperry.typepad.com/main/2009/01/cloudcenters-and-infrastructure-we
b-services-whats-the-difference-.html


--Randy

BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias

[Greg Pfister]

Interesting issues, Randy, and for me rather confusing … up to the
statement “Sysadmins/IT are comfortable with datacenters. Developers
are comfortable with web services.”

That led me to this thought:

Why think of this as a pyramid? Why isn’t it a stack? You have

- hardware at the bottom,
- then OSs,
- then glue those together with various forms of networking / DNS /
etc,
- then general distributed tools (distributed file systems for sure;
others?),
- then gradually more specialized tools (web servers, MapReduce) (this
covers a multitude of sins, and often includes semantics specific to
particular application areas)
- ultimately ending at applications.

Various vendors of cloud platforms stop at various points in the
stack, and their customers take over from that stopping point. There
are customers who want control over everything from the hardware up,
others who want everything already in place but their custom apps, and
nearly every level in between. Not all make sense as offerings; you
want to pick points where god-sized populations are comfortable – such
as Sysadmins, or web site designers, or genomists, other HPC types.
Etc.

So GoGrid is at the Sysadmin level, AWS is up at one of the many
application levels, and others may be in between.

It’s very much a “usual” stack, but at each level it’s modified to the
cloud environment – e.g., the hardware becomes virtual; the data
access tools get very scalable; etc.

Greg Pfister
http://perilsofparallel.blogspot.com/

On Jan 11, 3:50 pm, Randy Bias <ran...@gogrid.com> wrote:
> Sankar,
>
>     Thanks for the opportunity to clarify.  We are NOT based on Appistry.
> More details below.
>

> On 1/11/09 10:31 AM, "Sankar Nagarajan" <nagarajansan...@gmail.com> wrote:
>
> > It seems  GoGrid's Cloud Architecture is based on and integrated to
> > Appistry Enterprise Application fabric [EAF] ,a partner of GoGrid
> >http://www.appistry.com/products/eaf/index.html
> >http://www.gogrid.com/partners/index.php
>
> > There is a related News article here :

> >http://www.on-demandenterprise.com/offthewire/Appistry_Extends_Cloud_...

[Mukund Parthasarathy]

I see indirect references to Workload types in the discussion thread below, whether it is

a pyramid or stack. However, the type of Workload you are capable of supporting,

whether as a PaaS or Cloud-center or whatever depends on the capabilities of your

hw infrastructure at all levels, plus your Cloud fabric. Most vendors are not being vocal

about their positioning....I guess this is mostly because everyone assumes you're

going after web scale, distributed computing workloads. Other vendors are consolidating

investments such as util computing etc.

Why is this important?

You can't have a work-load agnostic CC framework, segmentation is important to meet

the needs of the customer base you're going after..as long as there's proven market

demand.

For those interested, I have created a new post on the issue of Workload characterization v/s

infrastructure capabilities in my blog : I think it is important for both providers and customers to know where their

capabilities/needs match along these 2 dimensions: workload type against the stack/pyramid

discussed here. Chances are, CC providers might have to help their customers migrate  to

a better workload distributing/resource utilization model, if we're serious about this market :)

Mukund

http://mukundanps.wordpress.com

[Sankar Nagarajan]

My belief is for the end users moving to the cloud , it is going to be
rather "Application Centric " rather than being "Infrastructure
centric"

As Elastic clouds become an abstract layer for from a client
perspective,End users need to focus more on their Business Apps rather
than anything on the low level Infrastructure plumbing work,rather it
should get to a lesser degree. Cloud vendors have to manage more of
the Work load characterisation dynamics and reliability as Mukund has
commented.

Here is an interesting blog related to this from Kaavo
http://www.kaavo.com/blog/-/blogs/application-centric-vs--infrastructure-centric-management-of-resources?_33_redirect=%2Fblog


Sankar Nagarajan
http://www.linkedin.com/in/nsk007

> Greg Pfisterhttp://perilsofparallel.blogspot.com/

> > ran...@gogrid.com,              (4...       [mobile]
> > BLOG:http://neotactics.com/blog- Hide quoted text -
>
> - Show quoted text -

[Randy Bias]

No offense, but that's a very shortsighted assertion. Reality is that
plenty of folks need, and will continue to need, the ability to manage their
infrastructure cloud deployments.

I can name countless examples, but the notion that you can somehow make the
infrastructure 'disappear' for every use case is disingenuous.

The cloud is NOT an abstraction layer. It *can* be an abstraction layer,
but it doesn't have to be.

Yes, the average end user wants to focus on their business apps. Yes, the
cloud gives more tools to make this possible, but it's not some magical
silver bullet. What if your business application requires multicast network
traffic? What if it requires a specific messaging platform that isn't
readily available?

The notion that you're going to build a single management system that
manages an infinite number of configuration options isn't reasonable. It's
very clear what we'll see instead is different 'stacks'. Stacks are
development environments.

For those paying careful attention you may have noticed that the number of
programming languages is *increasing* not decreasing. The same is going to
happen with stacks. There is no one-size-fits-all solution.

This isn't magic people. It's applications, platforms, and infrastructure
as usual but with a lot more tools at our disposal.

Thanks,

--Randy

On 1/15/09 7:15 PM, "Sankar Nagarajan" <nagaraj...@gmail.com> wrote:
> My belief is for the end users moving to the cloud , it is going to be
> rather "Application Centric " rather than being "Infrastructure
> centric"
>
> As Elastic clouds become an abstract layer for from a client
> perspective,End users need to focus more on their Business Apps rather
> than anything on the low level Infrastructure plumbing work,rather it
> should get to a lesser degree. Cloud vendors have to manage more of
> the Work load characterisation dynamics and reliability as Mukund has
> commented.
>
> Here is an interesting blog related to this from Kaavo
> http://www.kaavo.com/blog/-/blogs/application-centric-vs--infrastructure-centr
> ic-management-of-resources?_33_redirect=%2Fblog

--
Randy Bias, VP Technology Strategy, GoGrid

ran...@gogrid.com, (415) 939-8507 [mobile]
BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias

[gaberger]

Randy,

I can understand your point but I do not necessarily agree. While we can
have different layers of cloud (Infrastructure, Platform, Services) it is
the intent of this movement to in fact remove the dependencies (stacks) of
the infrastructure from the business service and drive down the operational
cost of managing infrastructure services.

Abstractions are a large part of the "cloud ecosystem" as a whole, and
follows the evolution of utility computing. This transformation will
continue to grow as companies struggle to keep their compute requirements
from outgrowing their physical premise constraints. We are already at the
point where the cost of maintaining the server (infrastructure/energy) have
already exceeded the capital cost.

"Infrastructure and Energy Cost (I&E) will be 75% of the cost in 2014 and IT
will be only 25%. That is a significant shift of 20% I&E and 80% IT in the
early 90¹s." Belady, C., ³In the Data Center, Power and Cooling Costs More
than IT Equipment it Supports², Electronics Cooling Magazine (Feb 2007)"

"The notion that you're going to build a single management system that
manages an infinite number of configuration options isn't reasonable"

I agree with this statement, but ultimately it is our job to figure this
out, unlocking the power of parallel processing for the masses and offering
the use of hundreds of thousands of servers to developers which can be built
used and destroyed 'at will' to meet business objectives.

There is no reason why as a community we can't build the service brokers,
connection managers and telemetry to develop, build and run these
environments (see some of the work OASIS is doing).

Back in the day I worked on the conversion of Chubb Insurance from
multi-drop mainframe terminals to client-server. They built a complete UI on
OS/2 with C running on IBM Lan Server with NetBEUI (YUCK). If we did not see
the problems with STACKs based architectures we would never have left the
Mainframe...

tks

-g

[Sankar Nagarajan]

I agree that differnt Application and infrastructure stacks will
remain for some time as CC model is in its embryonic stages from a
fullfledged commercial adoption . At present,the complexity of
packaging and running application stacks itself is overwhelming for
many. To this extent an abstraction of the Infrastructure layer would
make life easier (time to market,deployment,management and
maintenance costs,labour so on). It may not exist now ,Perhaps we
could see this happening in the (near) future.If we take the anology
of How enterprise Application infrastruture ,standards and Platforms
emerged in the last 10+ years viz JEE and .NET)


Sankar

On Jan 16, 10:16 am, Randy Bias <ran...@gogrid.com> wrote:
> No offense, but that's a very shortsighted assertion.  Reality is that
> plenty of folks need, and will continue to need, the ability to manage their
> infrastructure cloud deployments.
>
> I can name countless examples, but the notion that you can somehow make the
> infrastructure 'disappear' for every use case is disingenuous.
>
> The cloud is NOT an abstraction layer.  It *can* be an abstraction layer,
> but it doesn't have to be.
>
> Yes, the average end user wants to focus on their business apps.  Yes, the
> cloud gives more tools to make this possible, but it's not some magical
> silver bullet.  What if your business application requires multicast network
> traffic?  What if it requires a specific messaging platform that isn't
> readily available?
>
> The notion that you're going to build a single management system that
> manages an infinite number of configuration options isn't reasonable.  It's
> very clear what we'll see instead is different 'stacks'.  Stacks are
> development environments.
>
> For those paying careful attention you may have noticed that the number of
> programming languages is *increasing* not decreasing.  The same is going to
> happen with stacks.  There is no one-size-fits-all solution.
>
> This isn't magic people.  It's applications, platforms, and infrastructure
> as usual but with a lot more tools at our disposal.
>
> Thanks,
>
> --Randy
>

> On 1/15/09 7:15 PM, "Sankar Nagarajan" <nagarajansan...@gmail.com> wrote:
>
> > My belief is for the end users moving to the cloud , it is going to be
> > rather "Application Centric " rather than being "Infrastructure
> > centric"
>
> > As Elastic clouds become an abstract layer for from a client
> > perspective,End users need to focus more on their Business Apps rather
> > than anything on the low level Infrastructure plumbing work,rather it
> > should get to a lesser degree. Cloud vendors have to manage more of
> > the Work load characterisation dynamics and reliability as Mukund has
> > commented.
>
> > Here is an interesting blog related to this from Kaavo

> >http://www.kaavo.com/blog/-/blogs/application-centric-vs--infrastruct...

[Jamal]

I agree to Randy’s comment that we still need infrastructure centric
approach for certain things. When we say we need application centric
approach it is implied that it is needed from application owner
perspective, people who responsible for managing applications, their
service levels etc. People responsible for running infrastructure and
providing infrastructure as a service, e.g. Amazon, GoGrid, alt. needs
infrastructure perspective to manage their infrastructure. However,
the application owners who are consumers of infrastructure as a
service will make their life a nightmare if they try to manage
applications running on virtual resources using infrastructure
perspective.

Let’s look at some historic context to get the perspective of why
application centric approach is needed.

In good old days, application owners bought dedicated hardware for
running their applications and they had the flexibility to install
whatever patches, OS, etc. they needed for their applications on the
dedicated hardware. This was an era of high flexibility and low
hardware utilization.

CIOs and their bosses didn’t like it as utilization was low, question
was why are we wasting hardware, so the directive came from the top
that let’s consolidate the infrastructure. Once the infrastructure,
especially the servers, was consolidated application owner lost
flexibility as anytime they have to make a change to infrastructure
they needed to check with 10 groups within an enterprise to make sure
they are not going to step on someone’s toes because applications were
using shared resources. This was a time of higher server utilization
but lower flexibility, configuration management and time of running
regression tests multiple applications even if the change was required
by a single application. Several IT organizations are still stuck in
this phase.

Then came along virtualization, it resolved the conflict b/w
flexibility and utilization by allowing each application owner to run/
install their own OS/patches on a virtual server which is using a
slice of the physical server resources. Hence each application owner
was able to run their own application on their dedicated virtual
server and apply patches, changes etc. without impacting the other
applications running on different virtual servers on the same physical
box. Although virtualization solved the problem of lack of
flexibility, it created a new management nightmare, because for every
physical server we ended up having multiple virtual servers. So from
application owner perspective it introduced a new complexity as they
need to track all the virtual resources used by their applications.
This problem was significant for internal clouds or virtualized
environments, however, when you add the scale of public clouds,
especially clouds in different locations the management becomes a
nightmare from enterprise perspective. How can a large company with
100s of application using 1000s of servers manage this complexity?

Taking an application centric perspective for managing virtual
resources addresses the complexity issue, as each application owner
can manage the entire infrastructure used by their application as a
system. It also allows each application owner to individually hold
accountable the infrastructure as a service provider for SLAs of the
infrastructure as a service which may impact the service levels for
their applications. So complexity is managed by having distributed
management as each application owner can manage their own virtual
resources. The infrastructure as a service provider could be an
internal IT team responsible for managing private cloud and/or it
could be one or multiple public cloud providers. In IT all the work
we do ultimately leads to delivering and managing business
applications, and business holds us accountable based on not how fast
our routers or servers are but, are we delivering applications on time
and are the applications meeting the business service levels.
Business users are judging us from application perspective we will do
ourselves disservice by not taking an application centric approach for
managing our applications.

Here is the summary of IT evolution:
1) Phase I - Cowboy Days: Each application owner had their own
dedicated infrastructure/hardware. Flexibility High, Utilization of
Resources Low.
2) Phase II - Consolidation: Application running on shared
infrastructure. Utilization High, Flexibility Low.
3) Phase III – Virtualization: Use of virtualization in the
datacenters and use of public and private clouds. Utilization High,
Flexibility High, Complexity High.
4) Phase IV – Application Centric Management: Use of application
centric management for managing virtual resources. Utilization High,
Flexibility High, Complexity Low.

Jamal

On Jan 16, 12:16 am, Randy Bias <ran...@gogrid.com> wrote:
> No offense, but that's a very shortsighted assertion.  Reality is that
> plenty of folks need, and will continue to need, the ability to manage their
> infrastructure cloud deployments.
>
> I can name countless examples, but the notion that you can somehow make the
> infrastructure 'disappear' for every use case is disingenuous.
>
> The cloud is NOT an abstraction layer.  It *can* be an abstraction layer,
> but it doesn't have to be.
>
> Yes, the average end user wants to focus on their business apps.  Yes, the
> cloud gives more tools to make this possible, but it's not some magical
> silver bullet.  What if your business application requires multicast network
> traffic?  What if it requires a specific messaging platform that isn't
> readily available?
>
> The notion that you're going to build a single management system that
> manages an infinite number of configuration options isn't reasonable.  It's
> very clear what we'll see instead is different 'stacks'.  Stacks are
> development environments.
>
> For those paying careful attention you may have noticed that the number of
> programming languages is *increasing* not decreasing.  The same is going to
> happen with stacks.  There is no one-size-fits-all solution.
>
> This isn't magic people.  It's applications, platforms, and infrastructure
> as usual but with a lot more tools at our disposal.
>
> Thanks,
>
> --Randy
>

> On 1/15/09 7:15 PM, "Sankar Nagarajan" <nagarajansan...@gmail.com> wrote:
>
> > My belief is for the end users moving to the cloud , it is going to be
> > rather "Application Centric " rather than being "Infrastructure
> > centric"
>
> > As Elastic clouds become an abstract layer for from a client
> > perspective,End users need to focus more on their Business Apps rather
> > than anything on the low level Infrastructure plumbing work,rather it
> > should get to a lesser degree. Cloud vendors have to manage more of
> > the Work load characterisation dynamics and reliability as Mukund has
> > commented.
>
> > Here is an interesting blog related to this fromKaavo

> >http://www.kaavo.com/blog/-/blogs/application-centric-vs--infrastruct...

[Mukund Parthasarathy]

I guess the key here for Phase IV you outline, is to find an operationally viable

model, that evolves with "CC aware" hw/sw technology improvements: because 

today, the more dynamic/adaptive you want the infrastructure to be (in response to application

needs), the more complexity you add, for providers, and consumers as well, depending on the

level of abstraction exposed.

 This is just in the very early stages w.r.t workloads that fit the web scale/distributed computing on 

commodity hw model.

Utopia of course, is responsive/purposeful provisioning and re-purposing of infrastructure "stack"

in an application/workload centric manner. There is no such thing as workload agnostic infrastructure,

for providers...at least not yet.

 

While there are significant challenges for providers, this is not looking bad for consumers: CC models specializing in niche workload areas can & do abstract the infrastructure away, for the consumer -- if one could consider SaaS as an extreme example. More importantly, this has turned out to be operationally viable

to providers because they know their deployment/workload characteristics, so they're not trying to boil the

"app centric" ocean.

It will be interesting to see how the rest of the continuum shakes out.

Regards,

Mukund

Blog: http://mukundanps.wordpress.com