2. Safe Harbor Statement
Forward-Looking Statements
This presentation contains forward-looking statements including, among other things,
statements regarding the development and functionality of VMware products and services and
the timing of their availability. These forward-looking statements are subject to the safe harbor
provisions created by the Private Securities Litigation Reform Act of 1995. Actual results could
differ materially from those projected in the forward-looking statements as a result of certain risk
factors, including but not limited to: (i) adverse changes in general economic or market
conditions; (ii) delays or reductions in information technology spending; (iii) competitive factors,
including but not limited to pricing pressures, industry consolidation, entry of new competitors
into the virtualization market, and new product and marketing initiatives by our competitors; (iv)
our customers’ ability to develop, and to transition to, new products and computing strategies
such as cloud computing; (v) the uncertainty of customer acceptance of emerging technology;
(vi) rapid technological and market changes in virtualization software and platforms for cloud
and desktop computing; (vii) changes to product development timelines; (viii) our ability to
protect our proprietary technology; (ix) our ability to attract and retain highly qualified
employees; and (x) the successful integration of acquired companies and assets into VMware.
These forward looking statements are based on current expectations and are subject to
uncertainties and changes in condition, significance, value and effect as well as other risks
detailed in documents filed with the Securities and Exchange Commission, including our most
recent reports on Form 10-K and Form 10-Q and current reports on Form 8-K that we may file
from time to time, which could cause actual results to vary from expectations. VMware assumes
no obligation to, and does not currently intend to, update any such forward-looking statements
after the date of this release.
Friday, November 12, 2010
3. What is the OpenPaas?
Friday, November 12, 2010
4. What is the OpenPaas?
• Application Platform as a Service
• Application delivery platform
• Favor choice and openness
• A what?
Friday, November 12, 2010
5. What is the OpenPaas?
• Application is the unit of currency
• That is what you care about
• Everything else is decided for you
• And you shouldn’t care
Friday, November 12, 2010
10. But I want control!!
• I want access to the web server!
• I need access to my app server!
• I need to control all configurations..
• I want my app placed here, not there!
Friday, November 12, 2010
11. Relax!
"They got rid of the horizontal
and the vertical settings years
ago."
Friday, November 12, 2010
12. But Seriously....
• We understand, we get it..
• You’ll have utilityVMs
• Layer 4 IP Connectivity
• Apps will bind to them
• They will bind to provisioned services
• More to come..
Friday, November 12, 2010
14. Why do we care?
• Cloud is about opex, not capex
• PaaS reduces opex
• Major portion of $$ spent is on application
deployment and management
• Simplify and save $$
• Storage & Compute are trending -> $0
Friday, November 12, 2010
15. Why do we care?
• Speed
• Agility
• How long do you wait to deploy your app?
• What if that was seconds? For any app?
• What if the cloud really was your “other”
computer?
Friday, November 12, 2010
20. Lightbulb!
• Opex vs Capex
• Incandescent vs CFL..
• Framework X vs FrameworkY
Friday, November 12, 2010
21. Lightbulb!
• What if you could light your room for half
the cost?
• How much does that app cost me to run in
the cloud again?
• What choices do I have to cut costs?
Friday, November 12, 2010
23. What isVMforce?
• VMware + SalesForce.com
• OpenPaaS instantiation at SalesForce.com
• Spring and Roo Frameworks
• SalesForce.com’s Data and Services
• Hosted in SalesForce.com datacenters
Friday, November 12, 2010
24. How does one build
one of these things??
Friday, November 12, 2010
25. • Inner and Outer shells on top of IaaS
• Outer shell is creation, orchestration, and
management of the infrastructure.
• StemcellVMs, raw resources, and change
management.
• Inner shell runs the core system components
• Routers, CloudControllers, ExecutionAgents,
HealthManager and Services.
How does one build
one of these things??
Friday, November 12, 2010
27. Basic Premises
• Should be self healing
• Should be horizontally scalable at all levels
• Should utilize distributed state
• NO single point of failure!
• Above all, should be simple and dumb
• Dumber as you get closer to the core
Friday, November 12, 2010
28. Basic Premises
• Messaging as a foundation
• Addressing
• Component discovery
• Command and Control
• JSON
• HTTP or file systems for data transport
• File system is an optimization
Friday, November 12, 2010
30. App Basics
• Execution is start and stop, that’s it!
• Be cloud-ready!
• Shared state, depend on nothing local
• No assumptions about resources
• X File.read(‘/home/derek/stuff’)
• X EM.start_server(‘localhost’, 80, h)
Friday, November 12, 2010
31. App Basics
• Send us everything.. I mean everything
• Can’t create “start” button until you do!
• Bundler is good.. so to speak
• ‘bundle package’ is better!
• How does that not suck though?
• Other frameworks? node.js/npm??
Friday, November 12, 2010
35. Wait, Ruby?? Really?
• Ruby is a great language, well designed..
• Distributed systems architecture has little
to do with language choice..
• If someone says so, walk the other way!
• Of course we all want faster Ruby!
• 1.9.2, RBX, JRuby, MagLev
Friday, November 12, 2010
39. Components
• Dynamically discoverable
• subscribe(‘you there?’)
• Launch in any order
• publish(‘hello!’)
• Never store central state
• Health status and state available via HTTP
Friday, November 12, 2010