The document discusses cloud computing and provides a case study on moving a financial company's data service to the cloud. It outlines two options: 1) migrating the existing service to Amazon EC2, which would require addressing various technical and operational challenges, or 2) redesigning the service to leverage cloud databases and services, which could reduce costs but would require significant development work. The document cautions that moving workloads to the cloud requires careful analysis and that the hype around cloud computing should be taken in perspective, as integration and other business issues are more significant than technical challenges. It emphasizes establishing metrics to measure the benefits of cloud initiatives.

1. Cloud Computing
Cl d C ti
An overview
+ a case study
Babak Hosseinzadeh
babak@newbridgestrategy.com
+1-206-612-7350

2. Some observations…
S b ti
2

3. A few examples of web-scalability
web scalability
Source: http://www.compete.com
3

4. Google & Amazon are not the only ones…
Source: http://www.compete.com
4

5. Speed is a major differentiator
ec2-describe-images
g
5

6. Living and socializing in a digital network economy…
6

7. A l k at the enterprise…
look t th t i
7

8. A quick review in the enterprise…
mplexity
Com
1970 2005
8

9. 1970 2005
Focus on “Data Processing” IT-led business innovation & transformation
The role of IT in the organization was simple Increasing demands, expectations, and business reliance on IT
Few standalone apps in select departments Different types of solutions throughout the enterprise
Af i
few internal users mostly in the same
l l i h Internal users i different locations & geos, work
I l in diff l i k
Business
location arrangements, habits… + external interactions over different
channels
Users had limited IT skills The business community is increasingly IT savvy
Business operation used to be 9 – 5 (M-F)
B i i d b (M F) 24X7 connectivity, availability, and reliability
i i il bili d li bili
Controlled & predictable workload Less controlled & unpredictable workload
System availability & reliability requirements Service Level Objectives are much more complex and impact
were simple and only effected the enterprise the value chain
Small
S ll set of vendors
f d Different types of vendors and solutions
Diff f d d l i
Simple technology stack Complex technology stacks
A few low level languages and tools Different high level languages, multiple tools (i.e. CASE,
ology
SLDC repositories, sophisticated compilers, interpreters…)
Techno
Simpler solution approach, architecture, and
i l l i h hi d “Enterprise Architecture”, multiple layers, distributed
implementation computing, exponential data growth, OO, SOA, EDA, Grid…
A few IT roles Multiple new roles, titles, and specialized skills
Central development with in-sourced resources Distributed development teams & hybrid sourcing models
p p y g
IT operation & management used to be simple IT operation and management is much more complicated
9

10. IT investments & cost allocations
WW IT Benchmark
On average, ~ 64% of IT Budget is spent on IT infrastructure
10

11. Cloud C
Cl d Computing
ti
11

12. What is Cloud Computing?
A pool of highly scalable, abstracted • Scalable, abstracted infrastructure
infrastructure, capable of hosting end‐ • Hosting environment
customer applications, that is billed by
t li ti th t i bill d b
• Utility-based billing
consumption.
A style of computing where massively
• Style of computing
y p g
scalable IT‐related functions and information
l bl IT l t d f ti di f ti
• Shared “services” are provided "as a service" using Internet
• Internet accessible technologies, potentially to multiple external
customers.
Cloud Computing an emerging IT development, deployment and delivery model, that
enables Cloud Services.
Cloud Services: Consumer and Business products, services and solutions that are
delivered and consumed in real‐time over the Internet
• IT development, deployment, & delivery model
• Dynamic p
y provisioning
g
12

13. Cloud Computing Model Solution
Business Capability
Control
Flexibility
Customization
13

14. Cloud Computing Vendor Landscape
Note: Sample list of vendors
p
14

15. Cloud Computing Responsibility Matrix
Infrastructure Hosting IaaS PaaS SaaS
Provider
Data Center Hosting provider has the Subscriber has no idea… IaaS Subscriber has no idea… PaaS Subscriber has no idea… SaaS
Management overall responsibility. provider abstracts the provider abstracts the provider abstracts the
Customers may negotiate infrastructure. infrastructure. infrastructure.
location.
Infrastructure Hosting Provider has the IaaS provider handles the (1) PaaS may run its own (1) SaaS may run its own
Operation & overall responsibility. physical infrastructure, but the infrastructure infrastructure or partner
Management Customers may negotiate subscriber is responsible for (2) PaaS may partner with an (2) SaaS may offer its own PaaS
specific terms. image creation, operation and IaaS provider or partner
management. In both cases, it is abstracted In both cases, it is abstracted
from the subscriber.
from the subscriber from the subscriber.
from the subscriber
Infrastructure Hosting Provider offers a pre‐ Subscriber creates virtual images PaaS provider offers some N/A ‐ There is typically no
Configuration / defined menu, but customers and manages the configuration capabilities for application infrastructure customization
Customization have the option pay for & customization configuration & deployment
customization
Infrastructure
I f Hosting Provider ff b i
H i P id offers basic Typically, infrastructure support
T i ll i f N/A – PaaS
N/A P S provider offers
id ff N/A ‐ Th
There iis typically no
i ll
Support support. Additional support is provided through forums. support for PaaS typically infrastructure customization
can be negotiated. Premium support can be through forums.
obtained, but Subscribers
ultimately handle infrastructure
support.
Application N/A – Customer is N/A – Subscriber is responsible N/A – Subscriber is responsible SaaS provider offers the
Development responsible. solution
Application N/A – Customer is N/A – Subscriber is responsible N/A – Subscriber is responsible SaaS provider offers some
Customization responsible. customization capabilities. 3rd
parties offer services.
parties offer services
Application N/A – Customer is N/A – Subscriber is responsible N/A – Subscriber is responsible SaaS provider handles
Maintenance responsible. maintenance for all subscribers
Application N/A – Customer is N/A – Subscriber is responsible N/A – Subscriber is responsible Typically forums 15
Support responsible.

16. An IT bill (tip included)
16

17. A Case study: Query Data Service
• Background
• Financial Company
• Multiple lines of business with some business processes interfacing 60+ external partners
• Mixed environment (packages, home grown apps, CICS, DB2, WAS, ALSB, …)
• Problem
• Maintaining service SLA (Resp-time < 3 seconds + 99.99 availability)
17

18. Option 1 – Migrate existing data service to the Cloud
• Notes
• Approach • Had to figure out development & testing requirements
• Install & configure software packages in Amazon EC2 • Had to assess for security & regulatory compliance
• Route service requests to the Cloud • Had to size for servers
• Operate and manage the service
O d h i • Had t
H d to pay for commercial software license costs
f i l ft li t
• Had to figure out operations, support, change management, etc and
• Benefits integrate them into the existing enterprise systems management
• No hardware investment framework (Tivoli & BMC)
• Quick provisioning / hassle-free server • Had to figure out SOA Governance integration
• Had to figure out secure data replication between on-premise database
• Built-in affordable scalability features (i.e. load balancing, & Cloud instances
auto scaling)
sca g) • Figure out budget & payment
Fi tb d t t
• Much better understanding of IT costs / service • Had to evaluate disaster recovery
• Client: Is this really Cloud Computing?
18

19. Option 2 – Redesigning existing data service for the Cloud
• Notes
• Approach • Had to figure out development & testing requirements
• Redesign the solution to leverage Cloud services • Had to assess for security & regulatory compliance
• Route service requests to the Cloud • Had to size for servers
• Operate and manage the service • Had to pay for commercial software license costs
• Benefits • Careful
C f l evaluation of SDB was necessary (i.e. architectural considerations,
l ti f (i hit t l id ti
• No hardware investment limitations, storage costs, etc)
• No software license costs for DB2 • Had to learn SDB programming model
• Had to figure out operations, support, change management, etc and
• Anticipated lower operational costs (i.e. DB2 systems integrate them into the existing enterprise systems management framework
administration) (Tivoli & BMC)
• Built-in affordable scalability features (i.e. load balancing, auto • Had to figure out seeding SDB & secure data replication with on-premise
scaling) database
• Enhanced understanding of IT costs / service • Figure out budget & payment
• Had to figure out SOA Governance
• Had to figure out how to abstract AWS to prevent vendor lock-in
• Had to evaluate disaster recovery
19

20. Some important research & references…
A review of enterprise projects by the Standish Group
CHAOS report: http://www.standishgroup.com/
http://mitsloan.mit.edu/cisr/ http://www.thomaslfriedman.com/
http://www.nicholasgcarr.com/
20

21. Summary
• Be careful in workload selection & analysis – Architectural decisions have to be analyzed
(i.e. transactionality)
• Beware of the hype and misinformation – (i.e. don t expect to just throw the application
don’t
into the cloud and be done…Technology issues are relatively minor compared to business
integration issues.)
• Understand and evaluate both on-premise & public cloud options - (i.e. Lots going on in
the app server space including gridification and virtualization – Talk to your vendor to learn
about roadmap and future plans).
b t d df t l )
• Should you move the particular app to the cloud or redesign it? Can it be cloud-sourced? --
relatively straight-forward and simple, but best to strike an agreement with the inner circle
quickly (i.e. an EA decision) to avoid continuing discussions, endless debates, etc…
• Assess impact/gaps on existing development, testing, deployment, operation, and
development testing deployment operation
maintenance processes – Tooling is critical for productivity and mandatory for cost-saving.
• A lot of the public cloud services have been in beta since a year ago or so…Before you
dismiss too quickly, let’s put things in perspective. Beta in Cloud Services != beta in
enterprise software.
p
• Finally, irrespective of the business motivation, it is important to establish a baseline (i.e.
avg transaction cost) for the existing workload and measure and compare thereafter to
communicate the benefits using financial terms.
21

22. Thank you
22