Meetup: Platform-as-a-Service / Cloud Foundry
- 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
- 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
- 14. 14
MICROSERVICES
• Many people interested in different things
• Merge conflicts
• Deployment scheduling
• Scaling
• Tight coupling
• Fragility
• Rigidity
MONOLITH
💾👑 🐧
🍀 🎃
- 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
💾👑 💾🐧
💾🍀 💾🎃
- 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
💾👑 💾🐧
💾🍀 💾🎃
- 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?
💾👑 💾🐧
💾🍀 💾🎃
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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