When do people think about this:
When they first buy hardware
When equipment is replaced
This is NOT a discussion about elastic compute services specifically and not about hybrid cloud solutions.
Will Law, timekeeper, Hans Jacobsen, scribe
Bruce works with GSB, ITS CRC distributed support.
Let's talk about work on infrastructure as a service - for example CORN, the campus service (or YEN for GSB) - we CAN move them off campus
Administrative plumbing - one contract for the institution with Amazon, but with charges for individual Stanford users
We are using other "cloud services" as a campus - Box, Google docs
What is "cloud" to you?
Is "Web" and/or client/service stuff?
An at-will computing or storage resource
It might allow/enable having a global presence or local (US) presence only, load balancing including CDN (content delivery to the edge)
Programatic control of dynamic instances
It might mean more - platform as a service (PaaS) -- force.com, google app engine, Roroku, Aquia, Matlab can be
Infrastructure as a service (IaaS) some vmware offerings, MS Azure, Amazon EC2
Software as a service (SaaS) - gmail
Storage as a service (also called SaaS) - Amazon, glacier
Dark lining of the cloud: (hurdles)
What really happens to your data? Can you really trust availability, integrity?
What security certifications does your provider have? Even if you have what you need from the company, is your application more exposed in that cloud context?
Do you have needed airgaps for audit-worthyness?
Can multi-tenancy work securely enough for our business needs?
Wiil the provider sign a BAA?
Can you make your licensing work?
There are a lot of new players/service providers - which should we even use?
It generally adds complexity
It costs more people resources than expected to try to do things. It is easy to make assumptions that are wrong.
It can be more expensive (2-3x) than running locally for steady-state stuff - but opex vs capex
There can sometimes be runaway cost when you thought you set things up on a limited basis but did not do so successfully.
It is hard to accurately forecast cost for your use case even with decent modeling.
This can be helpful or a problem for grants and granting agencies - use could be disallowed by a grant.
It can be harder to manage and control performance if there are issues. Stanford is small to the likes of Amazon.
The devil is in the details.
Benefits:
If you want to spend Capex instead of Opex - it might be for you
You can extend capability in a way - if you want to scale and scale quickly, the cloud can absolutely help you do that.
Could help for business continuity as a second/alternate site more cheaply than having a fully provisioned DR site, maybe.
Using extended services (like
Very good for temporary things
Transient peak load, for huge temporary load, even if daily for a "short time"
load testing
trying out new things (once you set up your ability to to use it at all and paid that contractual and complexity/personnel cost)
some research (with systems that can be shut off much of the time and are not running 24x7)
Who is doing cloud stuff:
http://class.stanford.edu/ - class to go (it is a subdomain at Amazon EC2)
GSB:
faculty can quickly spin up clusters - up to 64 members - as needed - paid for from a central fund
Other comments/notes:
We may need a central director or higher position to handle online/cloud resources. This was recommended. It was also joked about as Stuff as a Service, director of Cloud Strategy.
What are the problems to tackle? Which affect the entire university, or large swaths?
It can be hard to make change happen due to inertia.
The government has a cloud-first strategy - orgs must justify NOT doing something in the cloud.
There has been no re-org'ing related to our cloud efforts.
For example, if ITS was to use or look at using Amazon ELB (elastic load balancing), current ITS load balancing experts have domain knowledge and would be naturally called on to help.
Doing things to make practices of making things more public, have open/public APIs for data is a challenge.
Keep your eyes open to bringing operational people in for on-the-job training in "cloud" areas.
