Amazon.com: The Participatory Cultures Handbook (9780415506090): Aaron Delwiche, Jennifer Jacobs Henderson: Books.
I co-authored (with Sarah Pearce) a chapter in this book focusing on the culture of particle physicist at CERN as they developed the world’s largest Grid Computing infrastructure for the LHC. The chapter considers the different collaborative and management practices involved in such a large endeavour and offers lessons for others building information infrastructure in a global collaboration.
Pre-Order a copy now!!!
Our second Accenture report on Cloud Computing is about to be published! As a taster the above link takes you to a short synopsis (Published in the Accenture Outlook Points of View series). I will post a link to the full report when it is out.
While in danger of providing a summary on a summary, this second report builds on our first “Promise of Cloud Computing” report to analyse the challenges faced by a move to cloud. We identify the following key challenges:
Challenge #1: Safeguarding data security
Challenge #2: Managing the contractual relationship
Challenge #3: Dealing with lock-in
Challenge #4: Managing the cloud
Once you read the paper I would love to hear your views – please use the add comments link at the bottom of this section (its quite small!) or email me directly on firstname.lastname@example.org
I would also suggest you also review the whole report when it is out – much of the important detail is missing from this shorter synopses.
This is a company to watch http://www.cohesiveft.com/ – they have two products:
VPN-Cubed provides a virtual network onto the network of a cloud provider. This enables first to keep a standard networking layer which is consistent even if the cloud provided network changes (e.g. IP address changes).
Elastic Server allows real-time assembly and management of software components. This allows the quick creation of easy to use applications which can be easily sent to various cloud services.
However it is the fact that together these services allow virtual machines and cloud services to be moved between cloud IaaS providers without significant real-time work which is important. If their products live up to the promise then users can move to the cheapest cloud provider with ease so driving down costs to commodity supplier levels… and creating the spot market for cloud.
Service Level Agreements (SLAs) are difficult to define in the cloud in part because areas of the infrastructure (in particular the internet connection) are outside of the scope of either customer or supplier. This leads to the challenge of presenting a contractual agreement for something which is only partly in the suppliers control. Further as the infrastructure is shared (multi-tenanted) SLA’s are more difficult to provide since they rest on capacity which must be shared.
The client using the Cloud is faced a challenge. Small new cloud SaaS providers, which are increasing their business and attracting more clients to their multi-tenanted data-centre, are unlikely to provide usefully defined SLA for their services than that which a data-centre provider can offer where it controls all elements of the supplied infrastructure. Why would they – their business is growing and an SLA is a huge risk (since it is multi-tenanted breach of one SLA is probably a breach of lots – the payout might seem small and poor to the client but is large for a SaaS provider!). Further with each new customer the demands on the data-centre, and hence risk, increase. Hence the argument that as SaaS providers become successful the risk of SLAs being breached might increase.
There is however a counter-point to this growth risk though – as each new customer begins to use the SaaS they will undertake their own due-diligence checks. Many will attempt to stress test the SaaS service. Some will want to try to hack the application. As the customer base grows (and moves towards blue-chip clients) the seriousness of this testing will increase – security demands in particular will be tested as bigger and bigger companies consider their services. This presents a considerable opportunity for the individual user. For with each new customer comes the benefit of increasing stress testing of the SaaS platform – and increasing development of skills within the SaaS provider. While the SLA may continue to be poor, the risk of failure of the data-centre may well diminish as the SaaS grows.
To invoke a contract is, in effect, a failure in a relationship – a breakdown in trust. Seldom does the invocation of a contract benefit either party. The aim of an SLA is thus not just to provide a contractual agreement but rather to set out the level of service on which the partnership between customer and supplier is based. In this way an SLA is about the expected quality demanded of the supplier and with the above model the expected quality may well increase with more customers – not decrease as is usually envisaged for cloud. SLA’s for cloud providers may well be trivial and poor, but the systemic risk of using Clouds is not as simplistic as is often argued. While it is unsurprising that cloud suppliers offer poor SLA’s (it is not in their interest to do otherwise), it does not mean that the quality of service is, or will remain, poor.
So what should the client consider in looking at the SLA offering in terms of service quality?
1) How does the Cloud SaaS supplier manage its growth? The growth of a SaaS service means greater demand on the providers data-centre. Hence greater risk that the SLA’s will be breached for their multi-tenanted data-centre.
2) How open is the Cloud SaaS provider in allowing testing of its services by new customers?
3) How well does the Cloud SaaS provider’s strategic ambition for service quality align with your desires for service quality.
Obviously these questions are in addition to all the usual SLA questions.
Structure 2010: Akamai “Doing Terabit Events” (Thanks, World Cup). Akamai are an interesting company which highlights the problems of latency within the cloud. But also check out the work going on in Stanford on OpenFlow http://www.openflowswitch.org/ which provides a similar in data-centre / campus level network latency response by centralising the control of the network routers/switches to best manage the flow of traffic. This work also reduces the complexity of the network and allows a more specific and intelligent networking flow than achievable by existing routing tables.