How to Adapt Cloud Foundry to Organizations’ Contexts ?
0 likes704 views
The document discusses how organizations, specifically Orange, can adapt Cloud Foundry to meet their specific needs through customization and extension mechanisms. It outlines the challenges of transitioning from centralized governance to decentralized autonomy, as well as potential solutions, such as leveraging existing customization options and proposing new extension hooks. Additionally, it invites collaboration and sharing of experiences regarding adaptation strategies.
![Intro
• About Orange
• Disclaimer
• About me
• Contact me: @gberche or guillaume.berche [at] orange.com
3](https://image.slidesharecdn.com/adaptingcftoorgreqs-150603070404-lva1-app6891/85/How-to-Adapt-Cloud-Foundry-to-Organizations-Contexts-3-320.jpg)
![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]](https://image.slidesharecdn.com/adaptingcftoorgreqs-150603070404-lva1-app6891/85/How-to-Adapt-Cloud-Foundry-to-Organizations-Contexts-34-320.jpg)
How to Adapt Cloud Foundry to Organizations’ Contexts ?
- 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
- 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
- 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
- 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
- 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