Meetup: Platform-as-a-Service / Cloud Foundry
•
4 likes•521 views
The slide deck from our meetup at Booxware Karlsruhe on 2017-06-21. Meetup: https://www.meetup.com/booxware-events/events/239298065/ Talk: https://www.youtube.com/watch?v=CgQ0DsKHSyg Demo: https://youtu.be/CgQ0DsKHSyg?t=1452
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Meetup: Platform-as-a-Service / Cloud Foundry
Similar to Meetup: Platform-as-a-Service / Cloud Foundry (20)
Recently uploaded
Recently uploaded (20)
Meetup: Platform-as-a-Service / Cloud Foundry
- 1. 1
- 2. CLOUD FOUNDRY & PLATFORM AS A SERVICE SEBASTIAN SPRENGER
- 3. 3 AGENDA What are 'Platform-as-a-Service' and 'Cloud Foundry' how can microservice architectures benefit from them, how they play into DevOps, and how Booxware uses them to address challenges
- 5. AS-A-SERVICE
- 6. 6 AS-A-SERVICE PERPETUAL SOFTWARE LICENSES sale maintenance contracts software upgrade
- 7. 7 AS-A-SERVICE PERPETUAL SOFTWARE LICENSES Constantly growing user base (new customers are more important) New killer features are put into next release Various versions are maintained
- 9. 9 AS-A-SERVICE • Providers leverage existing customer base • Less pressure on growing user base • Continuous revenue stream • Opposed to spikes with new release • Shift in goals • New killer features that customers like • Increase customer satisfaction • New features • Availability, Stability • Performance, Support SUBSCRIPTION LICENSING MODEL • Flexible pricing for consumers • Less risk due to high investments • Upgrade on-demand • Try it out and adjust • Outsourcing lets consumers focus on their core business
- 10. 10 AS-A-SERVICE • Decreased economic risk • Goal to increase customer satisfaction • Focus on core business
- 11. MICROSERVICES
- 12. 12 MICROSERVICES "[…]The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. […]" OVERVIEW BY WIKIPEDIA
- 13. 13 MICROSERVICES Why make microservices an application easier to understand, develop and test? OVERVIEW BY WIKIPEDIA
- 14. 14 MICROSERVICES • Many people interested in different things • Merge conflicts • Deployment scheduling • Scaling • Tight coupling • Fragility • Rigidity MONOLITH 💾👑 🐧 🍀 🎃
- 15. 15 MICROSERVICES 💾👑 💾🐧 💾🍀 💾🎃 💾👑 🐧 🍀 🎃
- 16. 16 MICROSERVICES • Small & domain specific • Manage Conway's Law • Strong modularization • Explicit interfaces • Loosely coupled • Stateless protocols • Independent technology stacks • Independently deployable • Independently scalable 💾👑 💾🐧 💾🍀 💾🎃
- 17. 17 CONWAY'S LAW "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" ~ M. Conway
- 18. 18 MICROSERVICES • Small / domain specific • Strong modularization • Loosely coupled • Less things to consider • Less coordination • Testing in isolation EASIER TO UNDERSTAND, DEVELOP AND TEST 💾👑 💾🐧 💾🍀 💾🎃
- 19. 19 MICROSERVICES Why and how do microservices parallelize development? OVERVIEW BY WIKIPEDIA
- 20. 20 MICROSERVICES • Independent technology stacks • Independently deployable • Independently scalable 💾👑 💾🐧 💾🍀 💾🎃
- 21. 21 MICROSERVICES "It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently."
- 23. 23 MICROSERVICES • Loosely coupled • Independent technology stacks • Independently deployable • Independently scalable • Who maintains technology stacks? • Who deploys microservices? • Who decides what to scale when? 💾👑 💾🐧 💾🍀 💾🎃
- 24. 24 MICROSERVICES Dev Ops If OPS is a bottleneck for deployments, then microservices aggravate the situation
- 25. 25 MICROSERVICES "It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently."
- 26. DEVOPS
- 27. 27 DEVOPS "I went to the Deliverey of Things conference and it was interesting to see that while everyone agrees DevOps is a thing and should be done, everyone struggles at actually implementing it." ~ Philipp Deutscher, Director IT Operations, Booxware
- 28. 28 DEVOPS blah blah blah blah MINDSET blah blah blah CULTURE blah blah blah blah PRACTICES blah blah blah COMMUNICATION blah blah blah blah COLLABORATION blah blah blah AUTOMATION blah blah blah blah WORK TOGETHER blah blah blah TOOLCHAIN blah blah blah blah EFFICIENCY blah blah blah QUALITY blah blah blah blah OWNERSHIP blah blah blah NOT THROWING THINGS OVER THE WALL blah blah blah blah RESPONSIBILITY blah blah blah
- 29. 29 DEVOPS "We are all in the same boat" "Improve communication" "Improve collaboration" NEW TERMINOLOGY, NO CHANGE
- 30. 30 DEVOPS • Autonomous teams • Parallelize value delivery • Coordinate less MICROSERVICES 🤔
- 31. 31 DEVOPS My personal take on DevOps DISCLAIMER
- 32. 32 DEVOPS Communication and collaboration in DevOps are seriously misunderstood IMHO: COMMUNICATION & COLLABORATION
- 33. 33 DEVOPS It is not about handoffs between teams, but about communication and collaboration within teams. IMHO: HANDOFFS
- 34. 34 DEVOPS IMHO: HANDOFFS Dev Ops Handoffs do not scale. On the local level, teams do not share the same goals and priorities. "We are all in the same boat" "Improve collaboration" "Improve communication"
- 35. 35 DEVOPS • Test-driven development suggests Developers write tests themselves • Exposure to untestable code • Application of clean code principles and dependency injection • Overall better code quality as a "side effect" • Operators struggle with hard to operate code • Assumptions made, hardcoded values, not scalable • Bad or missing logs and monitoring • How would developers react to the pain of hard to operate code? PAIN AS MOTIVATOR
- 36. 36 DEVOPS "Developers operating their own code make their own code easy to operate" "Engineering teams need to operate their code themselves for DevOps to scale" THESIS
- 37. 37 DEVOPS Developers responsible for running things in production
- 38. 38 DEVOPS Business Dev Ops Customers
- 40. 40 DEVOPS • Teams need to know all layers to bring value to the customer • Software • Runtime • Operating system • Virtual machines • Servers, Network, Storage • Teams need to be isolated from each other, but share resources • Team A ought to not impact team B • Resources ought to be efficiently pooled ASSUMING FULL END-TO-END RESPONSIBILITY
- 41. 41 DEVOPS Teams need too many skills. We need a way to outsource all these runtime aspects.
- 44. 44 DEVOPS Self-service systems scale and allow users to work independently.
- 47. 47 DEVOPS SCALING DevOps Software as a Service Platform as a Service Infrastructure as a Service Domain specific software Runtime Operating System Hardware Virtualization
- 49. 49 PLATFORM-AS-A-SERVICE As-a-Service allows focusing on core business Microservices increase operational complexity DevOps requires self-service systems Platform-as- a-Service BOSH Cloud Foundry
- 50. 50 PLATFORM-AS-A-SERVICE •National Institute of Standards & Technology (NIST) • Branch of U.S. Department of Commerce •"The NIST Definition of Cloud Computing" • NIST Special Publication 800-145
- 51. 51 PLATFORM-AS-A-SERVICE • Essential Characteristics • On-demand self-service • Broad network access • Resource pooling • Rapid elasticity • Measured service • Service Models • Software as a Service (SaaS) • Platform as a Service (PaaS) • Infrastructure as a Service (IaaS) NIST DEFINITION OF CLOUD COMPUTING • Deployment Models • Private cloud • Community cloud • Public cloud • Hybrid cloud
- 52. 52 PLATFORM-AS-A-SERVICE "The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider (This capability does not necessarily preclude the use of compatible programming languages, libraries, services, and tools from other sources). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment." NIST DEFINITION OF CLOUD COMPUTING
- 53. 53 PLATFORM-AS-A-SERVICE A self-service system which engineers can use to • deploy a microservice and specify a configuration, • start, stop, restart apps, • scale instances, • forward logs to logging system without needing to care how or when. WHAT
- 54. CLOUD FOUNDRY
- 57. 57 CLOUD FOUNDRY
- 58. 58 CLOUD FOUNDRY "Here is my source code run it on the cloud for me I do not care how" ~ Onsi Fakhouri Vice President of Cloud R&D Pivotal
- 59. 59 Router Cloud Controller CLOUD FOUNDRY OVERVIEW Cloud Foundry cf cli / REST tcp application developers BOSH bosh cli / REST platform operators application users
- 60. 60 CLOUD FOUNDRY OVERVIEW Cloud Controller Router Diego Cell App App App App App App App App App App App App 011010 110001 100010 010101 Blobstore 011010 110001 100010 010101 011010 110001 100010 010101 tcp jar jar container
- 61. 61 CLOUD FOUNDRY • Deploy an application • Configure an application • Start, stop, restart application • Scale an application • Stream application logs • Connect to application container via ssh OVERVIEW
- 62. 62 CLOUD FOUNDRY • Isolation of users • Authentication and Authorization based on RBAC • Integrates with LDAP and SAML • Users can only manage apps they have access to • Quotas control maximum resource consumption • Isolation of applications • Every application runs within a container • Isolation segments separate compute resources OVERVIEW
- 64. 64 CLOUD FOUNDRY • Bulletin Board System • Maintains a real-time representation of the state of the Diego cluster • Checks against desired state • Brain • Coordinates work placement on cluster through auction algorithm • Cell • Runs Tasks and Long Running Processes (LRP) DIEGO
- 65. 65 CLOUD FOUNDRY • Router automatically distributes load between instances • No direct connection to app instance • Diego runs containers and keeps them running • Custom healthchecks (process, port, http) • Buildpacks turn code into containers • Java, Golang, Ruby, Python, NGINX, .net, php, node.js • Write your own or use community buildpacks • Run docker images
- 66. 66 CLOUD FOUNDRY • Forward logs to e.g. ELK • Enables zero downtime deployments
- 67. 67 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CF router blue
- 68. 68 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CF router blue green
- 69. 69 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CF router blue green
- 70. 70 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CF router blue green
- 71. 71 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CF router blue green
- 72. 72 CLOUD FOUNDRY • Replace individual instances of an existing app to monitor the behavior • Application with three instances • Create a new independent app with 1 instance • Add target route to new app • Scale down 1 instance on old app • Scale up 1 instance on new app • Scale down 1 instance on old app • Scale up 1 instance on new app • Repeat until new app has take fully over • Cleanup CANARY/ROLLING DEPLOYMENT
- 73. 73 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v1
- 74. 74 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v2 v1
- 75. 75 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v2 v1
- 76. 76 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v1 v2
- 77. 77 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v1 v2
- 78. 78 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v1 v2
- 79. 79 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v2
- 80. 80 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CF router v2
- 81. 81 CLOUD FOUNDRY • I. Codebase One codebase tracked in revision control, many deploys • II. Dependencies Explicitly declare and isolate dependencies • III. Config Store config in the environment • IV. Backing services Treat backing services as attached resources • V. Build, release, run Strictly separate build and run stages • VI. Processes Execute the app as one or more stateless processes 12-FACTORS
- 82. 82 CLOUD FOUNDRY • VII. Port binding Export services via port binding • VIII. Concurrency Scale out via the process mode • lIX. Disposability Maximize robustness with fast startup and graceful shutdown • X. Dev/prod parity Keep development, staging, and production as similar as possible • XI. Logs Treat logs as event streams • XII. Admin processes Run admin/management tasks as one-off processes 12-FACTORS
- 83. 83 CLOUD FOUNDRY Apps must be stateless. If you need state, you need a persistent backing service.
- 84. 84 CLOUD FOUNDRY • Integration of services via Service Broker API • Databases, message-queues, caches, etc • Users can create service instances via the platform • Bind service instances to application • CF injects config into app's environment • Client lib can read them
- 85. 85 CLOUD FOUNDRY service-instance Broker service-instance Broker IaaS / KubernetesCloud Foundry app app app app API
- 86. BOSH
- 87. 87 Router Cloud Controller BOSH OVERVIEW Cloud Foundry cf cli / REST tcp application developers BOSH bosh cli / REST platform operators application users
- 89. 89 BOSH "Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well." ~ Boris Debic Release Engineer Google RELEASE ENGINEERING
- 90. 90 BOSH • Identifiability • Being able to identify all of the source, tools, environment, and other components that make up a particular release. • Reproducibility • The ability to integrate source, third party components, data, and deployment externals of a software system in order to guarantee operational stability. • Consistency • The mission to provide a stable framework for development, deployment, audit, and accountability for software components. • Agility • The ongoing research into what are the repercussions of modern software engineering practices on the productivity in the software cycle, i.e. continuous integration. RELEASE ENGINEERING
- 91. 91 BOSH • Stemcell • A stemcell is a versioned Operating System image wrapped with IaaS specific packaging. • Release • A release is a versioned collection of configuration properties, configuration templates, start up scripts, source code, binary artifacts, and anything else required to build and deploy software in a reproducible way. • Deployment • A deployment is a collection of VMs, built from a stemcell, that has been populated with specific releases and disks that keep persistent data. These resources are created based on a manifest file in the IaaS and managed by the BOSH Director, a centralized management server. TERMINOLOGY
- 93. SUMMARY
- 94. 94 SUMMARY As-a-Service allows focusing on core business Microservices increase operational complexity DevOps requires self-service systems Platform-as- a-Service Cloud Foundry BOSH
- 95. 95 SUMMARY A self-service system which engineers can use to • deploy a microservice and specify a configuration, • start, stop, restart apps, • scale instances, • forward logs to logging system without needing to care how or when.
- 97. 97 SUMMARY We believe that engineering teams ought to • bring features into production at their pace, • be responsible for their product end-to-end, and • be in control of their workflow. BOOXWARE
- 98. Q & A