38
@dwStrebel Dave Strebel

12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Embed Size (px)

Citation preview

Page 1: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

@dwStrebel

Dave Strebel

Page 2: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

@dwStrebel

Dave Strebel

Hybrid IT

12 Factor

Microservices

PaaS

Oh My!

Page 3: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

12 Factor Apps

Page 4: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

CLOUD SUCCESS ?

WE GOT THIS!

HYBRID IT ?I. Codebase

Page 5: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

git commit “not negotiable”

May 1, 2023 5

Page 6: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

II. Dependencies

Page 7: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Definitions : Yours and Theirs

High

• Never assume it will just be there

• Most frameworks do it for you

• Extends to ops team

Page 8: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

III. Config

Page 9: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High• Anything that might vary • Usernames and passwords

count• Sloppy if you don’t do it

May 1, 2023 9

Page 10: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

IV. Backing Services

Page 11: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High• Referenced by simple URL• Code shouldn’t notice the

difference• Allows a lot of flexibility

May 1, 2023 11

Page 12: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

V. Build, Release, Run…

Page 13: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High• Tools and framework

should drive best practices

May 1, 2023 13

Page 14: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

VI. Processes

Page 15: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High

• Each instance should be stateless

• State defined by db or shared storage

• Store intermediate data in key-value

May 1, 2023 15

Page 16: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

VII. Port Binding

Page 17: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Medium

• Application should interface through simple URL

• Create separate URL for internal and external

May 1, 2023 17

Page 18: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Runn

ing

Proc

esse

s

Process Types

VIII. Concurrency

Page 19: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Low• Small parts working

independently• Allows more concurrency

May 1, 2023 19

Page 20: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

May 1, 2023CTL Cloud Platform Montly Ops Review 20

IX. Disposability

Page 21: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Medium• Use high speed DB’s and

cache’s• Don’t use cleanup task

May 1, 2023 21

Page 22: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

X. Dev\Prod Parity

Page 23: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High

• Keep similar as possible• Same backing services• Same configuration

management • Same libraries

May 1, 2023 23

Page 24: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

XI. Logs

Page 25: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High• Treat logs as event

streams• Consolidate logs

May 1, 2023 25

Page 26: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

May 1, 2023 26

XI. Admin Processes

Page 27: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

High • Run one off task• Don’t use local terminal

May 1, 2023 27

Page 28: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Cloud Foundry(Opinionated Platform)

May 1, 2023CTL Cloud Platform Montly Ops Review 28

Page 29: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

May 1, 2023 29

CF Architecture

Page 30: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

The router shapes and routes all external system traffic (HTTP/API) and application traffic from the internet/intranet. It maintains a dynamic routing table for each load-balanced app instance with IP addresses and ports.

How It Works:

• Load balancing• Maintaining an active routing

table• Access logs• Supports web-sockets

Responsible For:

Router

Page 31: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

The Cloud Controller maintains command and control systems, including interface with clients (CLI, Web UI, Spring STS), account and provisioning control. It also provides RESTful interface to domain objects (apps, services, organizations, spaces, service instances, user roles, and more).

How It Works:

• Expected App state, state transitions, and desired convergence

• Permissions/Auth• Orgs/Spaces/Users • Services management• App placement• Auditing/Journaling and billing

events• Blob storage

Responsible For:

Cloud Controller

Page 32: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

“Droplet Execution Agents” are secure and fully isolated containers. DEAs are responsible for an Apps lifecycle: building, starting and stopping Apps as instructed. They periodically broadcast messages about their state via the NATS message bus.

How It Works:

• Managing Linux containers (Warden)• Monitoring resource pools

• Process• File system• Network• Memory

• Managing app lifecycle• App log and file streaming• DEA heartbeats (NATS to CC, HM)

Responsible For:

DEA

Page 33: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Buildpacks are Ruby scripts that detect application runtimes/frameworks/plugins, compile the source code into executable binaries, and release the app to an assigned DEA. Runtime components can be cached for faster execution of subsequent app pushes.

How It Works:

• Staging*• /bin/detect• /bin/compile• /bin/release

• Configure droplet• Runtime

(Ruby/Java/Node/Python)• Container

(Tomcat/Websphere/Jetty)• Application (.WAR, .rb, .js, .py)

Responsible For:

Buildpacks

Page 34: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Service Brokers provide an interface for native and external 3rd party services. Service processes run on Service Nodes or with external as-a-service providers (e.g., email, database, messaging, etc.).

How It Works:

• Advertising service catalog• Makes create/delete/bind/unbind

calls to service nodes• Requests inventory of existing

instances and bindings from cloud controller for caching, orphan management

• SaaS marketplace gateway• Implemented as HTTP enpoint,

written in any language.

Responsible For:

Service Broker

Page 35: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

UPSI (formerly “Service Connectors”) store meta-data in the Service Broker to enable Cloud Foundry to connect to local services that are NOT managed by Cloud Foundry (e.g., OracleDB, DB2, SQLServer, etc.)

How It Works:

• Metadata managementResponsible For:

User Provided Service Instances

Page 36: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Health Manager monitors application uptime by listening to the NATS message bus for mismatched application states (expected vs. actual). The Cloud Controller publishes expected state and the DEAs publish actual state. State mismatches are reported to the Cloud Controller.

How It Works:

• Maintains the actual state of apps

• Compares to expected state• Sends suggestions to make actual

match expected (cannot make state changes itself – only CC can do that!)

Responsible For:

Health Manager

Page 37: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Demo Time!

Page 38: 12 Factor Apps and Cloud Foundry - Twin Cities Code Camp

Q & A