You are on page 1of 36

Cloud Computing

ECE7650
Cloud Computing Case Study
 At one extreme, sharing basic IT infrastructure
 E.g Amazon’s EC2: an EC2 instance appears physical HW,
users can control nearly the entire sw stack, from the
kernel upwards
 At the other extreme, sharing application domain-
specific platforms
 E.g. Google AppEngine, a platform for building and
hosting web applications on Google Web servers. Limited
range of applications are supported,
 In the middle, sharing programming environments
 Microsoft’s Azure written using .NET libraries, and
compiled to the Common Langurage Runtime (CLR).

Cloud Computing 2
Amazon Web Services
 AWS is a collection of remote computing services that together
make up a cloud computing platform, offered over the Internet by
Amazon.com.
 List of AWS products
 Amazon Elastic Compute Cloud (EC2) provides scalable virtual private
servers using Xen.
 Amazon Simple Storage Service (S3) provides Web Service based
storage.
 Amazon SimpleDB allows developers to run queries on structured data. It
provide "the core functionality of a database."
 Amazon Elastic MapReduce allows developers to easily and cheaply
process vast amounts of data. It uses a hosted Hadoop framework
running on the web-scale infrastructure of EC2 and Amazon S3.
 Amazon Virtual Private Cloud (VPC) creates a logically isolated set of
Amazon EC2 instances which can be connected to an existing network
using a VPN connection.
 And More…

Cloud Computing 3
Amazon’s EC2
 Amazon Elastic Compute Cloud (EC2)
 Web service that provides resizable compute capacity in
the cloud
 An EC2 instance appears physical HW, provides
users complete control over nearly entire sw
stack, from the kernel upwards
 Load Variety of operating system
 Install Custom applications
 Manage network access permission
 Run image using as many/few systems as you desire

C. Xu @ Wayne State Cloud Computing 4


Amazon’s EC2 features
 Elastic capacity
 Elastic resource config/reconfig; Elastic num of instances
 Completely Control
 Root access/access to console output/data store/ reboot
 Reliable
 Multiple locations
 Elastic IP addresses
 Secure
 Firewall config
 Virtual Private Cloud
 Performance
 Auto Scaling
 Auto local balancing

Cloud Computing 5
Amazon’s EC2 Instances
 On-Demand Instances
 Pay for capacity without long-term commitment
 Reserved Instances
 Standard Instances
 Micro Instances
 High-Memory Instances
 High-CPU Instances
 High-I/O instance
 High Storage Instances
 Spot Instances
 Bit on unused Amazon EC2 capacity, run those instances for as
long as their bid exceeds the current Spot Prices

C. Xu @ Wayne State Cloud Computing 6


Amazon’s EC2 Usages
 Create an Amazon Machine Image (AMI) containing your
applications, libraries, data and associated configuration
settings. Or use pre-configured, templated images to get up
and running immediately.
 Choose the types of instances and OS, then start, terminate,
and monitor as many instances of your AMI as needed, using
the web service APIs or the variety of management tools
provided.
 Determine whether you want to run in multiple locations,
utilize static IP endpoints, or attach persistent block
storage to your instances.
 Pay only for the resources that you actually consume, like
instance-hours or data transfer.
 http://www.youtube.com/watch?v=JPFoDnjR8e8

Cloud Computing 7
Amazon’s S3
 Amazon Simple Storage Service (S3)
 Storage for the Internet.
 Features
 Unlimited Storage
 Highly scalable
• in terms of storage, request rate and concurrent users
 Reliable
• Store redundant data in multiple facilities and on multiple devices
 Secure
• Flexibility to control who/how/when/where to access the data
 Performance
• Choose region to optimize for latency/minimize costs

 Work with other AWS products


 EC2/Elastic MR/Amazon Import/Export…

C. Xu @ Wayne State Cloud Computing 8


Example : online photo processing service
 Photo operation
 red eye reduction/cropping/customization/re-coloring/teeth
whitening, etc
 Procedure
 Web server receive request
 Put request message in the queue
 Pictures stored in S3
 Multiple EC2 instances run photo processing
 Put back in the queue
 Return

Cloud Computing 9
Google’s AppEngine
 A platform for building and hosting web
applications on Google data servers.
 support Python/Java
 Upload and ready to run
 No need to maintain your own servers, easy to scale as
your traffic and storage grow
 Kevin Gibbs, App Engine Tech Lead
“AppEngine is a system that exposes various
pieces of Google’s scalable infrastructure so that
you can write server-side applications on top”

Cloud Computing 10
AppEngine Does One Thing Well
 AppEngine handles HTTP(S) requests, nothing else
 Think RPC: request in, processing, response out
 Dynamic web serving, with full support for common web technologies
 App configuration is dead simple
 No performance tuning needed
 Everything is built to scale
 “infinite” number of apps, requests/sec, storage capacity
 Automatic scaling
 Automatic management
 Load balancing/monitoring/scaling

 Local development Environment: simulation


 Google AppEngine Software Development Kit

Cloud Computing 11
AppEngine Service
 URLFetch
fetch web resources/services
 Images
 manipulate images: resize, rotate, flip, crop
 Google Accounts
 Allow users to sign in their product by using G account
 Mail
 Send message using Google infrastructure.
 XMPP
 send instant messages
 Datastore
 managing data objects

 Memcache
 Distributed in-memory data cache in front of constant storage

Cloud Computing 12
App Enginer Sandbox
 Appl run in a secure environment that
provides limited access to the underlying
OS.
 Allow AppEngine to distribute web requests for
the application across multiple servers; Start
and stop servers to meet traffic demands
 Isolates your appl in its own secure, reliable
environment that is independent of the hw, OS,
and physical location of the web server

Cloud Computing 13
App Enginer Sandbox
 Limited Access:
 Appl can only access other computers on the
Internet through provided URL fetch and email
API
 Cannot write to file system, can read file
uploaded by the appl; The app must use the App
Engine datastore for all data that persists
between requests
 Run in response to a web request, and must
return response data within 30 seconds. A
request handler cannot spawn a sub-process or
execute code afte the response has been sent.
Cloud Computing 14
App Engine Architecture (python)
req/resp
stateless APIs

urlfech Python stdlib


VM
mail
process app
images

stateful datastore
APIs memcache

Cloud Computing 15
App Engine Architecture

Cloud Computing 16
Why Not LAMP?
 Linux, Apache, MySQL/PostgreSQL,
Python/Perl/PHP/Ruby
 LAMP is the industry standard
 But management is a hassle:
 Configuration, tuning
 Backup and recovery, disk space management
 Hardware failures, system crashes
 Software updates, security patches
 Log rotation, cron jobs, and much more

More Important…

Cloud Computing 17
Automatic Scaling
 Low-usage apps: many apps per physical host
 High-usage apps: multiple physical hosts per app

 Stateless APIs are trivial to replicate

 Datastore built on top of Bigtable; designed to


scale well
 Abstraction on top of Bigtable

Cloud Computing 18
Automatic Scaling
 You don’t need to configure your resource needs
 One CPU can handle many requests per second
 Apps are hashed onto CPUs:
One process per app, many apps per CPU
 Creating a new process is a matter of cloning a generic “model”
process and then loading the application code (in fact the
clones are pre-created and sit in a queue)
 The process hangs around to handle more requests (reuse)
 Eventually old processes are killed (recycle)
 Busy apps (many QPS query per sec) get assigned to multiple CPUs
 This automatically adapts to the need

• as long as CPUs are available

Cloud Computing 19
AppEngine’s Resource Limit

Quota Limit
Apps per developer 10
Time per request 30 sec
Quota Free Quota
Files per app 1,000 Emails per day 2,000
HTTP response size 10 MB BW in per day 10,000 MB

Datastore item size 1 MB BW out per day 10,000 MB


Secure BW in per day 2,000 MB
Appl code size 150 MB
Secure BW out per day 2,000 MB
CPU megacycles per day 200,000,000
HTTP Requests per Day 1,333,328*
Datastore API calls per day 10,368,000*
Data stored 1 GB

URLFetch API calls per day 657,084*


Cloud Computing 20
AppEngine Development Demo
 http://www.youtube.com/watch?v=tcbpTQ
XNwac

Cloud Computing 21
Microsoft’s Azure
 Cloud service platform hosted in MS data centers,
including an OS, Windows Azure, and a set of
developer services like .NET services, Live
services, and SQL data services
 Window Azure: serving as the development, service
hosting, data storage and service management
environment

Cloud Computing 22
Components of Azure
Compute , Storage , Fabric Controller , Content
Delivery Network (CDN) , Connect

Cloud Computing 23
Compute
 Web role: web-based application
 Worker role: various windows-based code
 VM role: Windows Server image, customized software
installations on OS will be kept.

Cloud Computing 24
Compute
 Submit an application with configuration of type
and number of instances
 Fabric controller creates VM and runs the code
 Requests through HTTP/HTTPS/TCP are load
balanced across all instances without affinity.
 Exposed API that allows
 automatically scale up and down.
 application logging
 Monitoring resource usage: CPU/storage

Cloud Computing 25
Storage: Blob, Table and Queue
 Blob
 Simple unstructured hierarchy: each container holds one or more blobs, which is up
to terabyte
 Access from URI: http://<StorageAccount>.queue.core.windows.net/<QueueName>
 Basic storage

Cloud Computing 26
Storage: Blob, Table and Queue
 Tables
 Structured storage.
 Stored in a group of entities that contain properties.
 Entity with different num of properties in various types.
 Not relational
tables, support
massively scalable
applications.

Cloud Computing 27
Storage: Blob, Table and Queue
 Queues
 Provide a way for communication between instances

Three replications for all kinds


Cloud Computing 28
Fabric Controller
 All Azure application and data reside in Microsoft
data center
 All Azure components are managed by the fabric
controller.

Cloud Computing 29
Fabric Controller
 Distributed application that’s replicated
across machines.
 It owns all of the resources: computer,
switches, load balancers and is aware of
each azure application
 Autonomic management
 Monitoring the system status
 Optimizing hardware utilization
 Create VMs and intelligent deployment
 Update instances without shutdown
 Managing the OS for Web and Work roles

Cloud Computing 30
Content Delivery Network
 The CDN stores copies of a blob at sites closer to
the clients that use it
 Servers store videos, Flash, HTML5…

Cloud Computing 31
Connect
 Effectively connecting on-premises environments with Windows Azure
 Installing a Endpoint Agent on each on-premises machines and communication
through IP-level connection
 Azure applications appears to be on the same IP network as the on-premises
machines.

Cloud Computing 32
Case Study 1
 Large scale web applications with occasional huge spikes and background
processing.
 Video sharing site
 Deployment
 A number of web instances
based on demand
 Table storage
for information
 Many works for
processing
 Blobs storage for
large data set

Cloud Computing 33
Case Study 2
 Parallel processing applications
 Financial modeling at a bank
 New drug testing simulations in a pharmaceutical company

 Deployment
 Web role for access interface
 Many workers

for processing
 Large data set

stored in blobs

Cloud Computing 34
Case Study 3
 Using storage from an on-premises or hosted application
 Archive old email
 User log file

 Deployment
 Connect on-premises
application with Azure

Cloud Computing 35
Case Study

Cloud Computing 36

You might also like