Is "Internal Cloud" an oxymoron ?
Jan Klincewicz
I'm of the mind that "Infrastructure as a Service" is more or less implied. Software as a Service would probably fall under this loose definition as well.
An "Internal Cloud" sounds to me like a cop-out for IT people who want to keep their jobs doing mundane infrastructure maintenance so they tell the higher-ups that they can do a "Cloud" in-house just to satisfy their want for "something different." "In-sourcing" became a popular phrase when outsourcing threatened the status quo.
It really doesn't matter whether the computing is a grid, client-server, or web-delivered, as far as I concerned. I think what makes Cloud Computing "cloud-like" is the abstraction of workloads from the physical compute resources. It doesn't necessarily require virtualization (though that starts to sound more like co-location) but that's OK. Visualization is just a tool to help with the elasticity and fuller resource utilization of apps that benefit from the spare CPU cycles, and for those apps that DON'T (like the large databases that consume all the cores you can throw at them) it still provides a layer of abstraction from the physical hardware making it (potentially) more portable and dynamic.
Just a thought...
--
Cheers,
Jan
Pietrasanta, Mark
I’m not clear on exactly what you’re saying? It sounded to me like you’re arguing both sides?
I have to disagree (I think) on a couple of your points:
1)
The main benefits of CC are around provisioning, maximizing
resource utilization, flexibility, adaptability, separation of hardware from
logical machines, etc. Anything that fits these criteria is CC, isn’t
it? Are you suggesting a criteria has to be “and not in-house”?
I’m not sure why, and I’m not sure what benefit that brings. Large
companies have more than enough volume and scale to justify and gain
substantial benefit from internal clouds, just like hosting facilities can
offer individual clouds. In fact, some large companies have larger
hosting needs than smaller hosting facilities!
2)
So I don’t see how you could say anything other than Cloud
Computing can be internal, either to an organization or to a hosting
facility. There are now bunches of hosting facilities offering “cloud
computing” capabilities, that’s not some uber EC2/Azure
cloud. It’s just a small(er), hosting-facility-specific
setup. Frankly, many of these have been offered for over a decade, under
lots of other names. So we call it CC now, that’s fine.
3) I think CC without some sort of virtualization is not possible. It’s simply not possible to have the abstraction of the logical machine from the physical hardware without some type of virtualization. That virtualization has, and will continue to change, but it’s always been there, right?
I’m sure I misunderstood your points below, so please correct me.
Thanks.
Ray
Fog Computing will probably be the Next Big Thing because the major players ( Cisco, Vmware, et al) want it that way.
But enterprise clouds should not be confused with Cloud Computing.
Ray
xd...@comcast.net
over 300k nodes (counting desktops) and I work in IT, though if we
adopt Cloud my job is largely not impacted by that decision. I wanted
to provide this context so you could read my thoughts below and
possibly get the context I'm coming from.
I think your projected rationale for the IT might be way off.
Internal Cloud makes sense in two very distinct ways:
1) We have more physical assets than many companies, and still need
to manage cost and efficiency. Cloud architectures (even if operated
internally) provide notable promises for agility (time to market,
rapid analysis and prototyping, on-demand scale up or down from the
application view), cost effectiveness (consolidation and workload
management across physical resources), and staffing and facilities
saves through these efficiencies. Even if I NEVER engage an external
anything to do this. Granted I might be able to save more if I engage
external hosting partners in my facilities and support and
infrastructure costs, but it isn't required for me to save money, and
there are currently lots of possible issues with externalized shared
infrastructure models.
2) Risk. Simply put, moving processing of some data loads externally
generates some notable changes in our risk analysis. Some workload
may never be moved due to sensitivity of the data, others due to lack
of sufficient liabilty agreements from vendors, others due to legal
and regulatory pressures. The risk provides the counter balance to
the cost and drives some workloads back internally, but that shouldn't
restrict my thinking to avoid Cloud behaviors and benefits generated
by operating internal systems more "cloud-like".
I don't care if it is called Cloud, Infrastructure Optimization, or
Bob. I want the properties and behaviors of Cloud Computing to
generate the speed and cost results needed both internally and
externally, and be able to make my decisions on workload movement
based on the cost risk factors, not on the name or technology that
makes it work. I think you are right that the key to what I need is
abstraction at the various levels, and current best single name given
to what I want is Cloud (at least that's the one my management
understands so I'm going with it).
None of these decisions are based on job retention or self-serving,
short-sightedness, but rather the balance between cost and risk for
the good of the overall corp. If possible I'd want it risk free, cost
free, and now, but hey I'm not THAT out of touch (yet) :)
On Jan 22, 4:05 pm, Jan Klincewicz <jan.klincew...@gmail.com> wrote:
> An "Internal Cloud" sounds to me like a cop-out for IT people who want to
> keep their jobs doing mundane infrastructure maintenance so they tell the
> higher-ups that they can do a "Cloud" in-house just to satisfy their want
> for "something different." "In-sourcing" became a popular phrase when
> outsourcing threatened the status quo.
>
Srini Gurrapu
One guy said "Cloud" equates Cost-savings [such a narrowed view].
The other guy said "Cloud" equates to the virtual disappearance of physical infrastructure and end users simply provision and manage their applications -- this is a very broad view that sounds more like S-a-a-S.
Here is what I came up with that covers both internal/external clouds..
1. Abstraction between physical and application resources to result in reduced CAPEX and OPEX in managing application workloads
2. On-demand and instantaneous provisioning of new workloads
3. Dynamic up/down scaling of the infrastructure capacity based on end user SLA needs without manual intervention
4. Last but not least, the chargeback is based on the granular utilization of the infrastructure resources.
Essentially, IT is delivered as a fully automated service.. This is also referred to as Dynamic IT etc..
My 2c..
Srini
--- On Fri, 1/23/09, xd...@comcast.net <xd...@comcast.net> wrote:
Jake Kaldenbaugh
Jan Klincewicz
Wikipedia:
Cloud computing is Internet ("cloud") based development and use of computer technology ("computing")[1][2][3]. It is a style of computing in which typically real-time scalable[4] resources are provided "as a service"[5] over the Internet[6] to users who need not have knowledge of, expertise in, or control over the technology infrastructure ("in the cloud") that supports them[7].
It is a general concept that incorporates software as a service (SaaS), Web 2.0 and other recent, well-known technology trends, in which the common theme is reliance on the Internet for satisfying the computing needs of the users. An often-quoted example is Google Apps, which provides common business applications online that are accessed from a web browser, while the software and data are stored on Google servers.
The cloud is a metaphor for the Internet, based on how it is depicted in computer network diagrams, and is an abstraction for the complex infrastructure it conceals.[8].
ServePath:
cloud computing — The definition of Cloud computing is the use of a 3rd party service to perform computing needs on a publicly accessible IP basis. Cloud computing services are usually performed in consolidated Data Centers to keep costs low while improving overall utilization.
***********************************************************************************************************************************************
Both definitions differ in that only the second explicitly includes "3rd party" as a prerequisite. I am not intentionally trying to "play both sides", but see if there is any consensus that "Cloud Computing" means that the primary user does not own the physical assets associated with IT infrastructure.
1. It seems to me that the "Cloud" part means that the hardware is somehow abstracted. If an organization is tasked with acquiring, and maintaining these physical compute resources, I do not see a great deal of abstraction. A full complement of expensive IT staff is needed for the "care and feeding" of what, in the end, is a "commodity."
2. If "elasticity" is fundamental to Cloud Computing, that would imply that an organization will need to over-provision to accommodate peak usage periods (which mitigates the financial benefits of flexible provisioning.) If an organization maintains all this infrastructure "in house" and makes it available to all business units, then it qualifies as what ITIL refers to as "Shared Services", but I do not see how this can be called a "Cloud."
3. I do virtualization for a living, but cannot agree that it is essential to "Cloud Computing" because CC is capable of providing Grid resources which do not, by definition require "virtualization", but rather parallel processing. Likewise, very large-scale databases may not benefit as much from consolidation via traditional virtualization (as we know it today.)
Hope this clears up my post (which was actually a question, not a manifesto ) :)
Cheers,
Jan
Warren Free
I think this highlights the issues that we have with the term "Cloud
Computing", it means something different to everyone.
My personal opinion of cloud computing is that a user can access his/her
applications and data wherever they may be, regardless of where the data or
applications reside. I honestly cannot see large organisations allowing
their applications and data being stored outside of a "cloud" that they
manage and control. But does that mean they aren’t adopting cloud
computing?
Warren
--
Warren Free
Business Development Manager
Read my blog at www.virtualnetworkpartners.eu/blog
How secure is your mobile data? Download our free whitepaper.
www.virtualnetworkpartners.eu
Tel: +44 (0)2030 040 753 Mob: +44 (0)7812 414193 Office: +44 (0)2030
040 750
-----Original Message-----
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of Ray
Sent: 23 January 2009 17:06
To: cloud-c...@googlegroups.com
Miha Ahronovitz
This is one of best contribution to this group, and to this thread.
Three points are worth conserving:
(1) Enterprise Clouds have physical assets
(2) we can call the cloud what ever (Cloud, Infrastructure or "Bob")
we call it Cloud because people understand the term as something modern
(3) we need to balance costs and RISKS before considering
more physical assets or more virtual assets, or both
Some corporations are so big, they serve more users internally than many cloud computing start up company serve with outside customers.
A simple calculation of grid computing (to add a new name for the Cloud, after "Bob", - we can call it an "elastic grid")
1. Annualized cost per h/w and software ( new equipment 3 to 5
years)
2. Annualized costs of the personnel directly administering the grid
3. Support services from third parties
4. Percentage of Utilization of the grid
5. Assume power consumption
Here are some arbitrary numbers, for illustration sake only (not real numbers)
1. Assume $1,200,000 per year h/w and s/w
2. Assume 8 people at $100,000 each, $800,00 per year
3. Assume support services 400,000 per year
5. Assume Power consumption 600,000 per year (50,000/month is low price)
Total annual costs are $3 million per year.
Assume utilization is 50%. Then the cost for the time the grid is
active, is doubles, at $6,000,000
The total cost of operating the grid is then about $500,000
per month
If we have we assume 20 days per month of gainful operation, it costs
25,000 per day to have a grid.
If we do the cost on an arbitrary 10 hours day, we have , $2,500 per hour.
Notice two things.
1- if we double utilization to 100% from 50% , our hourly costs goes
down from $2,500 to $1,250
2- To make a profit (ratio 5, to be able to offer discounts), assume the
users pay for the service, grid should charge between 12,500 to $6,250 per hour LIST prices
(which gives 50% margin at 60% discount)
The sensitivity of the utilization is notable.
The usage of an external Amazon virtual infrastructure, provides you with virtual OS instances
only with very low guarantees on the performance of each individual
instance may request 3, 5 or 10 times longer to do the job, or offer 3,
5 or 10 times less throughput. One has to decide whether one can live with or not, but in this case it may be that adding physical assets is a better decision.
Assume you have an urgency for work that can come suddenly and you need immediate response: There's a premium which you have to pay
to get guaranteed access to the resources you need immediately when you
need them. Cloud infrastructures like Amazon may not provide you with a
solution here. I.e. there may be no way for you to throw money at them
and get your work done sooner.
Getting to use Amazon (I keep repeating Amazon as this name is synonymous with Elastic Clouds) the really tricky aspects of
cloud computing which are security/privacy and data locality. Most money
in using Amazon goes into payments for data transport and data storage.
The CPU-hrs are only a fraction. The more data your application requires
to be stored and transferred the less attractive Amazon becomes. And
transferring massive amounts of data has a huge time implication also -
you're bound by the public Internet infrastructure ... Note that for
hard HPC apps we're talking hundreds of Gigabyte if not more - per
individual run.
Some of the thoughts above are specific for High Performance Computing. The HPC is a name coined in 50s to label exotic applications with Cray and Thinking machines. today, all computing is high performance. Risk modeling is extremely processor intensive. Image recognition is high performance. Modern data bases are high performance
Cheers,
Miha
PS: I am indebted for some key ideas from this post to my colleague Fritz Ferstl.
----- Original Message ----
From: "xd...@comcast.net" <xd...@comcast.net>
To: Cloud Computing <cloud-c...@googlegroups.com>
Sent: Friday, January 23, 2009 9:29:39 AM
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
Jan Klincewicz
Abraham Lincoln is credit with the following :
While giving a discourse to an audience on why slavery should be abolished, Mr. Lincoln was asked by a member of the crowd "Mr. Lincoln, if slavery is so wrong then why don't you just pass the legislation to get rid of it?"
Mr. Lincoln answered with a question: "Sir, if I call a lamb's tail its leg, how many legs will it have?".
The man answered "Five."
"No, it will still have four", replied Mr. Lincoln, "calling a lamb's tail a leg doesn't make it a leg."
Anyway, my position is that CALLING an internal IT infrastructure a "cloud" doesn't make it one.
The premise behind elasticity is that an enterprise can spin up and spin down compute resources as business needs (such as seasonality) dictate. In order to accommodate this, an IT infrastructure needs to be constructed to handle the MAXIMUM capacity, and then will lay idle the remainder of the time. While you may turn the servers, switches and storage systems off, they require maintenance contracts, take up physical space, and need to be wired (often by Union workers.)
Acquiring expensive depreciable assets in this fashion DOES eliminate risk, but at a very high TCO. There are also risks inherent in investing in technologies which may obsolete prematurely. Do you think the server sales rep, knowing he is probably looking at a work force reduction six months down the road cares if you realize the blade chassis and associated peripherals for which you are about to sign a P.O, is going end-of-life in 10 months, and the new model will not work with the blades you are just about to deploy ?
I'm not saying that any CC: providers out there NOW will be able to meet the needs of most typical organizations with CC as it exists today. Also, a mega-conglomerate like Johnson and Johnson probably has a diverse enough portfolio of organizations to scale it's internal IT to "Cloud" proportions.
I'm not looking to create a definition of CC myself, but am hoping the collective wisdom of this group will eventually achieve a consensus on what it really means.
Cheers,
Jan
Mukund Parthasarathy
Jan Klincewicz
I am certainly not arguing that there are salient reasons not to want to lose control of corporate data. Many people here have pointed these out numerous times; security, vendor dependency, etc.
Still, the fact remains that IT is pretty unique in the costs it represents to organizations who are not in the IT business.
Sure, Verizon and Comcast, GM have in-house Counsel, but a great deal of legal work is sent outside. Any dot-com still surviving probably has a sushi chef in-house, but most large enterprises have Aramark preparing meals in the cafeteria (if they still have one.)
How many organizations can you think of now that still have an in-house Travel Agent ?? How about HR?? In the last five years I worked at Hewlett Packard, HR was a WEBSITE !!! Companies out there recruiting use headhunters.
Compensation planning is outsourced along with a number of functions that used to be considered "mandatory" to keep in-house for reasons of "security" and "protection of intellectual property."
Again, I am not purporting to define Cloud Computing, but to query the collective intelligence here to try and reach a consensus. Your arhument is every bit as valid as anyone else's. It will be interesting to see how CC is defined a year from now. Thanks for your thoughts.
But surely cloud computing and Enterprise clouds are the same thing?
I think this highlights the issues that we have with the term "Cloud
Computing", it means something different to everyone.
My personal opinion of cloud computing is that a user can access his/her
applications and data wherever they may be, regardless of where the data or
applications reside. I honestly cannot see large organisations allowing
their applications and data being stored outside of a "cloud" that they
manage and control. But does that mean they aren't adopting cloud
computing?
Warren
--
Warren Free
Business Development Manager
Read my blog at www.virtualnetworkpartners.eu/blog
How secure is your mobile data? Download our free whitepaper.
www.virtualnetworkpartners.eu
Tel: +44 (0)2030 040 753 Mob: +44 (0)7812 414193 Office: +44 (0)2030
040 750
[mailto:cloud-c...@googlegroups.com] On Behalf Of Ray
Sent: 23 January 2009 17:06
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
--
Cheers,
Jan
Steven Bulmer
This has been one of the best threads on the group since I have joined a few weeks back.
My $0.02 is in having recently spoken with two (OK, small dataset, I know) companies that specialize in SaaS enablement of formerly-traditional (e.g N-tier) applications. When asked how they characterize their revenue streams over the past 2 years, they both indicated that roughly half of the revenue came from large companies wanting to enable key apps to run on *internal* (e.g. company owned) compute clouds. The other half was from ISV's looking to (re)deploy their software now a software-as-a-service on most-likely externalized clouds. The latter stated "external" clouds only in that they were not interested in hosting and managing the infrastructure portion of the cloud capability.
Steve
Jan Klincewicz
Apparently there are a number of definitions of SaaS as well. I had always thought of apps like Salesforce.com or Webex to be Saas since you just subscribe to them..
Definitions of SaaS on the Web:
- Software
as a service (SaaS, typically pronounced 'Sass') is a model of software
deployment where an application is hosted as a service provided ...
en.wikipedia.org/wiki/SaaS - A
modern software deployment approach where the application runs on the
vendor's servers and all customer use is via a web browser.
omniupdate.com/assets/glossary/ - A
software delivery model in which a software firm provides daily
technical operation, maintenance, and support for the software provided
to their ...
www.oracle.com/profit/features/060807_Ondemand_gloss.html - Software as a Service is subscription based, and all upgrades are provided during the term of the subscription. ...
dts.utah.gov/egov/webstandards/guide/13-0/13-0.html - is
the name applied to on-demand computing services, normally delivered as
a one-to-many model (single instance, multi-tenant architecture) rather
than the traditional, on-premises one-to-one model.
simpleweb.squarespace.com/jargon-buster/
Cheers,
Jan
Jan Klincewicz
Apparently there are a number of definitions of SaaS as well. I had always thought of apps like Salesforce.com or Webex to be Saas since you just subscribe to them..
Definitions of SaaS on the Web:
- Software
as a service (SaaS, typically pronounced 'Sass') is a model of software
deployment where an application is hosted as a service provided ...
en.wikipedia.org/wiki/SaaS - A
modern software deployment approach where the application runs on the
vendor's servers and all customer use is via a web browser.
omniupdate.com/assets/glossary/ - A
software delivery model in which a software firm provides daily
technical operation, maintenance, and support for the software provided
to their ...
www.oracle.com/profit/features/060807_Ondemand_gloss.html - Software as a Service is subscription based, and all upgrades are provided during the term of the subscription. ...
dts.utah.gov/egov/webstandards/guide/13-0/13-0.html - is
the name applied to on-demand computing services, normally delivered as
a one-to-many model (single instance, multi-tenant architecture) rather
than the traditional, on-premises one-to-one model.
simpleweb.squarespace.com/jargon-buster/
--
Cheers,
Jan
Matthew Zito
I think of an internal cloud a lot like the stereotypical compute grid – I have 5,000 servers running Hadoop, or Gigaspaces, or whatever, and any group of developers can simply push a job onto that grid, have it parallelized as much as possible/appropriate, and the results returned.
I don’t know if that warrants a definition separate from “Grid”, but that seems basically identical to an external cloud.
Matt
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Jan Klincewicz
Sent: Friday, January 23, 2009
4:52 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re:
Is "Internal Cloud" an oxymoron ?
I think I am still struggling with what makes an internal data center a "Cloud." Where is the "cloudiness?" Can you explain what they meant by customers wanting to "enable key apps to run on internal compute clouds"? I'm not trying to argue, but I am very curious as to how this differs from traditional App delivery.
Jan Klincewicz
Cheers,
Jan
Matthew Zito
It seems, at least from my FinServ customers, that when they have dedicated, centralized, compute grids, they don’t bother with hypervisor-style virtualization. After all, the boxes are all single-purposed, and the whole point of the grid is to maximize utilization as much as possible – if you need a hypervisor to collapse multiple VMs onto one physical to get that utilization, you’re doing something wrong.
And I agree that the whole definition of a “cloud” gets more complicated with these kind of scenarios. I like to think of “cloud” as any multi-tenant, centralized, abstracted, infrastructure – hence it embodies stereotypical compute grid applications.
Thanks,
Jan Klincewicz
What was cool about Beowulf clusters was that only the master node needed a disk, and the slave images were provisioned over the network and were essentially hardware-independent (or agnostic.) Naturally, since I sold servers for HP at the time, I wasn't thrilled about this technology making my highly-proprietary servers unnecessary, but I couldn't help but be in awe of the concept. This DID utilize resources very efficiently.
For the hardware agnosticism alone, I'd have to agree that an "Internal Cloud" based on such a model is very valid in terms of fitting the definition.
One also has to realize that this architecture does not necessarily fit all types of applications, but nonetheless, I will consider my mind broadened.
Thanks !!
Cheers,
Jan
Miha Ahronovitz
1. What is the difference between grid and a cloud?
2. What is the difference between internal users and external users?
3. What is the difference between a data center and a cloud?
This is my angle. Answers:
1. A classic Grid is not elastic. It will not add more servers or resources to the service more in demand.
A cloud will automatically expand and shrink according to the demand
A grid user must be sophisticated enough to submit a job. They are not insulated from the grid complexity
A cloud user ideally talks via GUI and is agnostic what is going on behind the screen.
2. Lets have a cloud and select who has access to what, who pays and who does not pay, (but their bill is added to the cloud operations costs).
The internal users are just an arbitrary group well defined for specific apps not available to outsiders
3. A data center is not elastic. A data center plus access to virtualized resources is a cloud.
Unlike a Data Center,- which is designed for top workload, and it is idle 80% most of the time, -
a Cloud can respond rapidly to peaks in demand and will save tons of money, with better response time
A cloud can consolidate 2 or 100, and one day thousands of data centers, with huge economies of scales.
The final picture of clusters is this: users work on simple GUI and don't care what it is behind them, they always have a satisfactory responses.
This users are employees, customers, partners and the entire business ecosystem in specific regions.
Whether CC as described above will be one single cloud worldwide, this is not a technology issue. This is sociological and human question.
This is why we have separate countries, United Nations, 50 states in USA, separate armies, separate religion, yet we all live in peace as much as possible
All the technologies described and discussed on this group are contributors to this vision and are implementation details.
Some of the technologies will dominate allow building clouds and joining other clouds easily.
my 1 cent
Miha
From: Matthew Zito <mz...@gridapp.com>
To: cloud-c...@googlegroups.com
Sent: Friday, January 23, 2009 2:01:12 PM
Matthew Zito
I can, anonymizing the folks involved, obviously. You hit on some of the players involved – Beowulf was sort of the first generation of distributed computing. One of the considered issues with it was that the development interface was limited, and it didn’t handle multi-tenancy very well. It was fine as a very low-cost replacement for a traditional academic/scientific supercomputer, but there’s features and functionality that were considered lacking. Then, you had some of the initial job distribution players, the earliest one being Platform computing, with their LSF product. LSF was a distributed job scheduler – you could take your existing app and its data, and kick it off to run on a farm of servers. You didn’t need to worry about copying the data around, or starting the job, or aggregating the results, that was all done for you. Then, the next generation of companies came along – companies like DataSynapse, where instead of writing an app that was partitionable and having a centralized job scheduling facility, products like DataSynapse actually offered an API, so you coded/integrated your app directly against the platform. This allowed for much more advanced processing – app nodes could actually do some state-sharing, and it was possible to do intermediary updates, etc., none of which were possible without all sorts of gyrations in the past.
Then, the concept of “grid” really came along, and you had a whole rush of folks jumping on the bandwagon (*cough* looks at own company’s name *cough* ), while the definitions weren’t really standardized. Then standards bodies, etc. came along, and some standards were implemented that no one cared about except the vendors. There’s a pile of vendors in this space, all of them with a slightly different slant, but all with the same concept – take a farm of independent nodes and distribute work amongst them in such a way that performance and utilization are optimized within the resources.
BUT – you ask about specific implementations I’ve seen. At one company, there’s a 10,000 processor transactional grid doing financial simulations. Developers simply write a library describing the simulation that they want to be run, assign a priority, and hit “go”, and the job is executed on some quantity of the 10k servers. When I saw this infrastructure, it was multiple gigabit Ethernet links per machine, but they were talking about moving to InfiniBand, I don’t’ know if they did.
Another company had proofed out a 1000-server storage grid, where data nodes exported storage to worker nodes, which spoke to the actual apps. Applications in the organization would request to store an object (think something like a Hibernate), and the worker nodes would accept the object, and store it on one or more data nodes.
The interesting thing about these apps versus some of the uses for an external cloud is the persistence. One of the classic value-add examples of ec2 plus S3 is how the NY Times did a ton of image processing for <$100k, when the estimates to do it in-house were in the millions. For them, they simply don’t do enough compute to make it worth their while to make a long-term investment in building it themselves. At a lot of large IT environments, though, they’ve got enough continuous compute requirement in certain parts of their environments that outsourcing the cloud might actually be more expensive than doing it themselves.
Miha Ahronovitz
M
Ioan Raicu
Miha Ahronovitz wrote:
This brings three questions:
1. What is the difference between grid and a cloud?
http://people.cs.uchicago.edu/~iraicu/publications/2008_GCE08_Clouds_Grids.pdf
2. What is the difference between internal users and external users?
3. What is the difference between a data center and a cloud?
This is my angle. Answers:
1. A classic Grid is not elastic. It will not add more servers or resources to the service more in demand.
More details about Falkon and dynamic resource provisioning can be found at:
http://dev.globus.org/wiki/Incubator/Falkon
http://people.cs.uchicago.edu/~iraicu/publications/2007_SC07_Falkon.pdf
We have a more recent paper that is still under review that shows how well the dynamic resource provisioning can adapt to varying workloads. If anyone wants to see the draft of this paper, let me know and I can send it to you offline.
A cloud will automatically expand and shrink according to the demand
A grid user must be sophisticated enough to submit a job. They are not insulated from the grid complexity
In summary, while elasticity and easy to use front ends weren't in the original specs of Grids from a decade ago, they are making inroads in todays Grids for sure; these new techniques haven't made their way into production Grid systems yet, but we have real users that are using our research systems (i.e. Falkon) with great success, and with time, I am sure these research systems will make their way into production when they are ready and mature. It is true, that Clouds take both of these features, elasticity and easy to use front ends for granted, and are part the the Cloud definition (at least according to my definition).
So, in a sense, Grids and Clouds are quite similar, today, in terms of goals. Where they differ is in implementations, technical details, and most likely the target audience, which implies different workloads as well. The article I mentioned above goes into the various differences in the architecture, business model, resource management, programming model, application model, and security.
http://people.cs.uchicago.edu/~iraicu/publications/2008_GCE08_Clouds_Grids.pdf
Cheers,
Ioan
-- =================================================== Ioan Raicu Ph.D. Candidate =================================================== Distributed Systems Laboratory Computer Science Department University of Chicago 1100 E. 58th Street, Ryerson Hall Chicago, IL 60637 =================================================== Email: ira...@cs.uchicago.edu Web: http://www.cs.uchicago.edu/~iraicu http://dev.globus.org/wiki/Incubator/Falkon http://dsl-wiki.cs.uchicago.edu/index.php/Main_Page =================================================== ===================================================
Sankar Nagarajan
Internal clouds in my viewpoint may help enterprises especially large
ones to
a) Derive more efficiencies out of their computing assets (Lower
TCO,Improve or Optimise ROI)
b) Optimise the performance of their application portfolio
c) Optimise their IT operational tasks (multiple OS
admin,licensing,management etc)
As technologies and tools mature in this area,a number of companies
may want to leverage the benefits of having an internal cloud.
Sankar Nagarajan
http://www.linkedin.com/in/nsk007
Bernard Golden
project is $240, which is even more dramatic (the guy who did it put
it on his credit card). The fellow who did the project gave a talk at
OSCON last year; I'm checking to see if O'Reilly has the slides posted
or if I can get a copy. If it turns out the slides can be made
available, I'll post a link here.
I don't know that the internal quoted cost was in the millions, tho. I
think what drove this was that the project was going to take a long
time to get provisioned internally and the guy is kind of a hacker who
was personally interested and technically capable of doing the
project.
Overall, the project highlights some key drivers for use of an
external cloud: quick availability of resources, ability to scale
transitory resources without needing to have those resources
permanently provisioned (i.e., owned and on the books of the
organization), and internal skills and interest in using a different
application delivery vehicle.
Matthew Zito
It's different strokes for different folks, obviously - I knew companies that moved from LSF to DataSynapse simply because LSF didn't have an API that would allow them finer-grained control over what was happening. I'm also sure there were companies that didn't want to be development shops, they just wanted partitioning of workloads - they stayed with LSF or one of the other companies that focused on that.
Matt
-----Original Message-----
From: cloud-c...@googlegroups.com on behalf of Miha Ahronovitz
Sent: Fri 1/23/2009 11:30 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
DataSynapse actually offered an API, so you coded/integrated your app
directly against the platform. This allowed for much more advanced
processing - app nodes could actually do some state-sharing, and it was
possible to do intermediary updates, etc., none of which were possible without
all sorts of gyrations in the past.
This is a big drawback of Data Synapse, as it requires access to the source code of an application. No problem for in-house applications like financial institutions using their own algorithms. But for of the off-the-shelf 3rd party applications this is a real issue. SGE and LSF and PBS do not require access to the source code at all.
M
________________________________
From: Matthew Zito <mz...@gridapp.com>
To: cloud-c...@googlegroups.com
Sent: Friday, January 23, 2009 4:03:32 PM
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
I can, anonymizing the folks involved,
obviously. You hit on some of the players involved - Beowulf was
sort of the first generation of distributed computing. One of the
considered issues with it was that the development interface was limited, and
it didn't handle multi-tenancy very well. It was fine as a very
low-cost replacement for a traditional academic/scientific supercomputer, but
there's features and functionality that were considered lacking. Then,
you had some of the initial job distribution players, the earliest one being
Platform computing, with their LSF product. LSF was a distributed job
scheduler - you could take your existing app and its data, and kick it
off to run on a farm of servers. You didn't need to worry about
copying the data around, or starting the job, or aggregating the results, that
was all done for you. Then, the next generation of companies came
along - companies like DataSynapse, where instead of writing an app that
was partitionable and having a centralized job scheduling facility, products
like DataSynapse actually offered an API, so you coded/integrated your app
directly against the platform. This allowed for much more advanced
processing - app nodes could actually do some state-sharing, and it was
possible to do intermediary updates, etc., none of which were possible without
all sorts of gyrations in the past.
Then, the concept of "grid"
really came along, and you had a whole rush of folks jumping on the bandwagon
(*cough* looks at own company's name *cough* ), while the definitions
weren't really standardized. Then standards bodies, etc. came
along, and some standards were implemented that no one cared about except the
vendors. There's a pile of vendors in this space, all of them with
a slightly different slant, but all with the same concept - take a farm
of independent nodes and distribute work amongst them in such a way that
performance and utilization are optimized within the resources.
BUT - you ask about specific
much as possible - if you need a hypervisor to collapse multiple VMs onto
one physical to get that utilization, you're doing something wrong.
And I agree that the whole definition of a "cloud"
gets more complicated with these kind of scenarios. I like to think of
"cloud" as any multi-tenant, centralized, abstracted, infrastructure
- hence it embodies stereotypical compute grid applications.
Thanks,
Matt
________________________________
From:cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Jan Klincewicz
Sent: Friday, January 23, 2009
5:19 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re:
Is "Internal Cloud" an oxymoron ?
Well, that is certainly ABSTRACTED .. that in itself
is "cloudy." I assume this does not make use of
traditional virtualization (as we tend to think about it ... with
hypervisors.." Great response, even if it makes the definition that
much harder to achieve .. :)
On Fri,
Jan 23, 2009 at 5:01 PM, Matthew Zito
<mz...@gridapp.com>
wrote:
I think of an internal cloud a lot like the stereotypical
compute grid - I have 5,000 servers running Hadoop, or Gigaspaces, or
whatever, and any group of developers can simply push a job onto that grid,
have it parallelized as much as possible/appropriate, and the results returned.
I don't know if that warrants a definition separate from
"Grid", but that seems basically identical to an external cloud.
Matt
________________________________
From:cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Jan Klincewicz
Sent: Friday, January 23, 2009
4:52 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re:
Is "Internal Cloud" an oxymoron ?
I think I
am still struggling with what makes an internal data center a
"Cloud." Where is the "cloudiness?" Can you
explain what they meant by customers wanting to "enable key apps to run on
internal compute clouds"? I'm not trying to argue, but I am very
curious as to how this differs from traditional App delivery.
Apparently there are a number of definitions of SaaS as well. I had
always thought of apps like Salesforce.com or Webex to be Saas since you just
subscribe to them..
Definitions
of SaaS on the Web:
* Software as a service (SaaS, typically pronounced 'Sass') is a model of software deployment where an application is hosted as a service provided ...
en.wikipedia.org/wiki/SaaS
* A modern software deployment approach where the application runs on the vendor's servers and all customer use is via a web browser.
omniupdate.com/assets/glossary/
* A software delivery model in which a software firm provides daily technical operation, maintenance, and support for the software provided to their ...
www.oracle.com/profit/features/060807_Ondemand_gloss.html
* Software as a Service is subscription based, and all upgrades are provided during the term of the subscription. ...
dts.utah.gov/egov/webstandards/guide/13-0/13-0.html
* is the name applied to on-demand computing services, normally delivered as a one-to-many model (single instance, multi-tenant architecture) rather than the traditional, on-premises one-to-one model.
Bernard Golden
that:
1. There is the question of total capacity required to address peak
demand (Jan's original point), and the potential for resources lying
fallow and tying up corporate capital, certainly not desirable, and
potentially a career-limiting move for the CIO. Large organizations
(e.g., Johnson and Johnson might have sufficient aggregate demand to
avoid this problem, but managing internal resources to achieve optimum
use -- perhaps 80%, with some in reserve? -- would be challenging)
might be able to address this issue, but I doubt that SMEs would, nor
would they be willing to tie up capital in this fashion.
One might expect this issue of aggregate demand to be even greater if
agile self-service for internally provisioning instances (one of the
oft-stated goals for internal clouds) increases aggregate demand. This
might very well be expected: reduce the friction for obtaining
resources and one can expect that more resources will be demanded. On
the other hand, one of the objections I hear posed about EC2 is
precisely the same one: how will Amazon keep sufficient capacity
available when everyone begins using EC2, and won't Amazon face the
same issues and it faces capital constraints, too.
2. The question of needing to keep cloud-based computing services
internal due to data privacy, etc. is an interesting one. There are
certainly laws and regulations that impinge the ability to locate data
outside of the organization's control, and also concerns about
important business data being more vulnerable when stored somewhere
else; however, the success of SaaS vendors like salesforce indicates
that organizations are willing to store important data (e.g., customer
information) outside their own data centers. There is perhaps a
reflexive assertion that because some data is critical, all data
should be treated as if critical, and therefore kept within an
organization's own data center. A more sophisticated approach would be
to assess the importance of internal storage of different data sets
and determine which can be stored in an external cloud and which must
be kept internally. That implies a risk assessment, which requires
additional work not currently performed, and there is a natural
inclination to avoid new work, so it's easier to just keep operating
under the same old assumptions. Not to toot my own horn, but I am
currently writing a series of blog posts for my blog on CIO on "The
Case Against Cloud Computing," and the next post will be on this issue
of data risk (see http://www.cio.com/article/477473/The_Case_Against_Cloud_Computing_Part_One
if you're interested).
3. The lack of enthusiasm on the part of many IT organizations to
embrace external clouds due to the putative risk might be attributed
to risk asymmetry they face. That is to say, they can get into a lot
of trouble if something goes wrong about data, but there isn't that
much upside for implementing a risk assessment process and reducing
costs by leveraging outside cloud resources. One might say IT
organizations are paid to be the worrywarts regarding data security,
which isn't really that much fun, but would affect their perspective
on risk and could motivate them to be very conservative on this
subject.
4. Finally, regarding the disdain for external clouds, this quote from
Sinclair Lewis is perhaps relevant: "It is difficult to get a man to
understand something when his salary depends upon his not
understanding it." For many people, embracing a concept that will
reduce costs (and budget under control) and total headcount is
distasteful and perhaps career limiting. So why embrace it? Instead,
why not point out potential flaws in it? Or how the organization
itself can do it just as well? Jan's examples are instructive. I'm
confident that every one of those organizations whose domain is now
outsourced insisted that their function was critical and needed to be
performed internally by them. They ended up not having a choice in the
matter, however, as the drive to efficiency caused the parent
organization to select an outsourced option. It's quite possible the
same phenomenon will happen with IT regarding cloud computing: the
demand to reduce costs -- particularly in such a terrible economic
climate -- will motivate CEOs and CFOs to impose external cloud use
over the protestations of internal IT groups. When the CEO and the CIO
hold different opinions about doing things a certain way, the CEO
generally prevails, with a new CIO more sympathetic to the new
approach being employed.
So doesn't it make more sense to explore use of external clouds and
identify key issues and ways to address them rather than asserting
that they're unacceptable due to the need for data security? My
recommendation would be to develop a policy regarding data to identify
that which must be kept internally and that which may be stored
externally. Develop an internal cloud to leverage agility and IT
responsiveness and use the policy to determine which apps must operate
on the internal cloud while recognizing that some apps might be hosted
externally all the time or be migrated from the internal cloud to an
external cloud if necessary -- put another way, have a local cache of
internal cloud resources and be able to 'tag' some applications as
needing to reside permanently in the internal cloud cache while others
could migrate as needed. Blindly asserting that data security
requirements preclude use of external clouds is a self-defeating
strategy as it raises the probability that IT will be bypassed and
data that really shouldn't be externally stored will be.
Well, I'm really glad this topic got raised, since I think I just
wrote my next blog posting!
Jim Houghton
Miha,
I respectfully suggest you refresh your understanding of DataSynapse’s current capabilities, you are referencing their GridServer product set which at this point is at least 8 years old (a lifetime for software). For several years now they have offered a product called FabricServer, which essentially sits above the pool of applications (COTS or developed in-house) and provisions or takes away resources from that application based on its required service levels, the pool of compute resources it has at its disposal, and the relative priority of 1 app versus another. It is NOT in the execution path of the application, nor does it require access to the source code. It does require some simple app packaging up front, but they provide a Studio to simplify that process. After that it can deploy to any set of compute resources (inside your data center or not) that you’ve given it access to – including deployment of/to VM’s or to a non-virtualized server.
The schedulers you reference below are based on a 10+ year old deterministic approach to managing a finite set up compute resource to execute large HPC workloads. I would argue that with the situation has shifted 180 degrees since then; we now have thousands of cheap (but powerful) compute capacity at our disposal along with a large number of applications, most of which require less than 1 CPU to operate the vast majority of the time. A static scheduler applied to non-HPC workloads is a recipe for highly underutilized resources.
Jim
(to head off any advertising complaints, no I do not work for DataSynapse…)
Miha Ahronovitz
Many thanks for the references provided. No wonder this group is populated by many grid experts. You defined the cloud as follows:
driven by economies of scale, in which a pool of
abstracted, virtualized, dynamically-scalable, managed
computing power, storage, platforms, and services are
delivered on demand to external customers over the
Internet.
How will you update the Cloud definition above, in light of the very rich debate on this group?
In my opinion:
The large-scale is not a limiting factor. The ease of use should be in the definition.
The ease of use means users who have not clue what clouds are using them
(like driving a car without knowing nothing about engine, transmission, etc,
typical of the 99.9% of the drivers today.)
M
From: Ioan Raicu <ira...@cs.uchicago.edu>
To: cloud-c...@googlegroups.com
Sent: Saturday, January 24, 2009 6:49:43 AM
Ioan Raicu
Its always tough to come up with a 1 sentence definition of a concept that now embodies an entire industry sector. Nevertheless, we did try :) About extending the definition with "ease of use", yes, we could. I think the paper's message is that one of the Clouds motivation was to lower the entry barrier costs to large-scale distributed systems. At least today, I believe the end users of Grids and Clouds do not have much overlap, with Grid users being power users, and Cloud users being the average person who knows little about distributed systems. Over time, this will likely change. Now, about how to build and make Grids or Clouds a reality, the challenges are similar, and the people involved are just as tech savvy on both ends, Clouds and Grids. I just wanted to clarify that the "ease of use" only applies to the end user using the Cloud (vs. Grid), and not to the people that are working on the Cloud and Grid middleware to enable end-users to do their work.
Cheers,
Ioan
mij...@sbcglobal.net
Thanks for the update for Data Synapse..
SGE 6.2 has the new Service Domain Manager. It adds or removes hosts from services according to SLAs (service level agreements) based on SLO ( sl objectives), which are measurable.
See sun.com/sge
We have installations with parallel applications running on 60,000 cores.
This is at today standards, mind boggling.
The fabric server is realy a very nice framework, rather than a product that works off the shelf. It is very succesful in financial industryn predominatly
Kindly update me again if I missed latest information
Thanks,
Miha
Sent from my Verizon Wireless BlackBerry
From: "Jim Houghton"
Date: Sat, 24 Jan 2009 11:19:36 -0500
R Chishty
> Date: Sat, 24 Jan 2009 06:54:25 -0800
> Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
Ray Nugent
He doesn't say what it would have cost or what it did cost but you can do the math. Assuming he uses a small EC2 machine, 100 machines for 24 hours is $240 not including storage and data transfer costs so round up to $300. Now to order, buy, provision, test and maintain 100 machines would cost in the neighborhood of $100K and take weeks if not months to work it's way through the fog of the corporate financial and IT process. so we have $300 bucks for cloud computing vs $100K for Fog Computing, 24 hours for Cloud Computing vs 30-90 days for Fog Computing (assign your own costs for time to market).
Ray
From: Bernard Golden <bernard...@gmail.com>
To: Cloud Computing <cloud-c...@googlegroups.com>
Sent: Saturday, January 24, 2009 7:14:45 AM
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
natis...@gmail.com
It looks like were still strangling with the definition of a cloud.
Most of the discussion tries to pin point an accurate technical
definition and that's probably what makes it difficult.
I'd like to approach it from an end-user value perspective i.e. what
brought many users to look at cloud computing in the first place.
Based on my experience there are two main driving force:
1. On demand computing i.e. the ability to get a resource when i need
it in matters of minutes.
2. Pay - per use i.e. the ability to pay only for what i use.
The rest is an implementation details.
From an end user perspective if it doesn't matter that much if i can
get the above value from internal or external cloud.
In my view what will see in the near future is hybrid-cloud i.e. local-
IT+ Internet Cloud. A typical scenario would be to run testing on
public cloud and production internally. There are many other scenarios
that jutifies this type of hibrid model.
The real question about private cloud is whether local-IT would ever
be able to compete with the cost and level of service of those of the
public cloud.
This is where the economy of scales plays an important role (See James
Liddle recent blog: The Economics of Cloud http://vehera.jsn-server7.com/LiddleBlog/?p=234
) i.e. the bigger the data-center is the higher the chance the cost
and level of service will get better then those of smaller data-
centers. It may very well that over time public cloud will become the
only option just like energy, however its going to take a while till
this will happen if at all.
Cheers
Nati S
www.gigaspaces.com/cloud
Jan Klincewicz
I would tend to focus more on "Business Units" than "end-users" since charge-back has never gotten THAT granular (let's hope!!) This does allow IT to shed its skin of "Cost Center" and calculate value much more accurately.
As you state, economies of scale apply, and very large IT shops may have the benefit of departments whose usage expands and contracts (like Accounting with the Quarterly and Yearly Close, and then Financial Analysis on its heels ..)
Unfortunately, until the market matures, it will still be difficult to "go outside" just for those few days, so it will still mean internal IT will have to make Capex acquisitions for the "worst case" scenarios, and those costs are sunk.
Thanks for your contribution!!
Cheers,
Jan
Jim Houghton
Thanks for one of the more thorough responses to the group on this
thread...I agree with your assessment but I feel it bears a little more
discussion about the genesis of internal clouds as it will have a lot to do
with the adoption path over the next few years.
This thread has spawned some very interesting tangents over the past week -
none are wrong but they definitely illustrate the diversity of backgrounds
we have. So as not to leave mine in doubt, I've spent much of my career in
professional consulting capacities around technology infrastructure
(strategy, architecture, & operating models) for Fortune 500 clients across
all industries. That experience undoubtedly colors my perspective as well.
The subject line for this thread "Is "Internal Cloud" an oxymoron?", while
provocative, is misleading. Many of the posts have asserted that for
something to be called a "cloud" it must be external; that I will strongly
disagree with. The majority of the clients that I've worked for had data
centers that numbered in the double digits; and a number of them even topped
triple digits. These facilities all had high speed interconnects. I've read
in many posts about how "size matters" when talking about the Cloud; if
that's the case then we certainly have circumstantial evidence of 'internal
clouds'.
The real issue is how are these resources architected, built, and managed
.... and unfortunately (or fortunately for my consulting income) by and large
they were architected as monolithic silos. These silos are aligned to
specific applications/systems, are provisioned individually to accommodate
peak loads, and stand side by side filling up every square inch of the data
center until things burst at the seams so the corporation shells out $200M
to build another facility to repeat the cycle. On average (7x24) these
systems run at 10-15% utilization, with a handful of spikes during the
day/week/month where the CPU maxed out. Of course, there are also
requirements for dedicated development, integration test, stress test,
pre-production test/UAT, and of course disaster recovery resources. So
let's add that up - thousands and thousands of servers, with average
utilization around 10% - and then multiplied by 5 for non-production
capacity (with average utilization less than 1%). It's safe to say there is
an opportunity for improvement here (this idle capacity is how Amazon
initially launched their service).
In the early 2000's people outside of the scientific community started to
realize an interesting technology developed to search for alien life in the
cosmos just might have some commercial applicability, and we saw the
explosion of grid computing. Financial Services firms, in particular,
quickly realized the competitive advantage of having better/faster pricing
and risk models by running their apps on hundreds of cheap wintel servers at
less cost than the traditional SMP servers previously employed. Problem
was, in most cases they repeated the same architectural mistake - it was "MY
grid for OTC derivatives" and "My grid for market risk"...suddenly there
were dozens of grids that were at 100% utilization for a few hours of the
day but less than 5% the rest of the time. In the ensuing years (2003-2004)
we did see what is arguably the beginning of Cloud Computing - grid
offerings from Sun, IBM, HP, and a few others where a customer could obtain
compute capacity charged by the CPU/hour to supplement an enterprises'
internal capacity. Some of those services are still available today ... and
we also had lots of fun with the security side of things back then and
managed to find ways to make it work because the economics made sense.
Now what if instead of dedicating those grids to a single app or single
department you were able to integrate them into a single pool? I've been
away from college for a long time, but I still remember the basic rules of
traffic engineering...one pool of 50 can do substantially more work than 10
pools of 5. Yes there are sometimes a few technical hurdles, but mostly
it's a cultural hurdle. Once that barrier is broken it starts to get fun,
because at this point the business users (or at least the development teams)
have gotten over the fact that they no longer have "their" servers/grid and
interesting things become possible. You can look for other workloads - not
necessarily batch - to consume the grid resources that are invariably idle
at some point. The post about the NYT image conversion is very interesting,
as that's one of the first services (image conversion, also print rendering)
that made for great "filler" applications around the primary business
workloads.
But let's move beyond grids ... in an earlier post I articulated the
benefits of DataSynapse's FabricServer product, but what's important is the
capability. If you've broken the link between the application and the
server platform, you've changed the entire paradigm of the data center. Now
when a new development project is initiated, instead of waiting around for
weeks/months to obtain a server you fill out a webform and within hours are
emailed the login to your VM. When it comes time to test, that application
image is moved from its development VM(s) to resources that resemble the
production topology. Meanwhile, those resources were configured for a
completely different application only minutes earlier (leveraging tools like
Scalent VoE you save an image of the app to the SAN and then reconfigure the
server and network connectivity to provision the new app). Once tested and
ready for production, instead of provisioning a static server or VM, you let
the service level of the application determine its runtime topology in your
large pool of production resources. And if there is suddenly an outage, you
can move the entire pool of running apps to another one of your datacenters
(again, courtesy of Scalent - with the caveat that you have SAN replication
in place). Yes, it's easier to type than do but it is absolutely possible.
I apologize for being verbose so let me net it out - in today's enterprises
it is absolutely possible to dynamically share infrastructure amongst a
large number of apps using tools to fine-tune capacity allocation at runtime
to match shifts in demand, while also using coarse grained tools for bare
metal provisioning to optimize your supply of resources (think the test
scenario, day/night workload shift, or DR). Sounds to me like what we want
to do in the Cloud...
So why the monologue - internal clouds are not an oxymoron, they are the
stepping stone to the external cloud. Until enterprises become comfortable
sharing their resources inside their own firewall, they are not going to
migrate to a model where they share with John Q. Public in a meaningful way.
This first step is sharing internally, the next step is using external
resources to augment for peak capacity (or non-strategic uses), the next
step will reverse that internal/external ratio, and the final step will be
full adoption (of course we'll still keep some capacity on-site for
emergencies, just like I keep a generator at my house).
This transition has to go through the IT organizations. Yes, there are too
many examples to list where business guys use their credit card to buy Cloud
capacity for a day to do something that would have taken IT weeks or months
to accomplish. And yes, you might have a CIO or 2 get fired by their CEO
because they refused to move things to the Cloud on the grounds of
inadequate information security ... but it'll only take 1 story on the front
page of the NY Times about data loss on the Cloud for that CEO to get fired
and that situation won't happen again (for a while).
It is an economic inevitability that in the not-too-distant future public
Clouds will provide that vast majority of computing resources for the
planet. How many people generate their own electricity today? If anyone
raised your hand it's either because the power grid is not available or not
reliable (certainly not because it's cheaper or easier to do it yourself).
Permit the gross analogy to say that "not reliable" translates to "you can't
guarantee my information security" or "you can't guarantee my end user
response time" or "you make me code my app to your API so I can't easily
move it to another provider". We obviously have a lot of work to do to
realize that future state, but ignoring the internal cloud - a critical step
on the maturity model - is foolish.
Look forward to replies ... will put my flame retardant pants on :)
Jim
Jan Klincewicz
I intentionally made this subject one that would draw controversy (of course, in this crowd, nearly anything will.)
Among my greatest joys in life is LOSING an argument, because it means that an incorrect notion I had been harboring has been corrected by someone more knowledgeable than I. Net, net, I LEARNED something, which is why I am here. I may tend to be a prolific poster, and I do have my own opinions, having been in the industry my entire adult life. I know I am entitled to them, and that others may disagree passionately, but I hope never to sink to the level of insulting another individual's ideas, please let me know and I will know it is time for me to stop posting.
Cheers,
Jan
Stuart Charlton
Sent from my iPhone
<<I don't care if it is called Cloud, Infrastructure Optimization, or Bob.>>
Let's not use Bob. Microsoft tried that one and failed pretty miserably (though Linda, the Product Manager, did end up marrying Bill Gates !)
Abraham Lincoln is credit with the following :
While giving a discourse to an audience on why slavery should be abolished, Mr. Lincoln was asked by a member of the crowd "Mr. Lincoln, if slavery is so wrong then why don't you just pass the legislation to get rid of it?"
Mr. Lincoln answered with a question: "Sir, if I call a lamb's tail its leg, how many legs will it have?".
The man answered "Five."
"No, it will still have four", replied Mr. Lincoln, "calling a lamb's tail a leg doesn't make it a leg."
Anyway, my position is that CALLING an internal IT infrastructure a "cloud" doesn't make it one.
The premise behind elasticity is that an enterprise can spin up and spin down compute resources as business needs (such as seasonality) dictate. In order to accommodate this, an IT infrastructure needs to be constructed to handle the MAXIMUM capacity, and then will lay idle the remainder of the time.
Acquiring expensive depreciable assets in this fashion DOES eliminate risk, but at a very high TCO. There are also risks inherent in investing in technologies which may obsolete prematurely.
Do you think the server sales rep, knowing he is probably looking at a work force reduction six months down the road cares if you realize the blade chassis and associated peripherals for which you are about to sign a P.O, is going end-of-life in 10 months, and the new model will not work with the blades you are just about to deploy ?
I'm not saying that any CC: providers out there NOW will be able to meet the needs of most typical organizations with CC as it exists today. Also, a mega-conglomerate like Johnson and Johnson probably has a diverse enough portfolio of organizations to scale it's internal IT to "Cloud" proportions.
I'm not looking to create a definition of CC myself, but am hoping the collective wisdom of this group will eventually achieve a consensus on what it really means.On Fri, Jan 23, 2009 at 12:29 PM, <xd...@comcast.net> wrote:
Before I dive in, a few disclaimers: I work for a large corp with
over 300k nodes (counting desktops) and I work in IT, though if we
adopt Cloud my job is largely not impacted by that decision. I wanted
to provide this context so you could read my thoughts below and
possibly get the context I'm coming from.
I think your projected rationale for the IT might be way off.
Internal Cloud makes sense in two very distinct ways:
1) We have more physical assets than many companies, and still need
to manage cost and efficiency. Cloud architectures (even if operated
internally) provide notable promises for agility (time to market,
rapid analysis and prototyping, on-demand scale up or down from the
application view), cost effectiveness (consolidation and workload
management across physical resources), and staffing and facilities
saves through these efficiencies. Even if I NEVER engage an external
anything to do this. Granted I might be able to save more if I engage
external hosting partners in my facilities and support and
infrastructure costs, but it isn't required for me to save money, and
there are currently lots of possible issues with externalized shared
infrastructure models.
2) Risk. Simply put, moving processing of some data loads externally
generates some notable changes in our risk analysis. Some workload
may never be moved due to sensitivity of the data, others due to lack
of sufficient liabilty agreements from vendors, others due to legal
and regulatory pressures. The risk provides the counter balance to
the cost and drives some workloads back internally, but that shouldn't
restrict my thinking to avoid Cloud behaviors and benefits generated
by operating internal systems more "cloud-like".
I don't care if it is called Cloud, Infrastructure Optimization, or
Bob. I want the properties and behaviors of Cloud Computing to
generate the speed and cost results needed both internally and
externally, and be able to make my decisions on workload movement
based on the cost risk factors, not on the name or technology that
makes it work. I think you are right that the key to what I need is
abstraction at the various levels, and current best single name given
to what I want is Cloud (at least that's the one my management
understands so I'm going with it).
None of these decisions are based on job retention or self-serving,
short-sightedness, but rather the balance between cost and risk for
the good of the overall corp. If possible I'd want it risk free, cost
free, and now, but hey I'm not THAT out of touch (yet) :)
On Jan 22, 4:05 pm, Jan Klincewicz <jan.klincew...@gmail.com> wrote:
> An "Internal Cloud" sounds to me like a cop-out for IT people who want to
> keep their jobs doing mundane infrastructure maintenance so they tell the
> higher-ups that they can do a "Cloud" in-house just to satisfy their want
> for "something different." "In-sourcing" became a popular phrase when
> outsourcing threatened the status quo.
>
SNIP
>
> I think what makes Cloud Computing
> "cloud-like" is the abstraction of workloads from the physical compute
> resources.
--
Cheers,
Jan
Stuart Charlton
So why the monologue - internal clouds are not an oxymoron, they are the
stepping stone to the external cloud. Until enterprises become comfortable
sharing their resources inside their own firewall, they are not going to
migrate to a model where they share with John Q. Public in a meaningful way.
This first step is sharing internally, the next step is using external
resources to augment for peak capacity (or non-strategic uses), the next
step will reverse that internal/external ratio, and the final step will be
full adoption (of course we'll still keep some capacity on-site for
emergencies, just like I keep a generator at my house).
It is an economic inevitability that in the not-too-distant future public
Clouds will provide that vast majority of computing resources for the
planet.
How many people generate their own electricity today? If anyone
raised your hand it's either because the power grid is not available or not
reliable (certainly not because it's cheaper or easier to do it yourself).
Ray Nugent
"Among my greatest joys in life is LOSING an argument, because it means that an incorrect notion I had been harboring has been corrected by someone more knowledgeable than I."
From: Jan Klincewicz <jan.kli...@gmail.com>
To: cloud-c...@googlegroups.com
Sent: Saturday, January 24, 2009 4:38:19 PM
Jan Klincewicz
I can't imagine a lot of CIOs today are approving Superdome purchases with ICOD. The rate HP charges to "lease" you an incremental off-the-shelf Itanium should be a criminal offense.
I can understand your point in normal times, but with current economic conditions trying to get capital budget for "excess" capacity will likely be a hard sell even it makes good sense.
Cheers,
Jan
Jan Klincewicz
Cheers,
Jan
Stuart Charlton
It is a good idea for test & dev servers to be put into use to accomodate seasonal fluctuations. However, in a modern, highly virtualized shop, these machines no longer represent a lot of spare capacity.
- Most IT shops are not highly virtualized yet, even the "modern" ones. This is changing, of course....
- I've observed many a production outage because the organization could not allocate the resources to perform an adequate stress test of major changes, and the budget to acquire such an environment *for the purposes of that project* would have been prohibitive.
- I have seen two poles of behaviours with IT organizations related to dev/test: either dev/test is ignored and teams have to scavenge for resources, or huge amounts of idle capacity are tagged as dev/test. Both have major consequences, though usually the former is much worse.
I can't imagine a lot of CIOs today are approving Superdome purchases with ICOD. The rate HP charges to "lease" you an incremental off-the-shelf Itanium should be a criminal offense.
That depends on how big of a bat you bring to negotiations :)
I can understand your point in normal times, but with current economic conditions trying to get capital budget for "excess" capacity will likely be a hard sell even it makes good sense.
So, basically, you're saying that an enterprise won't invest into projects that require excess capacity because of the capital requirements?
I suppose if they were really failing in the current conditions, there would be a capex freeze, but otherwise I would consider the change in investment would mostly be a stronger benchmark of the short-term NPV impact that's required of such an investment.
If enterprises were to freeze capital expenses, that doesn't bode well for many cases that require capital investment in excess capacity (almost any major transformation):
- good ol' data center consolidation via virtualization
- SOA transformations (that still seem to be going on despite it being kind of dead in the trade press)
- Infrastructure clouds, public OR private (if you're not comfortable doing it in house, good luck trusting an outside provider, unless you're a rogue group with a credit card)
- Cisco's nascent cloud server business (you're going to rely on it day one? more likely you'll bring in some excess for pilot projects).
I don't expect a whole sale jump into any of the above, but I do expect some early adoptors getting into the act if they can see a positive NPV with a (say) 12-24 month window....
Cheers
Stu
Ray Nugent
Jan Klincewicz
I had already realized my days in physical servers were numbered when some of my customers forcasted ZERO new server purchases for 2008 in favour of virtualizing the 2007 purchases.
Since I made an intentional career move to the Virtualization software biz, I also tend to see customers who have already bought into virtualization in a big way.
I actually BENEFIT from capex freezes when customers decide to get better utilization from their existing servers. In most shops I see (right or wrong) there ARE huge capex freezes due to current economic conditions (in addition to enormous layoffs and other cost-cutting measures.)
I'm not saying this is good thing, but I am certainly not seeing any "investment" in "excess capacity" and don't see a whole lot forecast until the current times change. We are in extraordinary times, and I doubt there is a lot to be gained from trying to hypothesize what "normal" behavior is (or should be) given the grave reality of current circumstances.
Though, I suspect at the end of any given quarter, you COULD wheedle some extra ICODs into your contract from your HP BCS rep...
Cheers,
Jan
Frank D. Greco
>In my view what will see in the near future is hybrid-cloud i.e. local-
>IT+ Internet Cloud. A typical scenario would be to run testing on
>public cloud and production internally. There are many other scenarios
>that jutifies this type of hibrid model.
Totally agree Nati. In the long-term *perhaps* production systems for
large enterprises will move to an external cloud. In the near/middle
term, test/dev environments are ripe for external clouds as long as
the proper precautions about data security are addressed.
At a large investment bank (remember those?) several years ago,
I was responsible for moving components of a fixed income analytics
system to an external data center run by a large well-known
systems company. This was done to address over-capacity usage.
Effectively it was a primitive "inside-the-firewall cloud", ie,
low-ceiling clouds... ;)
Much of the focus was on: reducing the network/data latency
as much as possible, software licenses for the cloud machines
and last, but definitely not least, was data security.
My former employer was paranoid about data security for good reason.
I'm sure other large corporations would have the same stance.
Part of our agreements with our external customers mandated the
data would never be "co-mingled" (actual lawyer verbiage in our
contract) with other customers on the same physical machine. This
defeats much of the economies of scale advantages of the
IaaS provider.
Cloud providers should probably avoid this type of agreement
in their contracts.
In the end, we had our external site working fine. However, the costs
were *very* high. Network plumbing, data security products,
renegotiating software licenses, telecom provider costs, replication
of data to the external site (to minimize latency) and not
to mention the additional cost of the infrastructure-service provider.
Just some anecdotal info to add to the discussion...
>The real question about private cloud is whether local-IT would ever
>be able to compete with the cost and level of service of those of the
>public cloud.
Many corporations believe that their spin on IT is what differentiates
them from their competition. One can argue that this philosophy
was the driving force behind the creation of cloud services in the
first place. Would Google and Amazon have used an IaaS service?
It was their belief that they could do it better than anyone.
I first heard about utility (ie, cloud) computing from Bill Joy
in the late 90's. Even Bill said some large companies will continue
to use their IT as a competitive weapon. But he did say a large
segment of businesses would leverage utility computing. Bill Joy
is rarely wrong... ok... the invention of the c-shell wasn't
exactly that great... ;+
>This is where the economy of scales plays an important role (See James
>Liddle recent blog: The Economics of Cloud
>http://vehera.jsn-server7.com/LiddleBlog/?p=234
>) i.e. the bigger the data-center is the higher the chance the cost
>and level of service will get better then those of smaller data-
>centers.
Having a very large data center means you need another large
data center
as a DR site. It may be better to have families of data
centers working
in a federation. It will be interesting to see how well Sun
Microsystems
manages their Q-Layer acquisition and virtual data-centers notion.
We can draw analogies to the power-grid, but at a certain point, this
analogy doesn't apply. Sort of like the common "a GUI is just like
a car dashboard" and "building software is like building a house"...
yeah it is... but yeah it isn't...
> It may very well that over time public cloud will become the
>only option just like energy, however its going to take a while till
>this will happen if at all.
Totally agreed Nati. I'm not 100% convinced it will be the
only option
for all companies in the long run.
The difference between cloud-based IaaS and the energy
grid is software. Software innovation has a *long* way to
go before its
mature like our energy infrastructure. Besides, large
public cloud utilities
eventually will act like internal IT when many customers
share the same
virtual/physical infrastructure. :)
Frank G.
Ricky Ho
User's concern:
============
- Total cost of ownership
- Speed to deploy/undeploy infrastructure resources to meet changing business workload
- Data sensitivity protection and audit compliance
- Reliability and QoS guarantee
Provider's concern:
===============
- Efficient use of underlying infrastructure, usually achieved by physical sharing with logical isolation between tenants ("Virtualization" is a common means to achieve that).
- Efficient resource scheduling tool that can handle dynamic regrouping of resources based on temporary usage patterns.
- Efficient management tools that can keep track of the health, ease the debugging in a highly distributed and virtualized environment.
Note that I haven't said whether the provider is the in-house IT or a public cloud provider because I don't think this is an important distinction. I also believe "enterprise cloud" will be competing with "public cloud" for a while. And a public cloud will always have the advantage of economy of scale and operation expertise while an enterprise cloud will always have the advantage when data sensitivity is a concern.
I also think reality of cloud computing for large enterprise is always a hybrid environment. It will be very useful to get some guidelines from this expert group on what should be put on the public cloud versus enterprise cloud, and how does components living in different domains can communicate with each other in a secure way.
Rgds,
Ricky
----- Original Message ----
From: Frank D. Greco <fgr...@javasig.com>
To: cloud-c...@googlegroups.com
Sent: Sunday, January 25, 2009 2:10:47 PM
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
mij...@sbcglobal.net
A user shouldn't have any concerns other than how much it costs, assuming he uses the right cloud provider.
Miha
Sent from my Verizon Wireless BlackBerry
From: Ricky Ho <rickyp...@yahoo.com>
Date: Sun, 25 Jan 2009 16:46:42
To: <cloud-c...@googlegroups.com>
R Chishty
> To: cloud-c...@googlegroups.com
> Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?
> Date: Mon, 26 Jan 2009 04:56:34 +0000
Ricky Ho
I also think other than cost, the users are concerning about ...
- Data sensitivity protection and audit compliance
- Reliability and QoS guarantee
Pietrasanta, Mark
Yes, that people keep saying “more expensive on-site approach”, which is rarely the case.
EC2, for example, is substantially more expensive than any on-site approach, and still requires all the same IT staff since EC2 offers almost no offloading of IT resources. By almost every measure it’s significantly more expensive (except in peripheral education and research cases).
For hosting providers and mini-clouds, these can usually be less expensive than the typical managed services offering, but still more expensive than an on-site solution. It all depends on your on-site needs and scale.
In any case, cost does not appear to be a determining factor, at least today.
And then SLA is a joke – EC2 has an SLA that would make even the most accepting legal department run away with their hand in the air.
> </html
Ricky Ho
For large enterprises, the compelling usage of CC in my opinion is "occasional usage". Such as ... buffer for workload spike, experimenting new ideas, or disaster recovery. They shouldn't expect cost saving by outsourcing their stable workload handling to a cloud provider.
For startups, CC is very compelling so they don't need to pay the infrastructure setup cost at the beginning.
Rgds,
Ricky
From: "Pietrasanta, Mark" <Mark.Pie...@aquilent.com>
To: "cloud-c...@googlegroups.com" <cloud-c...@googlegroups.com>
Sent: Monday, January 26, 2009 6:30:34 AM
Kurt Milne
Ricky – let me build on your idea of experimentation.
Business managers like to experiment. Ie lets try offering bonzoberry flavored baby formula in the Cleveland market. If it sells, we’ll launch regionally next this fall, then nationally next spring. This is call a “low cost probe” and it typically rolls out fast. But, these types of things have a high failure rate. They want to try it, and kill it if not working.
What I see is that IT and business typically have different time scales. IT likes more certainty in projected capacity, connectivity etc in order to scope an effective solution, build, test, provision to a realistic set of requirements.
In a recent studied I conducted, I found that top performing enterprise IT
shops seem to be better at killing projects that no longer make business sense.
I assume these folks are better aligned with business on low cost probes.
In another recent study, I found that enterprise IT often has project office that manages more strategic big projects, but often struggles with managing ongoing stream of more tactical requests. Ie – we need 3 more servers, we need more storage etc. I found evidence that having a defined and published process for handling the tactical demand is actually a sign of the highest level of governance maturity.
My gut is that CC offers potential value for internal IT to help facilitate the smaller, faster low cost probe type projects via plug in resources. Perhaps once the business need is proven and scoped based on measured usage, then IT can find a more permanent home (internal or external) based on more stable set of requirements/projections.
ON a side note -
Per other recent posts and some conversations I had last week with infrastructure server providers, I do think that there is a layer of services IT organizations need to offer to manage CC based projects. My guess is that business funders/managers will still turn to IT to help manage CC based capabilities.
Ricky Ho posted a comment about list of functions the abstraction layer provides.
We should also consider what “services” the IT staff can offer, as well as technical services the CC management infrastructure should offer.
Kurt
Miha Ahronovitz
Rick, you state as user concerns the provider should consider
- Speed to deploy/undeploy infrastructure resources to meet changing
business workload
- Data sensitivity protection and audit compliance
- Reliability and QoS guarantee
- Total cost of ownership
VCs (Venture Capitalists) understand.
I learned "the little bird" methodology from Guy Kawasaki book:
"The Art of the Start: The Time-Tested, Battle-Hardened Guide for Anyone
Starting Anything"
Each time I make a statement, a little bird sits on my shoulder and asks:
"So What?" See my answers to the little bird.
1 Bullet
Total cost of ownership
little bird:
So What?
Translation: This is complicated to calculate and not obvious. Clouds make
profits, they are not cost centers. We need special research to find a
number, and then, skeptics will not believe. The TCO is of interest, it
adopted, to providers only. Users only want to know a price list for
services. They shop around and do their own calculations that the provider
cannot make for them. They will not order an internal TCO before making a
decision. They will look at their budgets and see how to get the maximum for
each buck
2. Bullet
business workload
So What?
Translation:
This assumes the user has a say in deploying resources. If he does, then
s/he does not use the cloud, but simply an external provider. If it is a
cloud, I can see the provider has always an answer. The user just asks how
long it takes to accommodate x simultaneous users and y applications
delivered as services, at QOS defined formally by Service Level Agreement.
The resources , ideally should assigned dynamically to the customer, in such
a way s/he is totally unaware of. All the resources consumed are part of
the price quoted next to the SLA.
3. Bullet:
So What?
Translation:
There is no way to assure for everyone that their data is "safe" in a
particular cloud. People have different degrees of data protection. If there
is special request for high level audit needs and data protection, this
should be priced separately. If it cannot be offered, then the user better
run these services internally. The cloud owner will say: This is what I can
offer. Do you accept the agreement or not?
4. Bullet
So What?
Translation:
Customers and cloud providers agree on quality of service that should be
priced. They write a Service Level Agreement (SLA) and this should be clear
enough for each requirement. Each line in the SLA should be associated (by
the Cloud Provider) to a Service Level Objectives (SLOs). Which are just
numbers. The provider understands, the user understands, they sign and all
what is needed. Even simpler, the providers offers prices for various levels
of service assurance, and the user accepts the range that it finds
appropriate.
There a few slides missing. If I start a cloud as above, who will be my
customers (they want NAMES , not just a market definition). Why these
customers will select my services versus anything else (product , service)
that solved for the customer the same problem? (Because I faster, cheaper,
more reliable, easier to adopt than the others?) etc.
Last paragraph raises the question: Do we worry on this group whether our
cloud ideas can be funded? Do we worry on this group whether all this
technology ca marketed and transformed in $?
This is why entrepreneurial Product Management exists. To make a business in
the eyes of the investors and to mitigate all risks (translation; to answer
very hard questions) to an acceptable level to the investors.
Cheers,
Miha
PS: Now I turn away my voice and hope that the bird does not hear me :-) To
learn more about how SLAs and SLOs work in Sun Grid Engine with the Service
Domain Manager, here it is a detailed engineering presentation by my
colleague Richard Hierlmeier:
http://www.globusworld.org/documents/R.Hierlmeier-RevisedOSGC_SDM.pdf
See the slides 23 to 29 with a detailed description of the SLOs
-----Original Message-----
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of Ricky Ho
Jaymes Davis
Like that rational
john...@ieee.org
For me, Cloud Computing, as a service, is a reincarnation of the
ancient time sharing with updated [distributed systems] technologies.
With time sharing, an organization can set up a time sharing system
for its users (as in the case of practically all the universities) or
contract out the computing need of its users to a time sharing system
company.
As such, I do not find "internal cloud" to be an oxymoron.
Alexis Richardson
http://businessmirror.com.ph/index.php?option=com_content&view=article&id=5158:us-defense-dept-mimics-google-microsoft-in-cloud-computing&catid=52:technology
Imitation is the sincerest form of flattery. Some guys at the US DoD
see Amazon and other clouds and for some reason they cannot use them
yet. Perhaps naturally they say "I want one of those". As Jim and
Stu pointed out earlier on this thread, most of the economics of
centrally managed, self-serviced, audited multitenancy, carry across
to the 'internal' case. So "mimicry" is the way forward for some
customers.
The corollary of the statement "there can be no internal cloud" is
that EC2 would cease to be a cloud if Amazon made it so that only
Amazon staff and suppliers could use it, but Amazon customers could
not. This does not make sense, therefore the notion of an internal
cloud is viable.
alexis
Ray
Ray
Krishna Sankar (ksankar)
space. Looks to me, we have more talk about standardization work than
actual cloud work. May be I am moving in the wrong circles ;o)
Anyway the reason for the blog is Bob Sutor's notes from a Cloud
Standards gathering. To be fair, I did not attend the meeting and I
should be careful to separate the message from the messenger - Bob's
ideas vs. what he is reporting from the gathering.
A few things that caught my eye - some I agree, a lot I disagree:
== There could be potentially 100s of standards
To quote Scooby-doo, "Yikes". I think this is the wrong approach.
The domain (Cloud Computing) is barely born and we are already talking
about 100s of standards- new or old ! This will definitely slow down the
progress or (most probably) everyone will ignore the "standards" and do
whatever is necessary to run the business. We should strive for
simplification. I propose that overstandardization was one of the
reasons for the demise of SOA and Web Services. (Yep, I know lots of
people will disagree. But before you start throwing stones, at least
read thru Ann's blog -
http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.ht
ml)
== Need "marketecture" & speed of standardization is important
This is exactly where I think we have the cart before the horse.
Usually standardization happens based on a few running instances and
when practitioners realize that some parts need interoperability based
on experience (let me say again, actual experience) standardization
happens. Because of running code, protocols et al, the participants know
what to standard and how. How are we going to standardize based on an
imaginary marketecture ?
And we should never rush standards - usually standards a little
deliberate and systemic. Agreed, once we understand a domain, we
shouldn't take infinite time. But I have never heard of standardization
based on "marketecture" even before a domain is being developed.
== Need to understand interchangeable parts vs. interoperability
I think we are over analyzing here. To tell the truth, I have no
clue what it means.
== "It is not acceptable to delay standardization until a particular
provider establishes lock-in or a monopoly"
Eh ? ;o) Very strange. Monopoly or duopoly or ... comes via business
relevance - not by standardization. Here also I am lost - are we saying
that all the hoopla about standardization is against a known or unknown
cloud provider ?
== "Cloud computing is here today, but we are very, very early"
Agreed. Of course, this clashes with other statements where it says
we already have a monopoly
== "We should not waste time having an official cloud computing
definition of 'interoperable.'"
Agreed. Instead, maybe we should define "interchangeable" and move
on o;) (Sorry, couldn't resist) Again, this is right - the domain is
very new that we really do not know what it is. Me thinks, we should not
smother it with too much standardization. What says thee ?
Of course, the updates (as & when available) at my blog
http://doubleclix.wordpress.com/2009/01/27/cloud-standards-putting-the-c
art-before-the-horse/
Cheers
<k/>
JimL
different stages of using EC2 right now. Around half of them are large
multi-national organisations whom most people will have heard of. All
of the use cases are interesting and the challenges face by each are
interesting.
One use case is for a large mobile Telco who are putting out two new
services on the cloud in late March. Each service has the application
hosted on EC2 but the data hosted internally. The reason they feel
they can do this now is that they have just come off a longish term
project to implement SOA / services internally. They now have a secure
services interface which is what is used to communicate with the
internal applications and pulls / pushed data needed / given. All of
this is done over SSL.
Another large media company is going to use the cloud to host an
application with data in the cloud solely. I can't give too much away
bit this a unique new type of TV show that uses the ability of getting
larges cale compute resources on the cloud to crunch some fairly large
amounts of data in real-time for the show. The TV show will be sold to
networks all over the world. This would not be practical to do from a
cost perspective if they had to use something else other than the
cloud.
I go through more of these examples in a recorded presentation that I
did with Nati Shalom that you can see at:
http://www.slideshare.net/giganati/savig-cost-using-application-level-virtualization-presentation
Jim Liddle
www.gigaspaces.com/cloud
On Jan 26, 12:46 am, Ricky Ho <rickyphyl...@yahoo.com> wrote:
> IMO, the "definition" of a buzzword is not very interesting and usually it is overloaded and can mean different things to different people. Look at what "characteristics" that the cloud brings may be more interesting. And there are 2 different points of view: the user and the provider.
>
> User's concern:
> ============
> - Total cost of ownership
> - Speed to deploy/undeploy infrastructure resources to meet changing business workload
> - Data sensitivity protection and audit compliance
> - Reliability and QoS guarantee
>
> Provider's concern:
> ===============
> - Efficient use of underlying infrastructure, usually achieved by physical sharing with logical isolation between tenants ("Virtualization" is a common means to achieve that).
> - Efficient resource scheduling tool that can handle dynamic regrouping of resources based on temporary usage patterns.
> - Efficient management tools that can keep track of the health, ease the debugging in a highly distributed and virtualized environment.
>
> Note that I haven't said whether the provider is the in-house IT or a public cloud provider because I don't think this is an important distinction. I also believe "enterprise cloud" will be competing with "public cloud" for a while. And a public cloud will always have the advantage of economy of scale and operation expertise while an enterprise cloud will always have the advantage when data sensitivity is a concern.
>
> I also think reality of cloud computing for large enterprise is always a hybrid environment. It will be very useful to get some guidelines from this expert group on what should be put on the public cloud versus enterprise cloud, and how does components living in different domains can communicate with each other in a secure way.
>
> Rgds,
> Ricky
>
> ----- Original Message ----
> From: Frank D. Greco <fgr...@javasig.com>
> To: cloud-c...@googlegroups.com
> Sent: Sunday, January 25, 2009 2:10:47 PM
> Subject: [ Cloud Computing ] Re: Is "Internal Cloud" anoxymoron?
>
JimL
>
> User's concern:
> ============
> - Total cost of ownership
> - Speed to deploy/undeploy infrastructure resources to meet changing business workload
> - Data sensitivity protection and audit compliance
> - Reliability and QoS guarantee
>
> Provider's concern:
> ===============
> - Efficient use of underlying infrastructure, usually achieved by physical sharing with logical isolation between tenants ("Virtualization" is a common means to achieve that).
> - Efficient resource scheduling tool that can handle dynamic regrouping of resources based on temporary usage patterns.
> - Efficient management tools that can keep track of the health, ease the debugging in a highly distributed and virtualized environment.
>
> Note that I haven't said whether the provider is the in-house IT or a public cloud provider because I don't think this is an important distinction. I also believe "enterprise cloud" will be competing with "public cloud" for a while. And a public cloud will always have the advantage of economy of scale and operation expertise while an enterprise cloud will always have the advantage when data sensitivity is a concern.
>
> I also think reality of cloud computing for large enterprise is always a hybrid environment. It will be very useful to get some guidelines from this expert group on what should be put on the public cloud versus enterprise cloud, and how does components living in different domains can communicate with each other in a secure way.
>
> Rgds,
> Ricky
>
> ----- Original Message ----
> From: Frank D. Greco <fgr...@javasig.com>
> To: cloud-c...@googlegroups.com
> Sent: Sunday, January 25, 2009 2:10:47 PM
> Subject: [ Cloud Computing ] Re: Is "Internal Cloud" anoxymoron?
>
John D. Mitchell
On Saturday 2009.01.24, at 14:10 , natis...@gmail.com wrote:
[...]
> Based on my experience there are two main driving force:
>
> 1. On demand computing i.e. the ability to get a resource when i need
> it in matters of minutes.
> 2. Pay - per use i.e. the ability to pay only for what i use.
I quite like this characterization precisely because it's clean and
simple.
I think a lot of the arguments to date end up being various forms of
echo chamber / navel gazing amongst the insiders rather than the
consumers of the services.
> The rest is an implementation details.
> From an end user perspective if it doesn't matter that much if i can
> get the above value from internal or external cloud.
As Frank noted, it can matter a great deal for various factors such as
security. That said, I'd expand that into the general category of
factors (and people who) need (to feel that they need) to be in
control (whether that's an internal need or an externally mandated
need).
> In my view what will see in the near future is hybrid-cloud i.e.
> local-
> IT+ Internet Cloud.
I totally agree. I see it as a spectrum rather than an either/or.
Some people/projects need very little in-house while others need more.
> A typical scenario would be to run testing on
> public cloud and production internally. There are many other scenarios
> that jutifies this type of hibrid model.
>
> The real question about private cloud is whether local-IT would ever
> be able to compete with the cost and level of service of those of the
> public cloud.
If you add in the fully-burdened costs of things like data transfer in/
out, sensitive data security (and the attendant liability risk), need
for some places of very high performance (e.g., predictable / low
latency, large bandwidth, etc.), etc. then the answer is/can be yes.
The variability for different organizations / projects needs is why
it's a spectrum rather than competing point solutions.
> This is where the economy of scales plays an important role (See James
> Liddle recent blog: The Economics of Cloud http://vehera.jsn-server7.com/LiddleBlog/?p=234
> ) i.e. the bigger the data-center is the higher the chance the cost
> and level of service will get better then those of smaller data-
> centers. It may very well that over time public cloud will become the
> only option just like energy, however its going to take a while till
> this will happen if at all.
I don't see that happening until it's far enough out to be science
fiction. :-) There's too many specialized constraints, for one.
Rock on,
John
John D. Mitchell
On Sunday 2009.01.25, at 09:57 , Stuart Charlton wrote:
[...]
> On Sun, Jan 25, 2009 at 4:25 AM, Jan Klincewicz <jan.kli...@gmail.com
> > wrote:
> It is a good idea for test & dev servers to be put into use to
> accomodate seasonal fluctuations. However, in a modern, highly
> virtualized shop, these machines no longer represent a lot of spare
> capacity.
>
> - Most IT shops are not highly virtualized yet, even the "modern"
> ones. This is changing, of course....
>
> - I've observed many a production outage because the organization
> could not allocate the resources to perform an adequate stress test
> of major changes, and the budget to acquire such an environment *for
> the purposes of that project* would have been prohibitive.
I've run into this a *lot*. This is one of those problems that's so
prevalent that people just seem to accept it as being part of the
natural order of things (and that's scary).
One of my biggest rants is how these sorts of constraints affects how
people (don't) see the problems that have and what the possible
solutions are and how that perverts their thinking and decisions. I
see this across the organizational layers and it's shockingly
consistent (in a bad way). One of my hopes of the benefits of the
hype of CC (regardless of the long-term reality) is that it helps to
force open people's brains as to there being a lot of options that
don't fit their existing biases.
> - I have seen two poles of behaviours with IT organizations related
> to dev/test: either dev/test is ignored and teams have to scavenge
> for resources, or huge amounts of idle capacity are tagged as dev/
> test. Both have major consequences, though usually the former is
> much worse.
Indeed!
This is an area where I see a lot of value in the use of
virtualization. Separating things logically and so being able to do
dev/test on much smaller number of physical boxes than production
while still getting lots of value from the logical testing -- this can
actually be an advantage over perfect replicas of the production site
since we can easily induce lots of the edge cases.
[...]
> I don't expect a whole sale jump into any of the above, but I do
> expect some early adoptors getting into the act if they can see a
> positive NPV with a (say) 12-24 month window....
Indeed.
Though I do see more and more startups (particularly web startups)
jumping into this whole hog from day one.
Cheers,
John
Nati Shalom
security. That said, I'd expand that into the general category of factors
(and people who) need (to feel that they need) to be in control (whether
that's an internal need or an externally mandated need)."
Note that when I mentioned that from an end user perspective it doesn't
matter that much who is the service provider I'm assuming that there would
be other cloud providers that will provide the type of SLA's that are
required by most data-centers. Obviously that statement doesn't fit them all
and I'm sure that those who already maintain a large data-center would
still maintain large part of their operations in the private cloud. We
should note that organizations with large data-centers are probably the
minority not the majority.
Nati S.
-----Original Message-----
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of John D. Mitchell
Sent: Wednesday, January 28, 2009 8:49 PM
To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re: Is "Internal Cloud" an oxymoron ?