1. Cloud Computing

2. Definition
“Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability.”

3. What is cloud computing?
I don’t understand what we would do differently in the light of Cloud Computing other than change the wordings of some of our ads
Larry Ellision, Oracle’s CEO
I have not heard two people say the same thing about it [cloud]. There are multiple definitions out there of “the cloud”
Andy Isherwood, HP’s Vice President of European Software Sales
It’s stupidity. It’s worse than stupidity: it’s a marketing hype campaign.
Richard Stallman, Free Software Foundation founder

4. Business attributes
Access resources from cloud of available computing resources
Is always available and scales automatically to meet demand
Is pay per use: Based on resources consumed
Enables full customer self-service
Note: Can be provided by 3rd party (e.g. Amazon) or on own network for v. large organisations (a.k.a private cloud)
Acquire resources on demand
Release resources when no longer needed
Turns capital investment/fixed cost into operating costs/variable costs
Reduced cost – take advantage of economies of scale across users of cloud

5. Technology attributes
Access computing resources via Internet protocols from any computer
Reduced system administration overhead: automated provisioning
Increased/matched reliability and security
Acquire resources on demand
Increased utilisation through sharing of resources through virtualisation or multi-tenancy
To minimise the cost to the provider, clouds rely on a large number of ‘commodity’ processors. These are cheaper to purchase and consumer less power per unit of processing when compared to high power processors
No longer design deployment environment to meet maximum load

6. The NIST Cloud Definition Framework
Hybrid Clouds
Deployment
Models
Community
Cloud
Private Cloud
Public Cloud
Service
Models
Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
Resource Pooling
Broad Network Access
Rapid Elasticity
Measured Service
On Demand Self-Service
Essential
Characteristics
Low Cost Software
Virtualization
Service Orientation
Advanced Security
Massive Scale
Resilient Computing
Homogeneity
Geographic Distribution
Common
Characteristics
Based upon original chart created by Alex Dowbor -

7. The NIST Cloud Definition Framework
OS Virtualisation leads directly to resilient computing, rapid elasticity and advanced security
In case of VM based cloud, facilitates measured service as hypervisor tracks usage
Multi-tenancy provides rapid elasticity
On Demand Self-Service
Essential
Characteristics
Broad Network Access
Rapid Elasticity
Resource Pooling
Measured Service
Massive Scale
Resilient Computing
Homogeneity
Geographic Distribution
Common
Characteristics
Virtualization
Service Orientation
Low Cost Software
Advanced Security
Based upon original chart created by Alex Dowbor -

8. The NIST Cloud Definition Framework
A number of other attributes rely on the scale of investment undertaken by cloud providers
Early cloud promoters (e.g. Amazon & Google) had to build massive scale for their main businesses
Use of open source software and commodity hardware reduces overall cost to cloud provider
On Demand Self-Service
Essential
Characteristics
Broad Network Access
Rapid Elasticity
Resource Pooling
Measured Service
Massive Scale
Resilient Computing
Homogeneity
Geographic Distribution
Common
Characteristics
Virtualization
Service Orientation
Low Cost Software
Advanced Security
Based upon original chart created by Alex Dowbor -

9. 4 Cloud Deployment Models
Private cloud
Cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise
Typically only large organisations
Public cloud
Cloud infrastructure is made available to the 3rd parties but is owned by an organization selling cloud services
Cloud services designed to be ‘generic’ and suitable to all customers
E.g. Amazon, Google, Microsoft, BM etc

10. 4 Cloud Deployment Models
Community cloud
Cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations)
May be managed by the organizations or a third party and may exist on premise or off premise
Hybrid cloud
composition of two or more clouds that remain unique and separate entities but are bound together by standardized or proprietary technology that enables data and application portability
Cloud bursting is the term used to describe the process where an organisation extend from a private to public cloud

11. Client access architecture
Client access via browser of Web Services
Independent of type of cloud computing
Platform VM
App 1
Server OS
Database
App Server
Storage
Network
App 1
App server Or
Clients
Access via
Browser Or
web-service
(SOAP or REST) DB OS
Network
Storage

12. Service model architecture
Software As A Service (SaaS)
Datastore as a service
Platform As A Service (PaaS)
Infrastructure As A Service (IaaS)
Four main service model architectures
Datastore as a service is not always included although currently the most popular use of cloud
Significant differences in the technical and commercial architectures

13. Service model architecture: Datastorage as a servce
Software As A Service (SaaS)
Datastore as a service
Platform As A Service (PaaS)
Infrastructure As A Service (IaaS)
Functional: Data storage interfaces can be used by any of the other types or accessed directly
Examples of direct usage: Amazon’s really simple storage
Commercial: Charged on basis of amount of storage used

14. Characteristics of cloud datastore
Cloud based datastore is massively distributed and scalable
Utilises large number of commodity servers (a.k.a. nodes)
This implies that the chance of system failure across a large number of nodes is high
Therefore, cloud datastore must cope with node failure
Cloud datastores are typically non-relational
Distribution across a large number of nodes not a good fit to the relational model of databases. Relational databases support “joins” which are hard to implement in a massively distributed way
To address requirement for relational database capabilities
Either provide relational interfaces to non-relational infrastructure
Allow relational databases to run on a small number of nodes as part of the virtualisation

15. Characteristics of cloud datastore
Cloud datastores are optimised for large scale data search
E.g. Google’s MapReduce (and hadoop – an open source implementation) which divide the processing into multiple blocks (Map) and then process each block on one or more nodes (reduce)
Cloud datastores are also appropriate to business intelligence applications which require ‘column’ based processing
E.g. Summing sales in a particular region
In contrast, relational databases are efficient for record/row level read/write

16. Service model architecture: IaaS
Software As A Service (SaaS)
Datastore as a service
Platform As A Service (PaaS)
Infrastructure As A Service (IaaS)
Functional: Virtual server instances available for provisioning
Examples: Amazon’s EC2,
Commercial: Charged on basis of number /scale of instances as well as usage profile

17. Example: Amazon EC2
Amazon provides a range of general purpose support services accessible via VMs
Examples of these services include
Simple Queue Service: Limited messaging system for communications between VMs
S3: Cloud storage service

18. Example: Amazon EC2 Other examples of these services (cont)
SimpleDB: Non-relational database
Elastic MapReduce: large scale search and text processing infrastructure
Flexible payment service: enabling website payments
Mechanical Turk: outsourcing marketplace

19. Amazon EC2 options and pricing
Aws.amazon.com/ec2

20. Service model architecture: PaaS
Software As A Service (SaaS)
Datastore as a service
Platform As A Service (PaaS)
Infrastructure As A Service (IaaS)
Functional: Application development and deployment environment
Provides programming APIs as well as underlying infrastructure
Commercial: Metering and billing based on application usage – typically CPU consumption/datastore consumption

21. Example: Google AppEngine
Platform uses multiple tenancy on the single infrastructure
Benefit of charging only on usage and not on number of instance (as with IaaS)
Provides general purpose support services
Includes infrastructure services such as database
Also includes application level interfaces such as video conferencing
Provides both server and client side APIs to develop Google AppEngine applications
Provides a platform which is proprietary

22. Example: Microsoft Azure Services
Access to the Microsoft platform as a cloud based platform
Provides a platform which is proprietary
Source: Microsoft Presentation, A Lap Around Windows Azure, Manuvir Das

23. Service model architecture: SaaS
Software As A Service (SaaS)
Datastore as a service
Platform As A Service (PaaS)
Infrastructure As A Service (IaaS)
Functional: End user interaction with the Application’s function
Allows for customisation of UI and workflows
Often uses mult-tenancy databases
Commercial: typically billing based on number of users

24. Example: Salesforce.com
Provides complete application accessible from the cloud
Infrastructure is hidden from the user
Software can be configured to support customer specific requirements
Supports customisation through configuration driven language
Scope for customisation is limited
Uses multi-tenancy architecture
Essential a platform for a specific class of application
Configuration results in a change to both UI and underlying database schema for that customer

25. Examples of configuration
UI actions (such as entering an address) can have customised scripts associated with them which perform workflow or validation logic
Workflow defines the sequence of steps through the UI screens
Validation logic enforces rules about information entered based on customer specific standards or context specific restraints (i.e. What can be entered given the current workflow)
These may not effect the database schema definition and therefore can be deployed only to that customers UI

26. Examples of configuration
UI definitions (or associated workflows) may also require modifications/extensions to the database schema
Through multi-tenancy/multi-schema approach, the metadata defining the schemas specific to that customer is modified without impacting on the ‘base’schema or the other customers’ deployed schemas

27. Different types of SaaS
Type 1: Ad-Hoc/Custom
Type 2: Configurable
Type 3: Configurable, Multi-Tenant-Efficient
Type 4: Scalable, Configurable, Multi-Tenant-Efficient
Source: Architecture Strategies for Catching the Long Tail, Frederick Chong and Gianpaolo Carraro Microsoft Corporation April 2006, 27
Source: Microsoft MSDN Architecture Center 27

28. Different types of SaaS
Type 1: Ad-Hoc/Custom
Each customer (or tenant) has there own instance of the application which can be customised on an individual basis
Level 1 SaaS is equivalent to application hosting 28 28

29. Different types of SaaS
Type 2: Configurable
A single application base is customised for each customer/tenant
Customisation is deployed within each instance of the application
Deployment of upgrades across the instance will require roll-out to each instance 29 29

30. Different types of SaaS
Type 3: Configurable, Multi-Tenant-Efficient
A single application base and instance is customised for each customer/tenant
Customisation is deployed at run-time within each instance of the application
Single instance is more resource efficient than multiple instances
Deployment of upgrades made to a single instance 30 30

31. Different types of SaaS
Type 4: Scalable, Configurable, Multi-Tenant-Efficient
Uses a tenant load balancer to balance load between multiple instances
Similar to a hypervisor
Should provide superior scalability and efficiency
Requires deployment of upgrades to made to multiple instances 31 31

32. Conclusions: Understanding the different service model architectures
Different levels of abstraction
OS: Amazon EC2
Application development framework : Google AppEngine
Applicaton customisation: Salesforce
Similar to languages
Higher level abstractions can be built on top of lower ones
Lower-level,
More flexibility,
More management
Scalability through configuration
Higher-level,
Less flexibility,
Less management
Automatically scalable
3 ti
EC2
Azure
AppEngine
Salesforce.com
IAAS
PAAS
SAAS

33. Cloud and security

34. General Security Challenges
Security/data control is the most often cited issue with migration to the cloud
Issues include:
Trusting vendor’s security model
Customer inability to respond to audit findings (dependent on service provider to modify service)
Obtaining support for investigations
Indirect administrator accountability
Proprietary implementations can’t be examined
Loss of physical control

35. Cloud Security Challenges Part 1
Data dispersal and international privacy laws
EU Data Protection Directive and U.S. Safe Harbor program
Exposure of data to foreign government and data subpoenas
Data retention issues
Mostly addressed by cloud vendor providing geographic specific services
Clear data ownership
Quality of service guarantees
Reliability of cloud service providers’ service in the context of enterprise level quality of service commitments (typically with required recovery times in seconds or minutes)
Potential for massive outages

36. Cloud Security Challenges Part 2
Dependence on secure hypervisors (for IaaS) or Multi-tenancy (in both PaaS and SaaS)
Attraction to hackers (high value target)
Security of virtual OSs in the cloud
Encryption needs for cloud computing
Encrypting access to the cloud resource control interface
Encrypting administrative access to OS instances
Encrypting access to applications
Encrypting application data at rest
Lack of public PaaS/SaaS version control
Changes to the service may occur with out explicit agreement from the customer – unlike tightly controlled lifecycle management within an enterprise