Download to read offline
![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](https://image.slidesharecdn.com/2017-06-21meetupplatformupload-170622133040/75/Meetup-Platform-as-a-Service-Cloud-Foundry-12-2048.jpg)
Uploaded byTipico / Booxware
Meetup: Platform-as-a-Service / Cloud Foundry
The document discusses the principles and benefits of platform-as-a-service (PaaS) and microservice architectures, particularly how they facilitate DevOps practices. It outlines how PaaS enables organizations to focus on their core business while managing operational complexity through self-service systems. Additionally, the document emphasizes the importance of engineering teams taking ownership of their products and workflow for effective deployment and operations.
More Related Content
Similar to Meetup: Platform-as-a-Service / Cloud Foundry
![[Capitole du Libre] #serverless - mettez-le en oeuvre dans votre entreprise...](https://cdn.slidesharecdn.com/ss_thumbnails/capitoledulibre2018serverless-181120135943-thumbnail.jpg?width=640&height=640&fit=bounds)
Meetup: Platform-as-a-Service / Cloud Foundry
- 1.
- 2. CLOUD FOUNDRY & PLATFORMAS 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
- 4.
- 5.
- 6. 6 AS-A-SERVICE PERPETUAL SOFTWARE LICENSES sale maintenancecontracts software upgrade
- 7. 7 AS-A-SERVICE PERPETUAL SOFTWARE LICENSES Constantlygrowing user base (new customers are more important) New killer features are put into next release Various versions are maintained
- 8.
- 9. 9 AS-A-SERVICE • Providers leverageexisting 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 economicrisk • Goal to increase customer satisfaction • Focus on core business
- 11.
- 12. 12 MICROSERVICES "[…]The benefit ofdecomposing 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 microservicesan application easier to understand, develop and test? OVERVIEW BY WIKIPEDIA
- 14. 14 MICROSERVICES • Many peopleinterested in different things • Merge conflicts • Deployment scheduling • Scaling • Tight coupling • Fragility • Rigidity MONOLITH 💾👑 🐧 🍀 🎃
- 15.
- 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 whichdesign 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 howdo microservices parallelize development? OVERVIEW BY WIKIPEDIA
- 20. 20 MICROSERVICES • Independent technologystacks • Independently deployable • Independently scalable 💾👑 💾🐧 💾🍀 💾🎃
- 21. 21 MICROSERVICES "It also parallelizesdevelopment by enabling small autonomous teams to develop, deploy and scale their respective services independently."
- 22.
- 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 OPSis a bottleneck for deployments, then microservices aggravate the situation
- 25. 25 MICROSERVICES "It also parallelizesdevelopment by enabling small autonomous teams to develop, deploy and scale their respective services independently."
- 26.
- 27. 27 DEVOPS "I went tothe 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 blahblah 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 allin 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 onDevOps DISCLAIMER
- 32. 32 DEVOPS Communication and collaboration inDevOps are seriously misunderstood IMHO: COMMUNICATION & COLLABORATION
- 33. 33 DEVOPS It is notabout handoffs between teams, but about communication and collaboration within teams. IMHO: HANDOFFS
- 34. 34 DEVOPS IMHO: HANDOFFS Dev Ops Handoffsdo 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 developmentsuggests 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 theirown 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 runningthings in production
- 38. 38 DEVOPS Business Dev OpsCustomers
- 39.
- 40. 40 DEVOPS • Teams needto 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 toomany skills. We need a way to outsource all these runtime aspects.
- 42.
- 43.
- 44. 44 DEVOPS Self-service systems scale andallow users to work independently.
- 45.
- 46.
- 47. 47 DEVOPS SCALING DevOps Software as a Service Platform asa Service Infrastructure as a Service Domain specific software Runtime Operating System Hardware Virtualization
- 48.
- 49. 49 PLATFORM-AS-A-SERVICE As-a-Service allows focusing oncore 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 ofStandards & 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 providedto 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 systemwhich 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.
- 55.
- 56.
- 57.
- 58. 58 CLOUD FOUNDRY "Here ismy 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 cfcli / REST tcp application developers BOSH bosh cli / REST platform operators application users
- 60. 60 CLOUD FOUNDRY OVERVIEW Cloud Controller Router Diego Cell AppApp 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 • Deployan 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 • Isolationof 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
- 63.
- 64. 64 CLOUD FOUNDRY • BulletinBoard 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 • Routerautomatically 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 • Forwardlogs to e.g. ELK • Enables zero downtime deployments
- 67. 67 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CFrouter blue
- 68. 68 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CFrouter blue green
- 69. 69 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CFrouter blue green
- 70. 70 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CFrouter blue green
- 71. 71 CLOUD FOUNDRY BLUE/GREEN DEPLOYMENT CFrouter blue green
- 72. 72 CLOUD FOUNDRY • Replaceindividual 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.
- 74. 74 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CFrouter v2 v1
- 75. 75 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CFrouter v2 v1
- 76. 76 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CFrouter v1 v2
- 77. 77 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CFrouter v1 v2
- 78. 78 CLOUD FOUNDRY CANARY/ROLLING DEPLOYMENT CFrouter v1 v2
- 79.
- 80.
- 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 mustbe stateless. If you need state, you need a persistent backing service.
- 84. 84 CLOUD FOUNDRY • Integrationof 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.
- 87. 87 Router Cloud Controller BOSH OVERVIEW Cloud Foundry cf cli/ REST tcp application developers BOSH bosh cli / REST platform operators application users
- 88.
- 89. 89 BOSH "Release engineering isthe 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 • Beingable 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 • Astemcell 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
- 92.
- 93.
- 94. 94 SUMMARY As-a-Service allows focusing oncore business Microservices increase operational complexity DevOps requires self-service systems Platform-as- a-Service Cloud Foundry BOSH
- 95. 95 SUMMARY A self-service systemwhich 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.
- 96.
- 97. 97 SUMMARY We believe thatengineering 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.