1. Selec%ng
a
DevOps/PaaS
Pla1orm
John
Mathon
VP,
Enterprise
Evangelism
Blog:
Johnmathon.wordpress.com
TwiCer:
@john_mathon
Mail:
john@wso2.com
(C)
WSO2
2014

2. ©
WSO2
2014
WSO2 Selected Customers (8 years, 200+)

3. ©
WSO2
2014
The
Broadest
Product
Set
for
the
Connected
Business
Stratos PaaS Foundation App Factory
Carbon Middleware Platform Developer
Studio
Stratos'Controller'
'
'
'
Stratos'Controller'
'
'
'
Iden.ty'
Mgmt''
Service'
Logging'
Service'
Security'
Service'
Registry'
Service'
Data'
Service'
Elas.c''
Load'
Balancer'
Cloud'
Controller/'
Autoscaler'
Artefact''
Distribu.on'
Service'
Deployment'
Synchroniser'
Management'
Console'
File'
Storage'
Service'
Task''
Mgmt'
Service'
Meter'
and'
Billing'
Service'
Load''
Monitor'
PaaS!
Foundation!
14/11/2012& 29&
Project&and&
Team&&
Management& So7ware&
development&
workflow&
Governance&
and&
Compliance&
Development&
Dashboards&
Develop&
Code&
Issue&
Tracking&
Source&
Control&
ConGnuous&
Build&
ConGnuous&
IntegraGon&
Test&
AutomaGon&
ConGnuous&
Deployment& App Factory!
App Factory!
App Factory!App Factory!

4. ©
WSO2
2014
What
is
a
PaaS?
• PaaS
automates
the
development
and
opera%ons
of
Applica%on(s)
in
a
self-­‐service
way
• Provides
incremental
costs
as
you
grow
the
applica%on(s)
and
tenants
it
runs
• Best
Prac%ces
baked
in
• Provides
resource
sharing
to
reduce
costs
• Generally
runs
on
top
of
an
IaaS
infrastructure
either
Private
or
public

5. ©
WSO2
2014

6. ©
WSO2
2014
The
process
simplified
w
DevOps:
Before
-­‐
so)ware
development
is
costly
and
risky
as
well
as
a
slow
process
30-­‐50%
of
project
cost
and
<me
in
dev
Large
hardware
commitment
up
front
Opera<ons
personnel
a
big
cost
• Do
tests
on
early
versions
of
so[ware
to
determine
loads
from
customers
• Plan
demand
expecta%on
and
hardware
required
• Acquire
hardware
and
networking
equipment
for
a
%me
period
including
addi%onal
hardware
for
failures
and
expected
peak
periods
• Find
space
for
hardware,
plan
network
integra%on
plan,
rule
changes
in
switches,
routers,
update
configura%on
management,
outages
for
upgrades
and
changes
• Test
hardware
and
network
with
so[ware
to
insure
it
works
• Understand
failure
modes,
when
to
scale,
runbooks
for
different
scenarios,
train
people
in
opera%on
and
what
to
do
in
different
scenarios.
Write
scripts
to
detect
scenarios
and
provide
needed
informa%on
in
failures.
• Write
or
acquire
management
tools,
put
in
instrumenta%on
in
hardware.
• Plan
for
upgrade
strategies,
outages
and
SLA
measurements,
backup
policies.
• Beta
customers
• Go
Live
Now
(cost
and
<me
nearly
disappears,
zero
upfront,
lower
risk)
• Choose
IaaS
vendor
• Choose
PaaS
pla1orm
• Write
some
runbooks
for
different
scenarios,
train
people
in
PaaS
opera%on
• Deploy
so[ware
• Beta
customers
• Go
live
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Time
Cost
Time
Cost
Development
Test/Deployment
Opera%ons
$$$$$$$$$$$$$$$$$$$$$$$
SAVED!
SAVED!

7. Lower
Costs,
Faster
Time
to
Market
In
today’s
world
this
is
not
op%onal
for
many
companies
(C)
WSO2
2014

8. ©
WSO2
2014
PaaS/DevOps
Ini%al
Costs
Vendor
Selec<on,
Tools
• Select
PaaS
pla1orm
• Choose
one
or
more
IaaS
– Public
IaaS
• Select
Vendors
• Security
research
• Value
Added
Services
• Compliance
issues
– Private
IaaS
• OpenStack
vs
VMWare
vs
Eucalyptus
vs
…
• Select
hardware
• Network
management,
security
Skill
Development,
Integra<on
• Hire/train
competency
in
DevOps
• Developers
training
• DevOps
administra%on
• Design
and
Test
ALM

9. ©
WSO2
2014
What’s
the
difference
DevOps/PaaS?
Basic
DevOps
–
you
write
the
automa<on
• Chef,
Puppet
• You
write
the
rules
• You
figure
out
how
to
deploy
on
IaaS
infrastructure(s)
or
on-­‐
premise
• You
figure
out
and
implement
how
to
scale
usually
implemented
manually
• You
figure
out
and
deploy
FT/HA
strategy
• Tenant
management
and
other
tasks
like
security
may
be
very
manual
s%ll
PaaS
–
its
built
in
• PaaS
automa%cally
builds
deployment
architecture
• PaaS
can
deploy
on
hybrid
infrastructure
• PaaS
can
scale
automa%cally
• PaaS
configures
clusters
automa%cally
• PaaS
load
balances,
assigns
tenants
and
fires
up
new
instances
as
needed
and
resources
needed
for
those
instances

10. ©
WSO2
2014
Different
Types
of
PaaS
• Applica%on
PaaS
– Language
/
IaaS
/
Applica%on
specific
PaaS
–
some
good
for
Java
or
Ruby
or
PHP
or
only
work
on
AWS
or
Azure
or
OpenStack
or
with
Salesforce
or
their
Applica%on
• Toy
PaaS
– Not
designed
for
“enterprise”
with
mul%ple
tenant
teams,
mul%ple
dev
environments,
more
rule
oriented,
don’t
isolate
test
from
produc%on,
not
designed
for
large
scale
produc%on,
limited
integra%on
capabili%es
• Generic
PaaS
– Support
DevOps
type
func%ons
generically
but
not
lifecycle
support
• Ecosystem
PaaS
– Support
for
many
isolated
tenants
for
applica%on
building,
a
store
for
sharing
assets
between
tenants,
a
powerful
mul%-­‐tenant
resource
sharing
deployment
model,
governed
rules
for
lifecycle
opera%ons,
built-­‐in
support
for
source
code,
issue
tracking,
con%nuous
integra%on
tools

11. ©
WSO2
2014
Applicability
of
Types
of
PaaS
• Applica%on
PaaS
– if
you
don’t
need
flexibility
• Toy
PaaS
–
avoid
• Generic
PaaS
– Good
if
you
are
going
to
do
one
app
or
just
a
few
apps
• Ecosystem
PaaS
– Good
for
you
to
use
yourself
if
you
want
more
automa%on,
governance
and
more
enterprise
features
for
many
apps
– Good
for
your
Ecosystem
to
enable
partners
and
customers
(Create
your
own
aPaaS)

12. ©
WSO2
2014
How
do
you
pick
a
PaaS?
• Features?
• Type?
• Performance?
• Ease
of
use
for
dev,
opera%ons?
• Flexibility?
• Open
Source?
• Opera%ng
Experience?
• Compatability
with
exis%ng
enterprise
devops?
• Compatablity
with
IaaS
choice?

13. ©
WSO2
2014
Covered
here
YES
• Generic
Private
PaaS
• Ecosystem
PaaS
NO
• Compe%%ve
landscape
• Toy
PaaS’s
• Applica%on
PaaS’s

14. ©
WSO2
2014
Generic
and
Ecosystem
PaaS’s
Requirements
Generic
• Private
or
Public
• IaaS
independence
• Hybrid
Cloud
Capability
• Resource
Sharing
differences
• Security
Concerns
• High
Availability
• Polyglot
• Management
and
Performance
Monitoring
• Automated
Resource
Alloca%on
• Scaling
Automa%cally
• Opera%ons
Support
• Pluggability
• Mul%-­‐tenancy
Ecosystem
• Ecosystem
support
• Environment
support
• Business
Process
Automa%on
• Lifecycle
support
• Social
Capabili%es
• Store
• Reuse

15. ©
WSO2
2014
Run
yourself
or
Public
Private
/
Run
yourself
• Gain
Experience
yourself
before
launching
into
public
sphere
• you
can
deploy
anywhere
and
grow
based
on
benefits
and
even
burst
into
public
on
demand
Public
• Start
cheap
• Start
small
• Build
from
there
and
gain
on
the
job
training
• Possibly
locked
in
to
a
vendor
and
its
problems
and
limita%ons
on
performance
and
scale,
compliance,
security
…

16. ©
WSO2
2014
Public
IaaS
Vendors
–
large
variability
High
Risk
–
not
all
PaaS’s
run
on
all
IaaS
Dell*,
Azure**
• Microso[
(Free)
• Dell
-­‐
On-­‐premise
like
Joyent**,
So)Layer*
• High
Performance
– Joyent
special
virtualiza%on,
SmartOS
– So[layer
–
bare
metal
• MongoDB,
Hadoop
Rackspace*,
HP*
• MySQL
• OpenStack
Pioneer
Google**
• Google
Compute
Cloud
• Google
App
Cloud
Amazon
AWS**
• Wide
variety
of
choices
• Lots
of
extra
value
services
• Poorest
performance
• Highest
cost
*OpenStack
**
Proprietary

17. ©
WSO2
2014
Do
you
need
IaaS
independence?
Lock
into
a
cloud
vendor
• Become
dependent
on
a
cloud
vendor
size
limita%ons,
growth
and
viability,
security
policies,
pricing.
If
any
fail
to
meet
future
needs
be
prepared
for
major
cost
and
difficulty
moving
Hybrid
• Change
cloud
vendors
based
on
experience
and
cost
changes
as
needed
• May
not
be
able
to
use
IaaS
vendor
specific
features
• Flexibility
-­‐
Have
some
on-­‐premise
hardware
as
well
as
public
cloud
for
beCer
cost
mixing

18. ©
WSO2
2014
Private
IaaS
Choices
VMWare
–
expensive
Eucalyptus(AWS)
–
%es
you
to
Amazon
OpenStack
– Many
supporters
Cloudstack
OpenNebula

19. ©
WSO2
2014
Hybrid
Capability
Important
• Change
cloud
vendors
based
on
experience
and
cost
changes
as
needed
• Run
different
tenants,
environments
or
even
different
components
in
different
clouds
for
reasons
of
performance,
compliance,
cost
or
any
reason
• Burst
on
demand
• Have
on-­‐premise
hardware
as
well
as
public
for
beCer
cost
mixing

20. ©
WSO2
2014
Polyglot
PaaS
Important
Polyglot
Development
Support
for
different
development
technologies
like
Java,
PHP,
JAX-­‐RS,
JAX-­‐WS,
…
Polyglot
Run<me
(Cartridges)
Can
the
framework
support
different
run%mes
and
cartridges?
Mul%-­‐tenant
and
non-­‐mul%-­‐
tenant
cartridges?
Can
the
system
generate
cloud
ar%facts
from
cartridge
defini%on
automa%cally
Can
the
system
automa%cally
allocate
resources
for
cartridge
and
tenants
Can
the
system
do
resource
sharing
for
mul%ple
cartridges
in
one
applica%on?

21. ©
WSO2
2014
One
PaaS
or
Mul%ple
Separate
PaaS’s
for
each
environment
or
Applica<on
• May
be
easier
to
stand
up
ini%ally
• More
flexibility
to
configure
each
environment
as
needed
• Harder
to
move
things
from
one
environment
to
another
• May
be
scenarios
that
weren’t
seen
in
one
applica%on
or
environment
that
pop
up
in
another
One
PaaS
to
support
all
• May
not
support
isolated
clouds
or
mul%ple
environments
• May
not
support
your
processes
for
promo%on
• May
not
support
tools
you
need
in
each
environment
such
as
test
tools,
special
hardware
or
network
configura%ons
needed

22. Component
Resource
Sharing
is
beCer
Great
Performance
Dedicated
Resources
but
expensive!
Mul%-­‐tenancy
Allows
each
instance
To
be
shared
–
beCer
u%liza%on
J
Break
into
components
Allows
each
piece
to
be
u%lized
And
split
to
different
servers
Giving
higher
performance
Mul%ple
copies
of
Each
component
Allows
unlimited
scale
Individual
components
can
be
scaled
independently
Giving
maximum
u%liza%on
and
scalability
as
well
as
Fastest
response
to
load
changes
Tear
down
Instances
faster
And
easier
too
Dedicated
instances
expensive
But
scales
(C)
WSO2
2014

23. ©
WSO2
2014
High
Availability
/
Disaster
Recovery
HA
• Is
the
PaaS
itself
fault
tolerant?
• Fault
tolerant
technologies
for
all
supplied
cartridges?
• Ac%ve/Passive
and
Ac%ve/Ac%ve
deployments
supported?
• Load
Balancing
between
fault
tolerant
components?
• Single
points
of
failure
anywhere
in
the
system?
DR
• Does
the
PaaS
include
a
gReg
to
replicate
governance
data
between
regions?
• Does
the
PaaS
support
ar%fact
distribu%on
automa%cally
to
all
regions?
• Does
the
PaaS
support
resource
backup?

24. ©
WSO2
2014
Security
built-­‐in?
Authen<ca<on
• Federated
Iden%ty
support
including
OPENID,
SAML
and
dual
factors?
• Support
for
mul%ple
LDAPs
or
at
least
one
LDAP
per
tenant?
• Is
the
IM
scalable
to
support
your
needs?
Authoriza<on,
Audit
• Does
the
PaaS
support
OAUTH2,
XACML
and
other
authen%ca%on
standards?
• Does
it
scale
to
your
needs?
• Can
you
audit
the
logs
or
easily
build
alerts
to
detect
poten%al
breakins
or
fraud?

25. ©
WSO2
2014
Auto
Scaling?
Detec<on
of
Change
• What
KPI’s
can
the
system
use
to
decide
if
something
is
overloaded
or
going
to
be
overloaded
or
is
underu%lized?
– Fixed?
• May
work
in
some
instances
but
will
probably
lead
to
bad
results
in
many
cases
– Real-­‐%me
informa%on
– Or
historical
based
– Complex
Event
detec%on?
– SLA
based?
What
is
auto
vs
manual?
• Is
the
scaling
manually
ini%ated?
Does
it
do
automa%c
up
and
down
scaling?
• Can
you
set
rules
or
business
process
to
scale
up
or
down
• Can
you
scale
by
tenant
• Can
you
scale
in
different
clouds?
• Can
you
scale
by
%me
of
day
or
by
region
depending
on
the
load
in
that
region?
• Can
you
scale
individual
cartridges
or
whole
applica%ons?
• Can
you
scale
resources
as
well
as
CPU?

26. ©
WSO2
2014
Open
Source
or
Proprietary?
Support
• Does
it
have
support
for
standards?
• Do
3rd
par%es
support
it?
• Is
it
available
as
private
or
hosted
version?
• Are
plug
points
well
defined?
Cost
• Is
there
a
license
fee
for
enterprise
version?
• Is
the
product
open
source?
Apache
Licensed?

27. ©
WSO2
2014
Performance
Management?
Management
Capabili<es
• Does
the
system
come
with
monitors,
agents
and
built-­‐in
monitoring
for
applica%ons?
• Does
it
allow
3rd
party
monitoring
to
be
added?
• Can
you
do
APM
to
detect
what
inside
an
applica%on
might
be
an
issue?
• Does
the
system
check
internal
and
external
performance?
Visualiza<on
and
Escala<ons
• Do
you
have
good
visualiza%on
tools
of
the
status
with
KPIs
on
historical
as
well
as
real
%me
performance?
• Is
the
monitoring
flexible
and
designed
to
make
seeing
overall
system
performance
easy
to
see
as
well
as
individual
instance
performance
• Can
the
system
detect
anomalous
situa%ons
and
instan%ate
a
workflow
or
escala%on
no%fica%on
to
the
right
people?
• Can
the
system
perform
automa%c
workarounds
to
known
events
or
scenarios?
• Can
you
plug
in
3rd
party
tools?

28. ©
WSO2
2014
PaaS
Management
• Do
all
parts
of
the
PaaS
have
APIs
to
manage
the
PaaS
so
you
can
build
your
own
interfaces
and
inquire
on
status?
• Do
all
parts
have
CLI
interfaces?
• Does
the
PaaS
have
consistent
opera%on
for
all
parts?
• Is
there
a
flexible
enough
billing
and
accoun%ng
component?

29. ©
WSO2
2014
Upgrades?
Down
Times
• What
are
the
components
to
be
upgraded
and
can
they
all
be
upgraded
without
any
or
very
liCle
interrup%on?
• What
modules
will
require
down
%me
or
maintenance?
• Are
down%mes
required
for
data
backup
or
other
maintenance?

30. ©
WSO2
2014
Management
Data
/
BigData
Integrated
• Is
bigdata
integrated
with
the
system
so
scaling,
management,
load
balancing,
SLA
monitoring
etc
are
all
facilitated
out
of
the
box?
• Can
you
gather
KPIs
on
usage
both
real
%me
and
over
%me
intervals?
Ready
• Are
the
feeds
for
performance,
logs,
gateways,
load
balancers,
and
all
the
components
instrumented
to
provide
big
data
informa%on
easily
to
the
bigdata
pla1orm?
• Can
the
system
log
data
from
applica%ons
as
well
as
the
PaaS
to
be
used
for
analyzing
tenant
usage

31. ©
WSO2
2014
Ecosystem
PaaS
• Full
Lifecycle
support
– including
source
code
repository,
agile
project
management,
automated
build,
con%nuous
integra%on,
con%nuous
deployment
for
each
tenant
and
tenant
applica%on
• At
least
one
Administra%ve
Tenant
– who
can
establish
Governance
of
Tenants
roles
and
ability
to
control
the
promo%on
and
demo%on
business
process
for
users
and
tenants
of
ar%facts
• Business
process
defini%on
– for
promo%on/demo%on
include
automated
steps
as
well
as
human
involvement
• A
social
Store
to
share
en%%es
– APIs
and
work
products
between
tenants
that
is
role
and
tenant
aware

32. ©
WSO2
2014
WSO2
App
Factory
:
Enterprise
DevOps

33. ©
WSO2
2014
What
are
use
cases
for
Ecosystem
PaaS?
1. You
want
to
establish
leadership
in
your
ecosystem
and
disrupt
your
compe%%on
2. PaaS
add-­‐on
for
your
APIs
or
SaaS
applica%on
I.e.
Salesforce
3. Regulatory
mandates
or
security
requirements
I.e.
Health,
finance,
government,
security
4. You
want
a
collabora%ve
development
environment
with
reuse
and
common
development
methodologies
5. You
build
lots
of
applica%ons
and
need
a
beCer
way
to
automate
the
development
and
management

34. ©
WSO2
2014
Managing
Environments
• Dev
• Test
• Produc%on
• Staging?
• Demo?
• Training?
• UAT?
• LastGood?
• Partner?
• …
• Do
you
need
flexible
gReg
support
for
all
environments?
• Do
you
need
more
than
3
environments?
• Do
you
need
automa%on
to
keep
this
working?
• Do
you
need
automated
tes%ng
between
environments?
• Do
you
need
to
allocate
different
environments
to
different
clouds
or
isolate
them
from
other
environments?

35. ©
WSO2
2014
Applica%on
Lifecycle
Management
No
Lifecycle
support
• The
devOps
will
have
more
manual
elements
more
room
for
error
and
less
consistency
• You
are
using
tools
that
cannot
be
integrated
into
your
DevOps
Pla1orm?
• You
aren’t
requiring
promote
standard
processes
in
development?
• You
don’t
have
requirements
for
automated
governance
of
development
products
Lifecycle
support
• Controls
and
Policies
• Standardize
on
tools
like
Maven,
Jenkins,
Agile
project
management,
Git?
• Do
you
have
both
automated
tasks
to
perform
as
part
of
promo%on
and
human
involvement
and
approval?

36. ©
WSO2
2014
Tenant
Administra%on?
Crea<ng
/
Assigning
Tenants
• Different
tenant
tshirt
sizes
supported?
• Assign
tenants
resources
in
different
loca%ons
/
clouds
• Tenant
LDAP
/
security
policies
supported?
Administra<on
of
tenants
• Tenant
size
to
size
migra%on?
• Tenant
instance
migra%on
• Tenant
backup
• Separate
tenant
versions
• Easy
to
see
tenant
SLAs
or
other
performance
characteris%cs
• Tenant
logs
• Tenant
billing
• Tenant
support
with
easy
problem
repor%ng
and
documenta%on

37. CXO
Dashboard
(C)
WSO2
2014

38. ©
WSO2
2014
Store
• Is
there
a
store
for
customers
to
access
applica%ons,
APIs,
subscribe
to
assets
and
be
a
tenant
or
user
of
an
asset?
• Does
the
store
support
a
community
through
social
comments
or
other
community
features?

39. ©
WSO2
2014
Publish
and
Socialize

40. Enterprise App
Integration
& Common
APIs
New IT:
PaaS Powered,
Democratized,
Mobile Enabled,
Socially Aware
Enterprise IT Store: APIs / Apps / Mobile Apps & More
Data Repository & Analytics Foundation
Cloud
Service
Cloud-to-Cloud&Cloud-to-Enterprise
Integration
Partners &
3rd Party
Ecosystem
Happy Users, Customers, Partners, Developers
StratosLive
AppFactory
Ecosystem
PaaS
(C)
WSO2
2014

41. ©
WSO2
2014
WSO2
Private
PaaS
• Generic
PaaS
– Full
polyglot,
hybrid
cloud
support
and
component
resource
sharing
capability
– All
cartridges
and
components
of
the
PaaS
are
mul%-­‐tenant,
fault
tolerant,
no-­‐down-­‐
%me
upgradeable
– Open
source
shared
with
Apache
– Integrated
Performance
Management
– Op%onal
Iden%ty
Management,
BAM,
API
Management
and
BigData
support

42. ©
WSO2
2014
WSO2
Ecosystem
PaaS
-­‐
AppFactory
• Integrated
with
Git,
Svn,
Maven,
Jenkins,
Redmine,
Puppet,
Apache
Stratos
and
other
open
source
projects
• Full
ALM
support
with
business
processes
for
promo%on/demo%on
including
human
tasks
• Full
governance
control
of
what
is
available
in
the
store,
what
tenants
can
do,
where
everything
is
and
the
rules
of
the
PaaS
• A
Social
Enterprise
Store
that
can
share
assets
and
informa%on
between
tenants
based
on
role
• Self-­‐service
interface
for
tenants

43. ©
WSO2
2014
More
Informa%on
• John
Mathon
john@wso2.com
• TwiCer
Feed:
@john_mathon
• Blog:
johnmathon.wordpress.com
• Cloud:
wso2.com/cloud
• Download:
wso2.com
• App
Factory
Signon:
hCps://cloudpreview.wso2.com/