Notes by Peter Foldes
Architectural Implications of Cloud Computing
Grace Lewis, SEI
- Cloud computing concepts
- Architectural implications of cloud computing
- Final thoughts
What is cloud computing by Ian Foster: Large scale; distributed
Cloud computing types:
by who can access it
- Amazon EC2
- IBM Computing on Demand
Application deployment platform, create and host applications
- Akamai EdgePlatform
- Google App engine
- Microsoft Azure
- Yahoo! Open Strategy; social focus
License application to customers for use as a service
- Google Docs
- 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
- deployed inside the firewall and managed by user organization
- user organization owns and manages it
- 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
- risk reduction
- reliability: cloud providers have reliability mechanism
- security: no control over data storage
- interoperability: No universal standards and/or interfaces
- resource control
- platform or language constraints
- regulation: data protection, fair information practices, etc.
Architectural implications of cloud computing
- 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?
- 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?
- 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
- 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
- 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:
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
- IaaS: provisions, configuration, management. For example, create image
- PaaS: for example, send email, upload app code
- SaaS: very specific access
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
- 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)
- 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.
- 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.