Meetup: Platform-as-a-Service / Cloud Foundry

CLOUD FOUNDRY &PLATFORM AS A SERVICESEBASTIAN SPRENGER

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

AGENDA

As-a-Service

Microservices

DevOps

Platform-as-a-Service

Cloud Foundry

BOSH

AS-A-SERVICE

6

AS-A-SERVICEPERPETUAL SOFTWARE LICENSES

salemaintenance contracts

software upgrade

7

AS-A-SERVICEPERPETUAL SOFTWARE LICENSES

Constantly growing user base (new customers are more important)

New killer features are put into next release

Various versions are maintained

8

AS-A-SERVICESUBSCRIPTION LICENSING MODEL

Provider Consumer

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

AS-A-SERVICE

• Decreased economic risk• Goal to increase customer satisfaction• Focus on core business

MICROSERVICES

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

MICROSERVICES

Why make microservices an application easier to

understand, develop and test?


14

MICROSERVICES

• Many people interested in different things• Merge conflicts• Deployment scheduling• Scaling

• Tight coupling• Fragility• Rigidity

MONOLITH

💾👑🐧🍀 🎃

15

MICROSERVICES

💾👑 💾🐧💾🍀 💾🎃💾👑🐧🍀 🎃

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

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

MICROSERVICES

• Small / domain specific• Strong modularization• Loosely coupled

• Less things to consider• Less coordination• Testing in isolation

EASIER TO UNDERSTAND, DEVELOP AND TEST

💾👑 💾🐧💾🍀 💾🎃

19

MICROSERVICES

Why and how do microservices parallelize development?


20

MICROSERVICES

• Independent technology stacks• Independently deployable• Independently scalable 💾👑 💾🐧

💾🍀 💾🎃

21

MICROSERVICES

"It also parallelizes development by enabling small autonomous teams to

develop, deploy and scale their

respective services independently."

22

MICROSERVICES

BUT

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

MICROSERVICES

Dev Ops

If OPS is a bottleneck for deployments, then microservices aggravate the situation

25

MICROSERVICES

"It also parallelizes development by

enabling small autonomous teams to develop, deploy and scale

their respective services independently."

DEVOPS

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

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 OWNERSHIPblah blah blah NOT THROWING THINGS OVER THE WALL blah blah

blah blah RESPONSIBILITY blah blah blah

29

DEVOPS

"We are all in the same boat"

"Improve communication"

"Improve collaboration"

NEW TERMINOLOGY, NO CHANGE

30

DEVOPS

• Autonomous teams• Parallelize value delivery• Coordinate less

MICROSERVICES

🤔

31

DEVOPS

My personal take on DevOps

DISCLAIMER

32

DEVOPS

Communication and collaboration in DevOps are

seriously misunderstood

IMHO: COMMUNICATION & COLLABORATION

33

DEVOPS

It is not about handoffs betweenteams, but about communication and collaboration within teams.

IMHO: HANDOFFS

34

DEVOPSIMHO: 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

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

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

DEVOPS

Developers responsible for running things in production

38

DEVOPS

Business Dev Ops Customers

39

DEVOPS

Business DevOps Customers

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

DEVOPS

Teams need too many skills.

We need a way to outsource all these runtime aspects.

42

DEVOPSSCALING


43

DEVOPS

People do not scale 😢

44

DEVOPS

Self-service systems scale and allow users to work independently.

45

DEVOPSSCALING


46

DEVOPSSCALING


47

DEVOPSSCALING

DevOpsSoftware as a Service

Platformas a Service

Infrastructureas a Service

Domain specific software

RuntimeOperating System

HardwareVirtualization

PLATFORM-AS-A-SERVICE

49


As-a-Serviceallows focusing on core business

Microservicesincrease operational complexity

DevOpsrequires self-service systems


BOSH

Cloud Foundry

50


•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


• 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


"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


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

CLOUD FOUNDRY

55


56

PLATFORM-AS-A-SERVICECLOUD FOUNDRY

57

CLOUD FOUNDRY

58

CLOUD FOUNDRY

"Here is my source coderun it on the cloud for me

I do not care how"~ Onsi Fakhouri

Vice President of Cloud R&DPivotal

59

Router

Cloud Controller

CLOUD FOUNDRYOVERVIEW

Cloud Foundry

cf cli / REST

tcp

application developers

BOSHbosh cli / REST

platform operators

application users

60

CLOUD FOUNDRYOVERVIEW

Cloud Controller

Router

Diego CellApp App App App

App App App App

App App App App

011010110001100010010101

Blobstore011010110001100010010101

011010110001100010010101

tcp

jar

jar container

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

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

63

CLOUD FOUNDRYDEMO

https://youtu.be/CgQ0DsKHSyg?t=1452

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

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

CLOUD FOUNDRY

• Forward logs to e.g. ELK• Enables zero downtime deployments

67

CLOUD FOUNDRYBLUE/GREEN DEPLOYMENT

CF router

blue

68


CF router

blue

green

69


CF router

blue

green

70


CF router

blue

green

71


CF router

blue

green

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

CLOUD FOUNDRYCANARY/ROLLING DEPLOYMENT

CF router

v1

74


CF router

v2

v1

75


CF router

v2

v1

76


CF router

v1

v2

77


CF router

v1

v2

78


CF router

v1

v2

79


CF router

v2

80


CF router

v2

81

CLOUD FOUNDRY

• I. CodebaseOne codebase tracked in revision control, many deploys

• II. DependenciesExplicitly declare and isolate dependencies

• III. ConfigStore config in the environment

• IV. Backing servicesTreat backing services as attached resources

• V. Build, release, runStrictly separate build and run stages

• VI. ProcessesExecute the app as one or more stateless processes

12-FACTORS

82

CLOUD FOUNDRY

• VII. Port bindingExport services via port binding

• VIII. ConcurrencyScale out via the process mode

• lIX. DisposabilityMaximize robustness with fast startup and graceful shutdown

• X. Dev/prod parityKeep development, staging, and production as similar as possible

• XI. LogsTreat logs as event streams

• XII. Admin processesRun admin/management tasks as one-off processes

12-FACTORS

83

CLOUD FOUNDRY

Apps must be stateless. If you need state, you need a persistent backing service.

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

CLOUD FOUNDRY

service-instance

Brok

er

service-instance

Brok

er

IaaS / KubernetesCloud Foundry

app app

app app

API

87

Router

Cloud Controller

BOSHOVERVIEW

Cloud Foundry

cf cli / REST

tcp

application developers

BOSHbosh cli / REST

platform operators

application users

88

BOSH

Release Engineering

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 DebicRelease Engineer

Google

RELEASE ENGINEERING

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

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

92

BOSHARCHITECTURE

SUMMARY

94

SUMMARY

As-a-Serviceallows focusing on core business

Microservicesincrease operational complexity

DevOpsrequires self-service systems


Cloud Foundry

BOSH

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.

96

SUMMARY


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

Meetup: Platform-as-a-Service / Cloud Foundry

Engineering

Transcript of Meetup: Platform-as-a-Service / Cloud Foundry