Professional Documents
Culture Documents
10
Thursday, January 21, 2010
what is cloud computing? IT initiatives in this space a few non-IT initiatives general approach of the IT Division
useful denition from Urs Hoelzle (SVP @ Google) cloud implies two kinds of computing systems
tiny: smart phones, net/notebooks, thin clients, tablets
at either scale, systems are optimized for efciency - battery constraints - operating expenses @ 50MW BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
privacy concerns security breaches data and service lock-in complete dependence on the network lower quality of service (stubborn c) lay-offs corporate turmoil higher prices, eventually
BERKELEY LAB
Thursday, January 21, 2010
much better IT services much faster innovation greater resiliency renewed focus on important problems more productive collaboration reduced travel end to burden of self-managed PC lower prices over time profound but appropriate disruption
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Infrastructure as a Service [IaaS] customer rents low-level resources (cycles, storage) sysadmin, integration, scaling tasks remain the most exible but labor-intensive option quick demo (nagios on EC2) Platform as a Service [PaaS] customer rents an application platform customer provides code no sysadmin tasks Software as a Service [SaaS] customer rents an app customer provides conguration + data
Thursday, January 21, 2010
BERKELEY LAB
strong support from the Feds: - Federal CIO Vivek Kundra promoting cloud very aggressively - take a look at the non-cartoon portion of http://apps.gov - vendors rening services to entice .gov customers - Google federal cloud + FISMA compliance in 2010 - another vendor offering separate .gov hosting facility (cloudish)
Thursday, January 21, 2010
BERKELEY LAB
There is obvious FUD around clouds on both sides. Both sides have economic interests.
BERKELEY LAB
Thursday, January 21, 2010
dont do sensitive work are good with computers (earnest early adopters) use a lot of diverse IT not already in bed with MS are multi-platform by nature tend not to just do what vendors and consultants
tell us to without thinking it through BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Home Energy Saver empowers home owners to reduce their energy use customer-facing app plus licensed web service hardware currently in Bldg 50A EETD now migrating to Amazon Web Services (EC2 / S3)
LEEP HES for wet labs implemented at nearly the same time on Google AppEngine, Appshosting, and conventionally (terrestrially) in J2EE
BERKELEY LAB
Thursday, January 21, 2010
To Summarize
Beware of generalizations about cloud computing! (the business models and services differ widely) having said that... its likely that many IT functions now performed locally will be cloud-sourced in 3-5 years
this is good for science & good for the planet, but there will be trade-offs general posture of IT Division proceed optimistically but pragmatically, seeking data understand range of services, policy issues gain competence in cloud-sourcing, conduct pilots use cloud services where appropriate
BERKELEY LAB
Thursday, January 21, 2010
If you believe slides 1-20, then... We need to get good at managing privacy and security in the cloud. We need to move judiciously, but quickly to exploit economic/strategic advantage for LBL and DOE.
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
1. Powerful collaboration suite 2. Gain advantages of Google scale and development lifecycle (new features every week) 3. Refocus our resources and people on sciencedriven projects, not commodity apps (specialize where we are trumped by scale).
BERKELEY LAB
Thursday, January 21, 2010
For the purposes of this talk, we will focus mostly on Mail, with occasional forays into other apps.
BERKELEY LAB
Thursday, January 21, 2010
Mail: Architecture
Scope: No change to mail handling architecture at this time. Further study required. berkeley -> lbl -> google -> lbl -> berkeley
A/V A/S Policy and other A/V A/S Policy
Security
The status quo (our approach): We permit LBL users to forward their email anywhere (this is a reection of our risk-tolerance). We prohibit sensitive data and many kinds of elevated sensitivity research. We manage email risks mostly through ltering. BERKELEY LAB
Thursday, January 21, 2010
Contract
The contract b/w the University and Google, as well as the TOS sets the boundaries of the relationship. To some extent, we are required to trust that Google is living up to its end of its commitments. Trust is fed by audits, reviews, and liability. The current UC-contract is being renegotiated to incorporate additional terms. BERKELEY LAB
Thursday, January 21, 2010
Easy Things
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Wont google own us? Complex question, detailed weighing required. Contractually, they must provide us with ways to migrate out and they have. We believe cost to migrate out to be similar to cost to migrate out of other systems (though there would be losses of integration, etc). Those costs are serious. (the complex equation: are Googles costs fundamentally lower? will goog raise the prices to within $1 of our decision-curve every year (like MS or Oracle?) BERKELEY LAB
Understand the envelope. Understand the tradeoffs. Is Google Secure? (this question makes no sense in a vacuum).
BERKELEY LAB
Thursday, January 21, 2010
Security
Status Quo: Risks Two kinds: to user email & to the system User: User accounts use reusable credentials and their pattern of use leads to relatively high likelihood of compromise. Local storage of email = high risk of mass loss of individual users email. This is acceptable in our current risk environment. System: LBL systems are well protected, enforce least functionality and separation, non-reusable auth, and extensive logging. No history of compromise (but were only talking about central systems). BERKELEY LAB
Lack of logging / Lack of our experience with it. -Requirement of cooperation for forensics. Google = large target New features may be poorly understood (ofine, delegation, etc).
BERKELEY LAB
Thursday, January 21, 2010
At the high level: Google & LBL share something in common: no trust of endpoints. Googles track-records is very good (compare to Adobe/MS) There is limited patch delay from release. Enormous team of security people. Well regarded lifecycle integration of security (an engineering approach to security). BERKELEY LAB
Thursday, January 21, 2010
Information Storage: Multi-tenant distributed on GFS. Data is chunked, difcult to piece together. Certicates for access, detailed Separation of Roles across apps, privacy protections built in.
BERKELEY LAB
Thursday, January 21, 2010
At the application layer: High visibility into normal performance of applications. Monitoring and Boundary Protection Instant response is possible (though not assured).
BERKELEY LAB
Thursday, January 21, 2010
BERKELEY LAB
Thursday, January 21, 2010
Security Documents address: Access Control Physical Control Logical Security Boundary Defense, etc...
BERKELEY LAB
Thursday, January 21, 2010
Privacy
Google reads your email (their computers do actually, which really is different) ... but not the same way they do when you are a gmail customer. Google employees dont read your email (by law, by contract, audited), except under dened situations.
BERKELEY LAB
Thursday, January 21, 2010
Google stores redundant copies of data in geographically disperse regions. Google does not make claims about where (though not China). There are novel aspects of this relationship, but the impacts seem modest. Scenario 1, physical access Scenario 2, logical access BERKELEY LAB
Thursday, January 21, 2010
Other risks?
Emergent properties of whole systems. What if Google becomes MS circa 2004? Does Google become Toyota or Oracle? What happens if there is a .gov incident? What about the Labs/Facilities that are much more strict? BERKELEY LAB
Thursday, January 21, 2010
What does climategate mean to us? What does Chinagate mean to us?
BERKELEY LAB
Thursday, January 21, 2010
1. Google owns your data. 2. Google never deletes anything. 3. Google mines your email to serve you ads. 4. Googles international presence means your data is being used by the elbonians. 5. Not being able to touch your data means its at more risk. BERKELEY LAB
Thursday, January 21, 2010
Its not that Google is no risk, its that its within our acceptable risk envelope. Its probably a wash (from what we see now)* * Security should be based on what we see now LBL has had much success with this model. This isnt a decision for now and forever.
BERKELEY LAB
Thursday, January 21, 2010