Cloud Computing is Dangerous
Reuven Cohen
"Son, back in my day we used to store all our data on a single computer." My son in turn says, "Dad, that's crazy, I have every song I've ever listened to and every movie I've ever watched on my brand new ibrain, anytime anywhere" and I say "Worse yet, we had to return to that computer in order to access those files, in the snow, without shoes on..." (You get the idea)
Although I'm partly kidding, for most this how personal computing still works. Ask anyone who's ever lost a hardrive and they will tell you that your data is your life and for the most part your life is stored on a single computer. If you lose that computer, you lose, well, your data. (No dramatics sorry) This begs the question, wasn't the emergence of cloud computing supposed to help solve these types of problems? Isn't cloud computing supposed to be the answer to all our problems?
I'm here to tell you. Hell No! Cloud computing is Dangerous!
Helping bring this danger to the forefront was the announcement last week that a division of Microsoft ironically called Danger Inc had likely lost all the contacts, photos and other personal data for users of the T-Mobile Sidekick. Pretty bad, huh? What was worse is this cloud service was a manditory requirement for using the Sidekick service. If you wanted to use a Sidekick you had no choice but to use this sadly lacking excuse for a hosted data service.
Although many of the cloud pundants out there will try to tell you that the Sidekick service isn't a cloud application. Let's call it what it is, it's a cloud app -- your data when using a Sidekick is hosted in some elses data center. In the most basic terms, if I choose a device such as a mobile phone that requires me to use some elses data centers for storing my personal data, I expect it to be at the very least backed up automatically, and preferably I should have the ability to do so myself. It appears that neither was an option for T-Mobile Sidekick customers. This failure hits at the heart of why interoperability and data portability is so important. It comes down to bad things happen and I should have the ability to take the data that is mine if I choose to do so, easily.
Over the last few days I've read a number of articles that point out that this cloud failure means the end of cloud computing. Let me remind you that failures happen and it happen all the time. There are whole groups at major manufacturers devoted to it, on purpose. Whether it's on your desktop, in your data center or in the cloud. To fail is human. But to be prepared is noble.
The best and easiest way to be prepared for the inevitable failures that will occur is to rely on services that allow for portability. Make sure you have a clear exit strategy before you choose a cloud service provider and avoid the ones that attempt to lock you in. At the end of the day it's up to you to make sure you don't get Sidekicked (in the face or otherwise).
Again, for those of you effected by the Danger Inc failure, my deepest sympathies are with you, you deserve more. You deserve your life back, or at the very least your data.
afalcon
The Danger service did just that. Danger is a hosted service, not a
cloud-based service.
Cloud based services have built-in redundancy for reliability and
availability, and scalability for capacity and performance.
Microsoft's hosting of Sidekick/Danger had neither.
Read more here: http://www.internetevolution.com/messages.asp?piddl_msgthreadid=229478
On Oct 11, 10:37 pm, Reuven Cohen <r...@enomaly.com> wrote:
> In about 25 years from now I can imagine having a conversation with my kids
> that goes something like this.
>
> "Son, back in my day we used to store all our data on a single computer." My
> son in turn says, "Dad, that's crazy, I have every song I've ever listened
> to and every movie I've ever watched on my brand new ibrain, anytime
> anywhere" and I say "Worse yet, we had to return to that computer in order
> to access those files, in the snow, without shoes on..." (You get the idea)
>
> Although I'm partly kidding, for most this how personal computing still
> works. Ask anyone who's ever lost a hardrive and they will tell you that
> your data is your life and for the most part your life is stored on a single
> computer. If you lose that computer, you lose, well, your data. (No
> dramatics sorry) This begs the question, wasn't the emergence of cloud
> computing supposed to help solve these types of problems? Isn't cloud
> computing supposed to be the answer to all our problems?
>
> I'm here to tell you. Hell No! Cloud computing is Dangerous!
>
> Helping bring this danger to the forefront was the announcement last
Fred Zappert
James Watters
Sent from my iPhone
bobinson
And what happens when the cloud service goes down ? we have seen AWS
going down, gogrid going down and Gmail going down.
On Oct 13, 12:25 am, James Watters <wattersja...@gmail.com> wrote:
> Excatly Fred...I think any attempt to make this a cautionary tale of
> cloud storage are daft.
>
> Sent from my iPhone
>
>
> > Danger was not using "Cloud Storage", they were using "Clod storage"
>
Sam Johnston
And what happens when the cloud service goes down ? we have seen AWS
going down, gogrid going down and Gmail going down.
bobinson
corruption. In such an incident our
only choice is to go for Geo Redundancy. Its immaterial whether the
data is stored in a single computer
or a cloud storage what is important is to provide redundancy. Isn't
that the case ?
Building redundant cloud storage solutions which can be accessed via
open APIs is what we need. And not
simply any cloud storage.
On Oct 13, 6:34 pm, Sam Johnston <s...@samj.net> wrote:
Sam Johnston
I remember the last time GoGrid was down due to a BGP cache
corruption. In such an incident our
only choice is to go for Geo Redundancy. Its immaterial whether the
data is stored in a single computer
or a cloud storage what is important is to provide redundancy. Isn't
that the case ?
Building redundant cloud storage solutions which can be accessed via
open APIs is what we need. And not
simply any cloud storage.
Gregg Wonderly
> On Tue, Oct 13, 2009 at 3:29 PM, bobinson <bobi...@gmail.com
> <mailto:bobi...@gmail.com>> wrote:
>
>
> And what happens when the cloud service goes down ? we have seen AWS
> going down, gogrid going down and Gmail going down.
>
>
> You use open interfaces to access your data in open formats (ideally
> before it goes down!) and spin up your workload somewhere else
> (externally or internally). What do you do when the power goes out today?
much opportunity to decide how you will get to it. Primarily, this is a
network path issue as the primary point of control. We depend on the
network providers to distribute paths with redundancy. We depend on
cloud providers to provide interfaces that will allow me access to my
"rain drops" from where ever and how ever I need.
Practically, this requires an infinite set of solutions even though
there is a finite number of failure points. The farther the
"interruption" is from me, the more choices I have about how to solve my
problem. In late 2008, we had an ice storm in our area that completely
eliminated all network paths out of here for >24 hours. No matter how
many ISPs I had contracted with, they either had no power, or no media
to provide service with/over. Satellite may have been an option
provided power was available.
Moving to a cloud infrastructure, from my perspective makes things
"better", but at an order of magnitude increase in cost because of all
the issues you have to deal with to make sure you can access the cloud.
When it's all local, you just need to deal with the power issue for your
location. A much smaller problem.
Gregg Wonderly
Adrian Cole
jclouds is an open source java api that allows you to write to multiple storage clouds at the same time using the same interface. Our next beta will support 6 clouds including S3, Rackspace, Nirvanix, Mezeo, Azure, and Atmos. This can get you geo-redundancy like no single cloud can achieve.
Pardon the plug, but I think it is relevant ;)
Cheers,
-Adrian
founder jclouds
http://code.google.com/p/jclouds
Ray DePena
And what happens when the cloud service goes down ? we have seen AWS
going down, gogrid going down and Gmail going down.
I suppose the same thing that happens when internal corporate systems go down....
--
Ray DePeña
Director, Stealth Startups
Strategic Business Advisor
http://www.linkedin.com/in/raydepena
Sacramento, CA 95630
(916) 941-5558
GoGrid
outages that are obviously not directly related to the Cloud but
rather due to bad IT planning. Yesterday I posted an article which
discusses this on the GoGrid blog:
http://blog.gogrid.com/2009/10/13/the-microsoftdangert-mobile-sidekick-fiasco-is-not-a-failure-of-cloud-computing/
and it seems to be getting some traction.
With ANY hosting environment, you need to have redundancy (internal
and/or external) as well as a well thought out failover and backup
strategy. There will always be issues and outages, this is not unique
to the Cloud. I just hope that all of us Cloud pundits out there will
work with main stream media to clearly articulate this fact and stop
the Cloud bashing.
Thx,
Michael
Pablo Serber
gary mazzaferro
-gary
Jeremy Day
I haven't read a whole lot about this but it sounded to me like it was really, really poor planning on the part of the folks doing whatever upgrade or migration they were doing. They failed to ensure that they had a current backup of the data before moving it. It doesn't, in my mind, have a single thing to do with the cloud. Poor planning and worse execution were at play here.
Jeremy
Scott Jordan
> going down, gogrid going down and Gmail going down.
Cloud computing is a tool, which can be used or abused like any other tool.
It is also a buzzword, which can be applied and misapplied like any
other buzzword. In the case of the MS/Sidekick/Danger screw-up, the
word "cloud" is, IMHO, being misapplied. A hosted service is not
necessarily cloudish in its implementation. As others have pointed
out, the Sidekick phone and service predates cloud technology by
several years.
Another interesting point to consider is whether anyone might have an
agenda in impugning cloud technology as the culprit in this mess. For
example, whose business model is threatened by emerging cloud-based
competition? Maybe those folks' anti-cloud invective needs to be
viewed against their evident interest in seeing cloud adoption
impeded. FUD, anyone? Similarly, let's admit that those of us on the
pro-cloud side have our own background agendas at play.
Bottom line: any computing configuration needs a backup strategy.
However, cloud resources are being applied (and will increasingly be
applied) to really huge data sets, for example clinical genomic
databases and assorted big-physics and astronomy databases, because
they're an enabler for new ways of investigating nature. This is, in
fact, a major frontier in science and cuts across many disciplines.
Backing all that data up is a big challenge. Which doesn't mean it
need not be done.
For those whose ventures are being deployed in the cloud but don't
involve terabytes galore, backup is a more tractable issue and
something to discuss with one's cloud vendor, and probably something
we should duplicatively perform ourselves. Though it's not a failure
of any cloud technology, the Danger/Sidekick mess has done us a favor
for spotlighting this necessity.
--Scott
Reuven Cohen
secondary to the real issue. The Sidekick failure has beautifully
illustrated a major potential problem facing the use of any remotely
hosted web services, cloud or otherwise and this is trust.
My issue with all the sidekick cloud debate isn't whether or not it's
a failure of cloud computing. You can't blame a buzzword. Cloud
computing isn't any single technology but instead It's a new way to
market, manage, deploy and operate web centric software and
infrastructure. So I do agree it isn't a failure of cloud computing so
much as a failure to build an adequate DR strategy among other things.
This failure does in the most simple terms demonstrate a key problem
facing cloud computing, you are trusting someone else to manage your
data / infrastructure. But leading an argument by saying it isn't a
cloud because clouds can't fail is ridiculous.
r/c
Rao Dronamraju
Yup!. I agree with Ruv. This also brings up the issue of cloud
certification. A good way to build trust is to have an industry sponsored
certification as to what is cloud and what is not cloud so that certain
vitals of a cloud are always provided by the CSPs. For instance, security,
performance, DR SLAs. Although considering that we still debate what is a
cloud, certification is probably a year of two off. But such disastrous
events might hasten the standards and certification.
Scott Jordan
>
> Whether the Sidekick platform is or isn't "cloud computing" is totally
> secondary to the real issue. The Sidekick failure has beautifully
> illustrated a major potential problem facing the use of any remotely
> hosted web services, cloud or otherwise and this is trust.
Then why entitle this thread, "Cloud computing is dangerous"?
Computing is dangerous. Ignoring fundamental backup principles is
really really dangerous!!
As to trust: an excellent point. Blind trust is like puffing on a
trick cigar: everybody watching knows what's coming but it always
seems to catch the victim by surprise. Trust, but verify. What
provisions does your remote service employ for backup? What can you
do to dupicatively perform your own worst-case-scenario recovery?
> My issue with all the sidekick cloud debate isn't whether or not it's
> a failure of cloud computing. You can't blame a buzzword. Cloud
> computing isn't any single technology but instead It's a new way to
> market, manage, deploy and operate web centric software and
> infrastructure.
There are those who say cloud computing is heavy on the hype, but I
think it's more than that, and that itself is an interesting point
worth discussing. There are technologies which demarcate this thing
we call the cloud from old-timey web-based ways of doing things, and
they enable new applications, low-cost/low-viscosity ventures, all
sorts of good things that weren't possible before. Along the way,
some questions arise that need answering: backup, recovery, security,
etc. There have been whoopses, which is inevitable. That's progress.
> So I do agree it isn't a failure of cloud computing
Good, thanks. I wish the pundits would back off on that point, as it
grows tiresome.
> so much as a failure to build an adequate DR strategy among other things.
Few among us would disagree! Microsoft and their vendor made some of
the most fundamental mistakes possible in any computing
implementation. Hell, you want to add RAM to your PC: back the damn
thing up first. It's that fundamental. My kids know that much.
> This failure does in the most simple terms demonstrate a key problem
> facing cloud computing, you are trusting someone else to manage your
> data / infrastructure. But leading an argument by saying it isn't a
> cloud because clouds can't fail is ridiculous.
Agreed, though implementation of cloud principles is a step towards
improved data-safety and uptime, just as going from a single hard disk
to a RAID array can result in improved data-safety and uptime. But
I'd hope that no one would say that it's unnecessary to back up a RAID
array, utilize off-site archival storage for a RAID array, have a
recovery plan for a RAID array, etc. Meanwhile the benefits of cloud
technologies extend beyond improved data-safety and uptime, and that's
getting lost in the wash of commentary on this episode.
--S.
Ray DePena
It wasn't exactly brain surgery... Have a backup? No. Redundancy? No. Hot Standby? No. Plan? Yes, 100% uptime off a single server. Eh... not an optimal plan there.
It didn't take long to explain what they needed and why.
Unfortunately, given today's economic situation, it wouldn't surprise me to see many companies forgo their DBR plans. Usually recommended as 'cost savings' by folks that don't plan to be around very long.
Sam Johnston
But leading an argument by saying it isn't a cloud because clouds can't fail is ridiculous.
Who ever said that?
The closest I've seen was Alexis' quip: "if it loses your data - it's not a cloud".
Sam
eric
>
> I doubt we'll see geographically independent virtual machines running
> in lock-step on a large scale any time soon, and given the way cloud
> architectures (like Google File System) works that's ok. Such failures
> should be transparently tolerated, resulting in at worst performance
> degradation (as is the case when a RAID set is degraded). We were
> discussing the concept of RAID for datacenters yesterday and that's
> essentially what it is we're talking about.
Storage limitations are something that is easily, if not expensively,
engineered around. What I've had trouble with is the reliability of my
virtualization platform in regard to hardware and software. Running in
lock-step might be an option but, ignoring the experimental status, it
requires homogeneous machines.
This last part is critical because it hinders upgrades. This
significantly increases costs as companies must continue to deploy last
year's technology with last year's efficiency, and for those same
reasons destroys green computing efforts.
We won't see larger scale lock-step deployments until it can be proven
to operate reliably with feature-locked kernels on varying
subarchitectures.
--
Regards,
Eric Windisch
Bernard Robertson-Dunn
data centre and behind firewalls) and some in a cloud (i.e. in a
separate environment owned and operated by a third party) how are
Integration/Security/Identity Management and other Non-Functional
Requirements handled across both environments?
--
Regards
brd
Dr Bernard Robertson-Dunn
Canberra Australia
b...@iimetro.com.au
Joseph Stein
is working on.
CSA has v1 guidance on a lot of domains and are working on v2 final
draft (which does help to answer this and MUCH more extensive than
v1).
I am part of the I&AM group (wrote on topic for Cloud Identity as a
Service) and I am editing the AppSec domain (working on second draft)
so I can speak to it but would rather have the final v2 guidance from
CSA come out before you take it as something to follow on.
What specif applications are they and what components of them are
internal and which are in the cloud (e.g. you back up in the cloud or
host the authentication in the cloud as each have different
problems/challenges/solutions).
There are standards that address cross domain between environments
which are SAML for identity, XACML for authorization, XDAS for
distributed auditing and SPML for provisioning. I blogged my first
draft of the Cloud Identity as a Service
http://charmalloc.blogspot.com/2009/08/identity-as-service-idaas.html
which has gone through a lot of changes (myself and others) in the CSA
doc but feel free to check it out and will follow-up once the V2 is
out.
/*
Joe Stein
http://www.linkedin.com/in/charmalloc
*/
Rao Dronamraju
Another source could be AWS. Since AWS is supporting VPC (Virtual Private
Clouds) they must be supporting what you have asked. I am also very
interested in knowing how AWS implements this. May be someone from AWS on
this forum can help with this.
-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On
Behalf Of Joseph Stein
Sent: Wednesday, October 14, 2009 6:10 PM
To: cloud...@googlegroups.com
Bernard Robertson-Dunn
I need to understand what architectures are being contemplated for
whole-of-enterprise systems across internal and external environments.
These architectures need to cover enterprise wide issues such as
authentication, authorisation, application-to-application (some
internal, some external) integration, single sign-on, application access
auditing, updating/maintaining systems across multiple environments etc.
They also should cover NFRs like performance and availability.
I can understand how isolated or stand alone applications can reside in
a cloud, what I'm trying to understand is how integrated enterprise
applications, currently executing in a single (or at least totally
controllable set of) security and managed environments (such as the
enterprise's data centre(s) )
Rao Dronamraju wrote:
> Another source could be AWS. Since AWS is supporting VPC (Virtual Private
> Clouds) they must be supporting what you have asked. I am also very
> interested in knowing how AWS implements this. May be someone from AWS on
> this forum can help with this.
>
--
Regards
brd
Rao Dronamraju
Bernard,
The way I understand how Amazon's AWS-VPC works is your data center/private
cloud is basically extended by a VPN to the public cloud. As far as the
security is concerned they infact rely on the fact that your (data center)
firewalls and IDS will provide the security inside your data center and the
VPN provides the security to the public cloud. Similarly as far as the
integration of the solution should be seamless as far as your VM that has
migrated to the public cloud is addressable and accessible through regular
IP addressing. One thing I am not sure is, VMs could only migrate within a
domain,so what happens if they migrate to a diferent domain, is the IP
address updating and consequent connection update happen seamlessly?...I do
not know whether this solution is implemented widely. The most interesting
part is how is the Identitiy Management handled, are the requests
re-directed back to the data center where AD/LDAP and other support systems
might reside. Anyway this was my understanding a few months back when Amazon
released its VPC. But I will wait for the AWS experts to answer your
questions.
-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On
Behalf Of Bernard Robertson-Dunn
Sent: Wednesday, October 14, 2009 7:09 PM
To: cloud...@googlegroups.com
Subject: Re: Integration across the enterprise
Sam Johnston
The issue of authentication is relatively straightforward in that organisations already have infrastructure that needs to be extended to the cloud. The simplest way to do this is to integrate a device with the existing directory services and allow users to authenticate to it, then have it generate tokens for use to access external services (e.g. SAML2, OAuth, OpenID).
Authorisation is a little more involved and at this point you only have service level granularity (that is, you can check a user against the service they are trying to access and grant or deny accordingly). As a specific example, Google Apps has a Provisioning API that allows you to sync existing groups with the cloud-based directory (that's right, you need to create the users in the cloud most of the time - there's no "thin provisioning" options in most cases). Once the user exists they can be authenticated and once authenticated group memberships can be used as role based access control.
In terms of technical integration, one of the primary advantages of cloud architectures is that they are typically loosely coupled. "Integration" becomes "aggregation" as relatively lightweight web services are used to bolt components together from different providers. Where possible queues are also used such that individual components can fail without bringing down the entire system, as is the case with typical "brittle" enterprise architectures today.
The example I usually use (which I have implemented myself as a proof of concept) is taking orders via Google App engine against a product catalog and CRM database stored in Salesforce. If Google App engine goes down you can still function, making widgets and delivering them based on existing orders. Conversely if Salesforce goes down you can continue taking orders from a cached product catalog.
I hope that brief explanation sheds some light on the subject,
Sam
Bernard Robertson-Dunn
> Bernard,
>
> The way I understand how Amazon's AWS-VPC works is your data center/private
> cloud is basically extended by a VPN to the public cloud. As far as the
> security is concerned they infact rely on the fact that your (data center)
> firewalls and IDS will provide the security inside your data center and the
> VPN provides the security to the public cloud. Similarly as far as the
> integration of the solution should be seamless as far as your VM that has
> migrated to the public cloud is addressable and accessible through regular
> IP addressing. One thing I am not sure is, VMs could only migrate within a
> domain,so what happens if they migrate to a diferent domain, is the IP
> address updating and consequent connection update happen seamlessly?...I do
> not know whether this solution is implemented widely. The most interesting
> part is how is the Identitiy Management handled, are the requests
> re-directed back to the data center where AD/LDAP and other support systems
> might reside. Anyway this was my understanding a few months back when Amazon
> released its VPC. But I will wait for the AWS experts to answer your
> questions.
>
I'll add another issue - latency.
Rao Dronamraju
Bernard,
Not sure if you have seen these before, but I posted these stress test
results some time back. Interestingly since you are down under and these
tests also were run from australia on AWS. They also talk about latency. I
must caution that they are a bit old. Anna Liu, of University of NSW might
have the latest results. Hope this helps.
http://www.itnews.com.au/News/153451,stress-tests-rain-on-amazons-cloud.aspx
http://www.itnews.com.au/News/153819,more-data-released-on-cloud-stress-test
s.aspx
Rao
-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On
Behalf Of Bernard Robertson-Dunn
Sent: Wednesday, October 14, 2009 7:35 PM
To: cloud...@googlegroups.com
Subject: Re: Integration across the enterprise
Reuven Cohen
Sidekick customers in the U.S. will have "most, if not all" of their
personal data recovered, Microsoft says.
Owners of the Sidekick cellphone lost their personal data, including
contact and calendar information, when the servers storing the data
crashed.
"We have determined that the outage was caused by a system failure
that created data loss in the core database and the backup," said Roz
Ho of Microsoft in a post on the T-Mobile Forums.
R/c
Bernard Golden
http://www.cio.com/article/505129/Microsoft_Sidekick_Debacle_and_the_Cloud_Lessons_Learned?taxonomyId=168354
On Oct 14, 2:46 pm, Sam Johnston <s...@samj.net> wrote:
> On Wed, Oct 14, 2009 at 9:25 PM, Reuven Cohen <r...@enomaly.com> wrote:
>
> > But leading an argument by saying it isn't a cloud because clouds can't
> > fail is ridiculous.
>
> Who ever said that?
>
> The closest I've seen was Alexis'