PaaS on OpenStack

Flag as Inappropriate

Please select the category that most closely reflects your concern about the presentation, so that we can review it and determine whether it violates our
Terms of Use or isn't appropriate for all viewers.

Submit

Like this presentation?

Embed this comment into your blog:

Comment URL:

No comments posted yet

Comments

1-10 of 34

Post a comment

How to measure productivity
A generally accepted working definition of programmer productivity needs to be established and agreed upon. Appropriate metrics need to established. Productivity needs to be viewed over the lifetime of code. Example: Programmer A writes code in a shorter interval than programmer B but programmer A's code is of lower quality and months later requires additional effort to match the quality of programmer B's code; in such a case, it is fair to claim that programmer B was actually more productive.
You have to give up control for better simplicity
True in some cases – but there are many cases were better control gets you more productivity for example – choosing your own OS can get you better performance, save bugs through patches that was already addressed etc , choosing your own selection of middleware packages can save the need to develop things that was already addressed through the ecosystem,..
Productivity is measured by the number of lines of code
Productivity is measured by units of features being delivered (not lines of code)
Development languages is only a small measure – take scala or earlnag for example. You can code the same thing that you would do in Java in few lines of code but it doesn’t come with strong development tools support, adminstration tools, and its hard to find skilled programmer in Scala – so even in the case that you could write less code for the same feature it doesn’t means that you would be able to deliver more features faster.
Opinionated architecture (Rails/Grails) gets your more productivity
True only if you stick to the exact design concept – but in reality architecture change and doesn’t always fits to all cases – in those cases designing to an opinionated approach can be significantly more complex.. (See the Twitter example, they started with Rails and over time found out that they needed something different – at the time Rails became extremely un productive to address their new needs and coding around it was extremely difficult that twitter decided to move away from it to Java/Scala…)

Slide 25

Continues -> Continuous

Sign In

Defining the PaaS
There is a difference between knowing the PaaS (path), and walking the PaaS (path).
Morpheus in “The Matrix”
Quiz: What do you
expect from a PaaS?
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
3

Productivity Myths
You have to give up control for more simplicity
Not always…
Less code = more productivity
Productivity is measured by units of features being delivered (not lines of code)
Opinionated architecture (Rails/Grails) is extremely productive
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
12

Slide 13

So Who’s Better?
Google/Heroku
Top-down sandbox approach
Highly opinionated
Designed for extreme simplicity at expense of user control
Amazon
Bottom-up approach
Designed for extreme simplicity with a significantly higher degree of control
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
13

Slide 14

Agenda
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
14

Slide 15

PaaS on OpenStack – Aim Higher
Anyone should be able to:
Build their own PaaS in a snap
Run on any cloud (public/private)
Gain multi-tenancy, elasticity… Without code changes.
Provide a significantly higher degree of control without substantial complexity
Language choice
OS
Middleware stack
Should come pre-integrated with popular stack
Spring,Tomcat, DevOps, NoSQL, Hadoop…
Designed to run the most demanding mission-critical apps
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
15

Join the Effort
Call for action
Try out the provider jclouds
Establish a PaaS working group to drive PaaS within OpenStack community
Register now for the beta program
www.gigaspaces.com
Learn more..
natishalom.typepad.com
blog.gigaspaces.com
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
31

Slide 32

Summary
Curving out complexity, opinionated architecture, relying on someone else’s stack is only one way to achieve productivity at the expense of control
With OpenStack we can aim higher and make the application infrastructure simpler and better suited for the cloud in the first place
® Copyright 2011 Gigaspaces Ltd. All Rights Reserved
32

Summary: The presentation provides an overview of the different PaaS platforms - specifically Google, Heroku, Amazon and suggest a better model for developing PaaS on top of OpenStack which will provide better degree of tradeoffs between control and simplicity