1. Lecture 2. Ecosystem, CAP, and Challenges
COSC6376 Cloud Computing
Lecture 2. Ecosystem, CAP, and Challenges
Instructor: Weidong Shi (Larry), PhD
Computer Science Department
University of Houston

2. Outline
Ecosystem
CAP
Challenges

3. Reading Assignment
Summary due
Next Tuesday in class

4. NIST: Interactions between Actors in Cloud Computing
Cloud Consumer
Cloud Provider
Cloud Broker
Cloud Auditor
Cloud Carrier
The communication path between a cloud provider & a cloud consumer
The communication paths for a cloud auditor to collect auditing information
The communication paths for a cloud broker to provide service to a cloud consumer

5. Classes of Cloud Players

6. Six Layers of Cloud Services
Salesforce.com, Webex, …
App Engine, Microsoft
Azure
Amzon AWS, Racksapce,
IBM Ensembles
Savvis, Intermap,
Digital Realty Trust
AT & T
VMWare, IBM, Xen

7. Spectrum of Clouds Instruction Set VM (Amazon EC2, 3Tera)
Bytecode VM (Microsoft Azure)
Framework VM
Google AppEngine, Force.com
Lower-level,
Less management
Higher-level,
More management
EC2
Azure
AppEngine
Force.com

8. Amazon EC2
Like physical hardware, users can control nearly the entirely software stack, from the kernel upwards.
A few API calls to request and configure the virtualized hardware.
No limit on the kinds of applications that can be hosted.
Low level of virtualization-raw CPU cycles, IP connectivity-allow developers to code whatever they want.
Hard to offer scalability and failover.

9. Google AppEngine and Force.com
Does one thing well: running web apps
App Engine handles HTTP(S) requests, nothing else
Think RPC: request in, processing, response out
Works well for the web and AJAX; also for other services
Request-reply based. Not suitable for general- purpose.
Severely rationed in how much CPU time they can use in a request.
Automatic scaling and high-availability.

10. Microsoft’s Azure
Written using the .NET libraries, and compiled to the language independent managed environment.
General -purpose computing.
Users get a choice of language, but can not control the operating system or runtime.
Libraries provide automatic network configuration and failover/scalability but need users' cooperation also.

11. Spectrum Azure General-purpose Can not control OS
A degree of scalability
Google appengine/force.com
Highly scalable
Yet not general-purpose
Amazon EC2
General-purpose
Hard to offer scalability

12. Major Cloud Providers and Service Offerings

13. Public, Private, and Hybrid Clouds

14. Hybrid Clouds
Using multiple clouds for different applications to match needs
Moving an application to meet requirements at specific stages in its lifecycle, from early development through unit test, scale testing, pre-production and ultimately full production scenarios
Moving workloads closer to end users across geographic locations, including user groups within the enterprise, partners and external customers
Meeting peak demands efficiently in the cloud while the low steady-state is handled internally
Maintaining confidential data on better protected clouds while allowing distributed computation on more computationally efficient ones.

16. Deployment Generic Scenario Perspective2.
Manage a Single Cloud 8.
Operate across Clouds
Clouds 7.
Work with a Selected Cloud
6. Interface Clouds
5. Migrate Between Clouds 1.
Deploy to a Cloud 3.
Interface to a Cloud
Enterprise Systems
4. Migrate to a Cloud

17. The Combined Conceptual Reference Diagram
Cloud Carrier
Cloud Consumer
Cloud
Auditor
Broker
Security
Audit
Privacy
Impact Audit
Performance
Cloud Service Management
Service Layer
Business
Support
Service
Arbitrage
Aggregation
Service Intermediation
Provisioning/
Configuration
Portability/
Interoperability
Physical Resource Layer
IaaS
SaaS
PaaS
Resource Abstraction and Control Layer
Hardware
Facility

18. Cloud Interoperability Standards
Open Cloud Computing Interface – Infrastructure
EC2 API
Simple Storage Service (S3) API
Windows Azure Storage Service REST APIs
Windows Azure Service Management REST APIs
Deltacloud API
Rackspace Cloud Servers API
Rackspace Cloud Files API
Cloud Data Management Interface
vCloud API
GlobusOnline REST API

19. CAP

20. The CAP Theorem
Three properties of a system: consistency, availability and partitions
Availability
Consistency
Partition tolerance 20

21. The CAP Theorem
Once a writer has written, all readers will see that write
Availability
Consistency
Partition tolerance

22. Consistency Model
A consistency model determines rules for visibility and apparent order of updates.
For example:
Row X is replicated on nodes M and N
Client A writes row X to node N
Some period of time t elapses.
Client B reads row X from node M
Does client B see the write from client A?
Consistency is a continuum with tradeoffs
For NoSQL, the answer would be: maybe
CAP Theorem states: Strict Consistency can't be achieved at the same time as availability and partition-tolerance.

23. Eventual Consistency
When no updates occur for a long period of time, eventually all updates will propagate through the system and all the nodes will be consistent
For a given accepted update and a given node, eventually either the update reaches the node or the node is removed from service

24. The CAP Theorem
Every request received by a non-failing node in the system must result in a response (must terminate)
System is available during software and hardware upgrades and node failures
Availability
Consistency
Partition tolerance

25. Availability
Traditionally, thought of as the server/process available five 9’s ( %).
However, for large node system, at almost any point in time there’s a good chance that a node is either down or there is a network disruption among the nodes.
Want a system that is resilient in the face of network disruption

26. The CAP Theorem
A system can continue to operate in the presence of a network partitions.
Availability
Consistency
Partition tolerance

27. The CAP Theorem
You can have at most two of these three properties for any shared-data system
To scale out, you have to partition. That leaves either consistency or availability to choose from
In almost all cases, you would choose availability over consistency C A P
Availability
Partition-resilience
Claim: every distributed system is on one side of the triangle.

28. Challenges

29. Adoption Challenges Challenge Opportunity Availability
Multiple providers & DCs
Data lock-in
Standardization
Data Confidentiality, Auditability, and privacy
Encryption, VLANs, Firewalls; Geographical Data Storage; Privacy preserving data outsourcing

30. Challenges and Opportunities
Availability of Service
Service
Duration
Data
S3 outage: authentication service overload leading to unavailability
2hours
2/15/08
S3 outage: Single bit error leading to gossip protocol blowup.
6-8hours
7/20/08
AppEngine partial outage: programming error
5 hours
6/17/08
Gmail.
1.5hours
08/11/08

31. Adoption Challenges Challenge Opportunity Availability
Multiple providers & DCs
Data lock-in
Standardization
Data Confidentiality, Auditability, and privacy
Encryption, VLANs, Firewalls; Geographical Data Storage; Privacy preserving data outsourcing

32. Challenges of Datasets over Multiple Clouds
Interesting datasets might be available in different clouds
Different cloud providers
Private or public clouds
Services mashing up datasets
Inevitably crossing clouds
Federated cloud architectures

33. Adoption Challenges Challenge Opportunity Availability
Multiple providers & DCs
Data lock-in
Standardization
Data Confidentiality, Auditability, and privacy
Encryption, VLANs, Firewalls; Geographical Data Storage; Privacy preserving data outsourcing

34. Growth Challenges Challenge Opportunity Data transfer bottlenecks
FedEx-ing disks, Data Backup/Archival
Performance unpredictability
Improved VM support, flash memory, scheduling VMs
Scalable storage
Invent scalable store
Bugs in large distributed systems
Invent Debugger that relies on Distributed VMs
Scaling quickly
Invent Auto-Scaler that relies on ML; Snapshots

35. Challenges and Opportunities
∙Data Transfer bottlenecks
Obstacles: large data transferring is expensive.
e.g. Ship 10 TB from UC Berkeley to Amazon
Bandwith: 20 M/s
Time: 45 days
Money: $1000
Opportunities: Ship disks.
Make it attractive to keep data in cloud.
Reduce the cost of WAN bandwidth.

36. Growth Challenges Challenge Opportunity Data transfer bottlenecks
FedEx-ing disks, Data Backup/Archival
Performance unpredictability
Improved VM support, flash memory, scheduling VMs
Scalable storage
Invent scalable store
Bugs in large distributed systems
Invent Debugger that relies on Distributed VMs
Scaling quickly
Invent Auto-Scaler that relies on ML; Snapshots

37. Algorithms on Big data Working on “Big Data”
Data mining
Machine learning
Visualization
Traditionally assume data is in
flat files or relational databases
Distributed data organization puts new challenges
Redesign algorithms
Redesign frameworks

38. Policy and Business Challenges
Opportunity
Reputation Fate Sharing
Offer reputation-guarding services like those for
Software Licensing
Pay-for-use licenses; Bulk use sales

39. Come to the Dark Side Spam as a service Crimeware as a service
Password cracking cloud
DoS attack as a service
How likely is the risk
buy services using stolen credit card numbers
create ec2 instances using stolen keys
attack authentication (SOAP, XML. XML wrapping attacks)

40. Policy and Business Challenges
Opportunity
Reputation Fate Sharing
Offer reputation-guarding services like those for
Software Licensing
Pay-for-use licenses; Bulk use sales