1. Cloud Computing Architecture
User Requirements for
Cloud Computing Architecture
Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU and in Cyberspace Law & Policy, UNSW 2nd International Symposium on Cloud Computing Melbourne, 17 May {.html,.ppt}
My disciplinary background is information systems, in business contexts rather than computer science, and in my day-job I'm a consultant in eBusiness strategy and policy.
When I looked at the literature on this new area of 'cloud computing', I was struck by two things:
• it appeared to be still emerging from the laboratory and not 'ready for prime time' just yet
• the architecture diagrams all appeared to be very one-sided
I've accordingly written two papers, one for an international eBusiness conference in Bled (Slovenia) next month, analysing the benefits and risks from a business perspective, and this piece.

2. User Requirements for Cloud Computing Architecture AGENDA
Precursors / Related Concepts
A Working Definition
An Architectural Framework
User Benefits
Disbenefits and Risks
Operational
Contingent
Security
Business
Implications
I'll work through what I see as being the origins and nature of cloud computing, and then propose an architectural framework.
From there, I'll do a brief scan of the benefits and downsides, in order to draw implications for architects and designers.
Throughout, my perspectivie is not technical. If cloud computing is to be something more than an interesting area of research, it needs to measure up to business needs.

3. The Gartner Hype-Cycle for Emerging Technologies
No doubt everyone's aware of the Gartner Hype-Cycle.
It's a-scientific, but it has some surface validity, has put some expressions into common usage, and it's a common framework for discussions of new technologies.
" ... a snapshot of the relative maturity of technologies ...
"They highlight overhyped areas against those that are high impact, estimate how long they will take to reach maturity, and help organizations decide when to adopt"

4. Here's a version from 10 years back.
Micropayments never have made it out of the Trough of Disillusionment, and the accuracy of a few of the other prognostications could be readily argued about; but some seem fair enough.
...media-history-through-gartner-hype.html

5. In 2007, Cloud Computing wasn't evident
In 2007, Cloud Computing wasn't evident. More surprisingly, neither was Grid Computing.
Mesh Networks had passed the 'Peak of Inflated Expectations', but was seen to be more than 10 years away, i.e. it was thought likely to slide into the 'Trough of Disillusionment' and stay there for a while.
...uploads/2007/10/gartner2007.jpg

6. In July 2008, neither Grid nor Mesh Computing merited so much as a mention.
Cloud computing had emerged, with a 2-5 year track to 'mainstream adoption'.
By interpolarion, it was expected to reach the Peak of Inflated Expectations sometime between early 2009 and mid Even with 21 months' hindsight, that's a tenable proposition.
The Trough of Disillusionment was therefore seen as being likely some time between mid-2010 and early 2012, with 'mainstream adoption' apparent from late 2010 to 2013.
This presentation will be suggesting that there are plenty of reasons to doubt the earlier timeframes, and even to be concerned about the longer ones.
...media-history-through-gartner-hype.html

7. In July 2009, say 10 months ago, Cloud Computing was declared to be at the peak of Inflated Expectations, but with mainstream adoption still2-5 years away, i.e. mid-2011 to 2014.
'Mesh Networks: Sensor' had reappeared, sliding down from over-hyping towards disillusionment, and more than 10 years from widespread adoption.
The Gartner Hype-Cycle –

8. Gartner Hype Cycle for Cloud Computing July 2009 – $US 1,995 (53 pp.)
On the Rise
Cloud Services Governance
Cloud-Driven Prof'l IT Services, Solutions
Cloud Computing/SaaS Integration
Cloudbursting/Overdraft
Cloud Service Management Tools
Tera-architectures
Virtual Private Cloud Computing
Application Platform as a Service
Cloud Computing for the Enterprise
DBMS in the Cloud
Private Cloud Computing
Business Process Utility
Hybrid Cloud Computing
Cloud Application Development Tools
Cloud-Based Services
Cloud-Enabled BPM Platforms
Cloud Security Concerns
Cloud Storage
At the Peak
Elasticity
Enterprise Portals as a Service
Cloud/Web Platforms
Compute Infrastructure Services
'In the Cloud' Security Services
Cloud Computing
Public Cloud Computing/the Cloud
Sliding Into the Trough
Real-Time Infrastructure
IT Infrastructure Utility
SaaS
Climbing the Slope
SaaS Sales Force Automation
Virtualization
Cloud Advertising
Grid Computing
Integration as a Service
For a suitably high price, some more detailed prognostications were available.
Important elements of the overall CC notion were already climbing the slope to adoption.
A couple had slid past the Peak and were heading into the Trough, with the implication that they would either fade away or rebound quickly to follow the leading features.
Other elements were back at the Peak, or their proponents were still trying to achieve the critical mass of PR verbiage necessary to qualify the idea as being over-hyped.

9. Predecessor Terms Related Concepts
Computing as a utility / 'computer service bureaux' / 'data centres' – 1960s, 1970s
Application Service Providers (ASPs) – 1980s
working from home / tele-work – 1980s
working on the move / 'road warrior' – 1990s
docking portables to corporate networks
portable-to-desktop synchronisation
Internet Service Providers (ISPs) – late 1980s
Web Services – 2000
Service-Oriented Architecture (SOA) – early-to-mid-2000s
Software as a Service (SAAS) – late 1990s, e.g. Salesforce
Cluster Computing – inter-connected stand-alone computers are managed as a single integrated computing resource
Grid Computing – computational resources are assigned dynamically
Peer-to-Peer (P2P) architectures
Server-Virtualisation
Infrastructure as a Service (IaaS) – 2006
Platform as a Service (PaaS) – 2006
Anything as a Service *aaS / AaaS
So much for the fantasy world of 'brand-name consultancies'. What's the real world look like?
Well, Cloud Computing is both new, and quite old. There are any number of predecessor terms that have been soldand applied during the last 50 years.
And there are multiple related concepts in something of a stew of current ideas, some of which are readily detectable a little over a decade ago.
Teasing out what it is that's actually different is important.

10. Cloud Computing Definitions
"a large-scale distributed computing paradigm that is 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" (Foster et al. 2008, at the Grid Computing Environments Workshop)
five 'essential characteristics' (NIST, October 2009):
on-demand self-service (i.e. automated response by servers to direct requests by clients)
broad network access (i.e. from anywhere, using any device)
resource pooling (i.e. the provider allocates resources according to demand, rather than assigning resources to particular clients)
rapid elasticity (i.e. resources are scalable according to demand)
measured service (i.e. resource usage is metered)
There's plenty of literature that proposes definitions of Cloud Computing.
Reviews of that literature assert that no definition has achieved broad acceptance yet, but that some common features or 'essential characteristics' can be discerned. (To date, however, authors differ on what features are and are not in the list!).

11. The User Organisation Perspective A Working Definition
A service that satisfies all of the following conditions:
it is delivered over a telecommunications network
users place reliance on the service for data access and/or data processing
the data is under the legal control of the user
some of the resources on which the service depends are virtualised, i.e. the user has no technical need to be aware which server running on which host is delivering the service, nor where the hosting device is located
the service is acquired under a relatively flexible contractual arrangement, at least re the quantum used
In order to conduct an analysis from a business perspective, I had to adopt a working definition.
Pragmatically, we know that users must be depending on networked services (bullets 1 and 2).
The fourth bullet is the key technical feature – virtualisation of *something*.
The fifth is partly technical and partly contractual – pay by use.
The third makes clear that the data has to be under the legal control of the user. For example, it's not appropriate to treat analysis of publicly-available data-sets (as in eResearch applications) as being necessarily cloud computing.

12. Cloud Computing is a Form of Outsourcing How is it different from earlier forms?
Scalability ('there when it's needed)
Flexible Contractual Arrangements ('pay per use')
Opaqueness ('let someone else worry about details')
which means less user control:
of the application, through commoditisation
of service levels, through SLA dependence (assuming there's an SLA, and it's negotiable)
of host location, through resource-virtualisation
A battle-hardened CIO is going to ask the question 'Isn't this just outsourcing with a new name?'.
There are differences, but they're not quite as obvious as it might seem.
And although the differences give rise to upsides, the following analysis will show that they have downsides as well.

13. Sample Architectures
I mentioned that I'd done a rapid trawl through the more readily-accessible literature on CC.
Here are some examples of architecture diagrams.
CSA (2009) 'Security Guidance for Critical Areas of Focus in Cloud Computing'
Cloud Security Alliance, April 2009
Youseff L., Butrico M. & Da Silva D. (2008) 'Toward a Unified Ontology of
Cloud Computing' Proc. Grid Computing Environments Workshop, 2008

14. Fig. 3 High-level market-oriented Cloud architecture
Including one from the Conference Chair.
In the two on the previous slide, you have to look very hard to find the user, and the user organisation within which the user sits.
Rajkumar et al.'s diagram at least shows red icons for humans – and presumably the blue ones are for user-agents; but none for the user-organisations.
Fig. 3 High-level market-oriented Cloud architecture
Buyya R., Yeo C.S., Venugopal S., Broberg J. & Brandic I. (2009)
'Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering
computing as the 5th utility' Future Generation Computer Systems 25 (January 2009)

15. CC Architecture – The User Organisation Perspective
Well, here's how the user-organisation perceives CC.
Out there is a cloud.
And the hosts and servers are somewhere inside it, i.e. the cloud is no longer between me and a known host and server – it's enveloped it.
I can see *something* – usefully referred to as a cloud manager.
And in a mature market maybe I will see intermediaries / brokers.
And I can of course see all of my internal infrastructure, whereby I'm going to access CC services.
But all that fancy stuff in CC articles' architecture diagrams is nothing to do with the user organisation.

16. A Comprehensive CC Architecture
What has to be disturbing to a CIO is the fact that the architects seem to have overlooked the client side.
Unless you can convince my client, the CIO, that your architecture is comprehensive, i.e. encompasses the clever bits out there in the cloud *and* the CIO's infrastructure, *and* ways for the two ends to effectively and efficiently talk to one another, then you don't have a sale.
A Comprehensive CC Architecture

17. CC's Potential Benefits
Enhanced Service Accessibility
Access to Services that are otherwise unavailable
Access to Services from multiple desktop devices
Access to Services from scaled-down devices
Access to Services from multiple device-types
Other Technical Benefits
Professionalised backup and recovery
Scalability
Collaboration convenience
Copyright convenience
Financial Benefits
Lower Investment / up-front cost
Lower Operational Costs
Lower IT Staff Costs
Getting the complete architecture sorted out is a necessary condition, but not a sufficient one.
The sale depends on the CIO perceiving benefits in adopting CC.
Distilling what I can read and infer from the literature, these are the potential benefits.

18. Downsides – The User Perspective
Operational Disbenefits and Risks
Dependability on a day-to-day basis
Contingent Risks
Low likelihood / Potentially highly significant
Security Risks
Security in the broad
Business Disbenefits and Risks
Beyond the merely technical
But, to get the sale, the CIO must perceive the realisable benefits, for his organisation, right now or in the very short term, to exceed the disbenefits and the risks.
There are lost of these, and I've broken them down into these categories and list them on the following slides.

19. Operational Disbenefits and Risks
Fit – to users' needs, and customisability
Reliability – continuity of operation
Availability – hosts/server/database readiness/reachability
Accessibility – network readiness
Robustness – frequency of un/planned unavailability (97% uptime = 5 hrs/wk offline)
Resilience – speed of resumption after outages
Recoverability – service readiness after resumption
Integrity – sustained correctness of the service, and the data
Maintainability – fit, reliability, integrity after bug-fixes, mods
There's a bunch of needs that real users have, and no service is 'ready for prime time' unless they're satisfied.

20. Contingent Risks Major Service Interruptions
Service Survival – supplier collapse or withdrawal Safeguards include software escrow; escrow inspection; proven recovery procedures; rights that are proof against actions by receivers
Data Survival – data backup/mirroring and accessibility
Compatibility – software, versions, protocols, data formats
Flexibility Customisation Forward-compatibility (to migrate to new levels) Backward compatibility (to protect legacy systems) Lateral compatibility (to enable escape)
There are various nightmare scenarios.
And CIOs take great care to avoid them.

21. Security Risks
Service Security Environmental, second-party and third-party threats to any aspect of reliability or integrity
Data Security Environmental, second-party and third-party threats to content, both in remote storage and in transit
Authentication and Authorisation How to provide clients with convenient access to data and processes in the cloud, while denying access to imposters?
Susceptibility to DDOS Multiple, separate servers; but choke-points will exist
There are potential security benefits in CC.
But there are also additional security challenges to be addressed, and nomatter how they are solved, there will be additional risks, above and beyond those that are inherent in IT, and inherent in conventional outsourced IT.

22. Business Disbenefits and Risks
Acquisition Lack of information, non-negotiability of terms of contract and SLA
Ongoing Usage Loss of corporate knowledge about apps, IT services, costs to deliver Inherent lock-in effect, because of high switching costs High-volume data transfers (large datasets, replication/synch'n)
Service Levels to the Organisation's Customers
Legal Compliance Data protection law, law of confidence, financial services regulations, evidence discovery law. Company Directors' obligations re asset protection, due diligence, business continuity, risk management
Privacy Breach – Content Access, Use, Retention Second-Party (service-provider abuse), Third-Party ('data breach', 'unauthorised disclosure'), Storage in Data Havens (India, Arkansas)
There are also the specifically 'business' or 'commercial' factors.
Companies have to worry about the law in ways that laboratory experiments can usually avoid.
Not knowing where the data goes is likely to be illegal for many companies. The financial services sector is one good example. eHealth will be another.

23. Some Risk Management Strategies
Risk Assessment
Contract Terms
Service Level Agreement (SLA)
Multi-Sourcing
Parallel in-house service
Several compatible suppliers
...
Of course, these downsides can and will be addressed.
Start by doing a Risk Assessment.
Identify the contract terms that you need.
Specify the important service terms.
Make sure you're not dependent on just one supplier.

24. ITILv3 SLA Checklist – Edited Down!
1. Service name
2. Clearance information (with location and date)
1. Service Level Manager
2. Customer
3. Contract duration
1. Start and end dates
2. Rules regarding termination of the agreement
4. Description/ desired customer outcome
1. Business justification
2. Business processes/ activities oncust side supported by the service
3. Desired outcome in terms of utility
4. Desired outcome in terms of warranty
5. Service and asset criticality
1. Identification of business-critical assets connected with the service
1. Vital Business Functions (VBFs) supported by the service
2. Other critical assets used within the service
2. Estimation of the business impact caused by a loss of service or assets
6. Reference to further contracts which also apply (e.g. SLA)
7. Service times
1. Hours when the service is available
2. Exceptions (e.g. weekends, public holidays)
3. Maintenance slots
8. Required types and levels of support
1. On-site support
1. Area/ locations
2. Types of users
3. Types of infrastructure to be supported
4. Reaction and resolution times
2. Remote support
2. Types of users (user groups granted access to the service)
9. Service level requirements/ targets
1. Availability targets and commitments
1. Conditions under which the service is considered to be unavailable
2. Availability targets
3. Reliability targets (usually defined as MTBF or MTBSI )
4. Maintainability targets (usually defined as MTRS)
5. Downtimes for maintenance
6. Restrictions on maintenance
7. Procedures for announcing interruptions to the service
8. Requirements regarding availability reporting
2. Capacity/ performance targets and commitments
1. Required capacity (lower/upper limit) for the service, e.g.
1. Numbers and types of transactions
2. Numbers and types of users
3. Business cycles (daily, weekly) and seasonal variations
2. Response times from applications
3. Requirements for scalability
4. Requirements regarding capacity and performance reporting
3. Service Continuity commitments
1. Time within which a defined level of service must be re-established
2. Time within which normal service levels must be restored
10. Mandated technical standards and spec of the technical service interface
11. Responsibilities
1. Duties of the service provider
2. Duties of the customer (contract partner for the service)
3. Responsibilities of service users (e.g. with respect to IT security)
4. IT Security aspects to be observed when using the service
12. Costs and pricing
1. Cost for the service provision
2. Rules for penalties/ charge backs
13. Change history
14. List of annexes
But look at the list of things that an SLA has to include, in order to satisfy a CIO.
And then remember that some people are championing CC *without an SLA* at all.
And others are assuming that the CC service-provider will dictate the terms of the SLA, and not permit customers to negotiate on any of them.
Sorry, but CIOs will be very worried about this.

25. User Requirements Essential Features
Assured Data Integrity
Assured Service Integrity
Assured Compliance with legal requirements within jurisdictions to which the user organisation is subject
Warranties and indemnities in the contract, terms of service and SLA (if any)
But who audits and certifies?
Switching to positive mode, what can we do about this?
Firstly, recognise that a number of characteristics are mandatories.
Then ask yourself whether your architectures and designs and commercial arrangements deliver.
As a small test, do you have a table that shows, for each physical location in which a host resides, which legal jurisdiction(s) it is subject to?
Who have you used to audit and certify your terms of service and your SLA?

26. Categories of Use-Profile
UP1: CC is completely inappropriate
'mission-critical systems'
systems embodying the organisation's 'core competencies'
applications whose failure or extended malperformance would threaten the organisation's health or survival
UP2: CC is very well-suited
Uses of computing that are highly price-sensitive, and adjuncts to analysis and decision-making, not essential operations Trade off loss of control, uncertain reliability, contingent risks against cost-advantages, convenience, scalability, etc.
UP3: CC is applicable depending ...
can the risks be adequately understood and managed?
trade-offs between potential benefits vs. uncontrollable risks
Briefly, CIOs will quickly decide that there are some uses to which CC should never be put.
And there are some for which it is eminently suitable.
But as you can see, they're not very exciting.
So the real action is going to be in the third category, where 'it depends'.
And what it will depend upon is the results of risk assessments, and the extent to which CIOs are satisfied that the risks can be understood and managed.

27. User Requirements for CC Infrastructure
1. Integrity Assurance
Service Integrity
Data Integrity
2. Compliance Assurance
Service Security
Service Access Controls
Data Transmission Security
Data Storage Security
Data Use (by service-provider)
Data Disclosure (by others)
Jurisdictional Location(s) of Data Storage
3. Declaration, Measurement
Service Reliability Levels
Service Survival Protections
Data Survival Protections
Service and Data Compatibility
Service and Data Flexibility
4. Privacy Policy Enforcement Measures, to enable:
Server Privacy Policy Statement
User Privacy Rqmts Statement
Comparison of the two
Preclusion of Usage where Requirements are not satisfied
Here's a summary of the requirements that people like me will be advising CIOs to use when they do evaluations of proposals from CC services providers.

28. Implications for Cloud Computing Architectures
CCAs must be comprehensive, encompassing not only the server side, but also the client side and intermediating functions
Security Risk Assessments and Solutions must be end-to-end rather than limited to the server side
CCA designers must address the risks arising from vulnerable user devices and vulnerable clients
Client authentication must be achieved through components, APIs, and externally-managed identities (Shibboleth, OpenID)
Jurisdictional Locations of Hosts must be controlled
These all depend on CCAs including specs and implementation of multiple special-purpose components and features
Privacy management must go beyond 'privacy through policy' and 'privacy by design' to 'Privacy through Architecture'
And here are the implications that I believe my paper has for CC architectures.

29. Conclusion
"Past efforts at utility computing failed, and we note that in each case one or two ... critical characteristics were missing" (Armbrust et al. 2008, p. 5 – UC Berekeley)
CC may be just another marketing buzz-phrase that leaves corporate wreckage in its wake
CC service-providers need to invest a great deal in many aspects of architecture, infrastructure, applications, and terms of contract and SLA
CC may be a complete fizzer.
Indeed, I think it will remain in the Trough of Disillusionment, and gradually slide off into the Slough of Discontent.
*Unless* positive steps are taken relating to key aspects of architecture, infrastructure, applications, and terms of contract and SLA

30. Cloud Computing Architecture
User Requirements for
Cloud Computing Architecture
Roger Clarke, Xamax Consultancy, Canberra Visiting Professor in Computer Science, ANU and in Cyberspace Law & Policy, UNSW 2nd International Symposium on Cloud Computing Melbourne, 17 May {.html,.ppt}
Well, I didn't come to this Conference hoping to be popular (:-)}