SATURN 2011 Session: SOA and Cloud Computing (morning session, May 18, 2011)

Notes by Peter Foldes

Architectural Implications of Cloud Computing
Grace Lewis, SEI

Abstract

Agenda:

  • Cloud computing concepts
  • Architectural implications of cloud computing
  • Final thoughts

What is cloud computing by Ian Foster: Large scale; distributed

Cloud computing types:
By capability

  • SaaS
  • PaaS
  • IaaS

by who can access it

  • Private
  • Public

IaaS
Computational infrastructure:

  • Amazon EC2
  • S3
  • IBM Computing on Demand
  • Microsoft

PaaS:
Application deployment platform, create and host applications

  • Akamai EdgePlatform
  • Force.com
  • Google App engine
  • Microsoft Azure
  • Yahoo! Open Strategy; social focus

SaaS
License application to customers for use as a service

  • Google Docs
  • Salesforce.com
  • Zoho

Public access:

  • offered as a service, usually over internet
  • typically pay-per-use
  • users can scale on demand and do not need to purchase hardware
  • cloud providers manage infrastructure and pool resources required

Private:

  • deployed inside the firewall and managed by user organization
  • user organization owns and manages it

Drivers:

  • scalability: large amount of resources
  • elasticity: decide resource utialization based on changing needs
  • virtualization: since view of the available resources
  • lower infrastructure cost
  • availability: access from around the globe
  • collaboration
  • risk reduction
  • reliability: cloud providers have reliability mechanism

Barriers:

  • security: no control over data storage
  • interoperability: No universal standards and/or interfaces
  • latency
  • resource control
  • platform or language constraints
  • regulation: data protection, fair information practices, etc.

Architectural implications of cloud computing
IaaS example

  • security measures: where and how? Do I trust provider’s logs? Do I have my own, sync, or check against?
  • availability: How do you know it went down? Will I wait for the provider?

PaaS example:

  • What data is stored in the cloud?
  • Is it possible to do calculation on the cloud, but keep data locally.
  • Question: Assuming you can do the above; how? Many patterns to use, for example normal user data in cloud, special clients in private networks.
  • cloud bursting: I use local resources, if I overuse it I use cloud resources.
  • moving application to the cloud; for example switching databases might be a problem
  • Authentication is done where?

SaaS example:

  • System is mostly outside the organizational control.
  • Part of system inside, part in the cloud for example. How do the clients react
  • Monitor system preformance and usage through the administrator interface; but do you trust that?
  • Security of the infrastructure compatible with the cloud part? For example using single sign-on.

Cloud consumer example decision:
#1 data model

  • local vs remote
  • total vs partitioned
  • distributed vs centralized
  • security model

Challenges:

  • data privacy question
  • performance and latency issues
  • data sych is definitely a problem

Question: privacy and performace might intervene, encription adds latency

#2 user authentication model

  • local vs remote authentication
  • single sign-on or separate authentication
  • authentication method

Challenges:

  • sych of identity data
  • who’s doing auditing?
  • incompatible methods

#3 allocation of finctionality
What functionality to deploy in the cloud, and what extras you need?

  • need new security?
  • management interface, is the one provided enough?

#4 Cloud Bursting

  • when to activate it?
  • how to get data back from the cloud as those resources are not needed anymore?
  • when to turn it off?

#5 resource management

  • how to detect failure?
  • how to monitor SLA?
  • what when and where to log?

Cloud provider example decisions:
#1 multi-tenancy
Meaning multiple users of the cloud service

  • tenant awareness, know who’s using what
  • data isolation
  • performance isolation

#2 Virtualization strategy

  • focus on dedicated resource vs extra applications provided
  • how to hande hardware fallout and management?

#3 Resource interfaces
APIs:

  • IaaS: provisions, configuration, management. For example, create image
  • PaaS: for example, send email, upload app code
  • SaaS: very specific access

Final thoughts:
Good publications: Hype Cycle for Emerging Technologies (Gartner)
Still overhyped, but it’s getting real.

What happened to SOA: Not emerging anymore, it’s mainstream.

  • cloud computing is in essence an economic model
  • The cloud is real (small enterprises).

Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design
Olaf Zimmerman, IBM Research

Abstract and presentation slides

Agenda:

  • architectural decision modeling concepts
  • recurring SOA design decisions
  • guidance models for other domains
  • SOA decision making models (SOAD)

Architectural decision definitions

  • Grady Booch’s definition
  • IEEE Software article: “Architectural Decisions as Reusable Design Assets”
  • IBM UMF work product description ART 0513 (previously ARC 100)

Example of an architectural decision using IBM Unified Method Framework (UMF)

  • ID
  • Name
  • Decision made
  • Problem or issue
  • Assumption, motivation, alternatives, justification
  • Implications, derived requirements, related decisions

This is a lot of work, not many people fill out the full table.

Example architecture to show designs
Observation: required architectural decisions not specific to the case; they recur
Challenges: SOA literature does not make required decisions explicit.

Refined IBM UMF table and introduced a guidance (issues and alternatives) and decision (solution) model as a UML metamodel

  • Stores decisions done based on domains
  • It’s implemented since 2006
  • About 500 decisions for SOA stored

From AD Documentation to Active Method Guidance; decisions documented iteratively, capturing all steps.

Example decisions

  • format for decisions: decision drivers, isuues, alternatives, and recommendation
  • There are decisions in each architectural layer.
  • Based on drivers and alternatives coming from the knowledgebase, recommendations can be made.
  • can be used as a roadmap to guide through architects

Skipping strategic outsourcing due to time restrictions. Assessment-wise an additional element added is confidence level

AD tooling options

  • do it yourself (Word, wiki, etc.)
  • emerging guidance and decision model tools

Lessons learned and summary:

  • architectural decisions: fun to investigate, less fun to document
  • Many decisions recur.
  • Tools are emerging.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s