Slides from the cloudfoundry ummit 2015 session, see full cfsummit schedule at http://www.cfsummit.com/program ------------------ Original Cf summit session description: Adopting a paas to meet new business objectives, often requires more than providing an out-of-the-box Cloud Foundry instance: integration in the organization’s existing ecosystem and support-for/transformation-of the organization processes might be key to CF adoption. This session introduces a BOF on how can CF be adapted to match organizations-specific contexts. In particular, this introduction presents an experience sharing from Orange Labs, proposing to use the impact mapping technique to gather and analyze organisation specific requirements. It outlines how Orange is adapting CF through the “ElPaaSo” product which is being opensourced. The participants are then invited to join the BOF session on tues 10.40am to share their own org-specific reqs, how they’ve so far adapted CF to match them, and imagining ways CF could potentially be extended in the future to natively support additional customizations and extension mechanisms. --------------------

2. How to Adapt Cloud Foundry
to Organizations’ Contexts ?
BOF introduction, Guillaume Berche

3. Intro
• About Orange
• Disclaimer
• About me
• Contact me: @gberche or guillaume.berche [at] orange.com
3

4. Session overview
• Sharing from Orange of specific
requirements
• Ways Orange is adapting CF to its reqs
• Potential future useful CF extension hooks
4

5. Impact mapping introduction
Credits: Gojko Adzic http://impactmapping.org/
5

6. Orange Paas impact map
https://www.mindmup.com/#m:h1gberche-orange/adapting-cf-to-org-
reqs:master:/Adapting%20CF%20to%20organizations.mup
http://goo.gl/LfjBDC
https://github.com/gberche-orange/adapting-cf-to-org-reqs
6
> who > how > what

7. > objectives
7

8. Actors overview
8

9. > actors
9

10. > app-dev > test toys/tools
10

11. > app-dev > test toys/tools > provide CF instance
11

12. > app-dev
12

13. > app-dev
13

14. My CF set up (is going great),
My production-ready paas is maturing
(fast)
14

15. > app-dev
15

16. Credit: http://en.wikipedia.org/wiki/Diffusion_of_innovations
16

17. > app-dev > develop app on CF
17

18. > actors
18

19. > app-ops
19

20. > app-ops > operate custom app
20

21. Limitations/obstacles:
• organisation slow to change:
– lacking dedicated-ops,
– project vs product,
– outsourced software
– slow to accept transition « from centralized governance
to decentralized autonomy »
• legacy apps take time to transform
21

22. • centralized governance to decentralized
autonomy... with transparency
• Provide common baseline
• Involve current experts in paas automation
– services is still the limiting factor
How can I help the « vast majority »
?
22

23. ElPaaso Overview
23

24. ElPaaso data model
24
application
useruseruser
processing
service
releasereleaserelease
architecture
releasereleaseenvironment
{ data, comm, mgt}
service
ElPaaso CF
environment space + space_roles
processing-service app + syslog_drain service + buildpack params
data service service instance
comm service route, esb service instance (arb param)
mgt service app env var
CF modelElPaaso model
with org-specific
meta-data
Pluggeable,
versionned
projection

25. > app-ops > operate custom app
25

26. > app-ops > operate custom app > user standard operation model
26

27. > app-ops > operate custom app > user standard operation model
27

28. > app-ops > operate custom app > user standard operation model
28

29. > app-ops > operate custom app
29

30. • centralized governance to decentralized
autonomy... with transparency
• Provide common baseline
• Involve existing shared infrastructure experts
in paas automation
– services is still the limiting factor
How can I help the « vast majority » ?
30

31. > actors
31

32. > off-stage actors
32

33. Alternatives for adapting cf to orgs reqs
• Use existing CF extension/customization
mechanisms
34

34. Overview of existing customization mechanisms
• uaa backend: (ldap/saml)
• org (name)
• space (name)
• service brokers
– static endpoints (instead of cups): smtp, splunk
– driving org systems (e.g. orange DBaaS)
– upcoming arbitrary params (e.g. api subscription)
• default buildpacks configuration
– (through env vars, app bits hooks, forks)
• custom buildpack (e.g. jonas)
• custom syslog drains
– intermediates that insert additional data
• custom services
– bosh releases
– bosh docker service broker
– mesos 35
• persistent fs bridge
– fuse + riakcs
– aop interception.
• app security groups
• cli plugins
• notification service
• [custom stacks]
• [custom stemcells]

35. Alternatives for adapting cf to orgs reqs
• Use existing CF extension/customization
mechanisms
• Fork and extend CF
– insert additional components
– replace some components
• Add-on to CF
36

36. Potential future useful CF extension hooks
• meta-data attached to some entities (app, space, service)
– production
– ops entity
– app code name
– ops on call contacts/ids
– app version
– cost-center
• intercept some CC API verbs (router service or CC webhooks)
– fine grain access control
– transformations
– extensions, new verbs
37

37. Lets share our reqs and experience
Meet tomorrow at 10.40 am for a
related BOF
How have you adapted CF ?
Any remaining challenges to share?
Thank you.
38