Design and Architecture Derek Collison What is Cloud Foundry? 2 - - PowerPoint PPT Presentation

▶
design and architecture
SMART_READER_LITE
LIVE PREVIEW

Design and Architecture Derek Collison What is Cloud Foundry? 2 - - PowerPoint PPT Presentation

Sep 12, 2023 455 likes •1.1k views

Design and Architecture Derek Collison What is Cloud Foundry? 2 The Open Platform as a Service 3 What is PaaS? 4 Or more specifically, aPaaS? 5 aPaaS Application Platform as a Service Applications and Services 6 aPaaS

slide-1
SLIDE 1

Derek Collison

Design and Architecture

slide-2
SLIDE 2

What is Cloud Foundry?

2

slide-3
SLIDE 3

The Open Platform as a Service

3

slide-4
SLIDE 4

What is PaaS?

4

slide-5
SLIDE 5

Or more specifically, aPaaS?

5

slide-6
SLIDE 6

aPaaS

  • Application Platform as a Service
  • Applications and Services

6

slide-7
SLIDE 7

aPaaS

  • Application Platform as a Service
  • Applications and Services
  • Not
  • VMs
  • Memory
  • Storage
  • Networks
  • CPU

7

slide-8
SLIDE 8

What is OpenPaaS?

8

slide-9
SLIDE 9

OpenPaaS

  • Multi-Language
  • Multi-Framework
  • Multi-Services
  • Multi-Cloud, Multi-IaaS
  • Hybrid - Public or Private or Both
  • OpenSource

9

slide-10
SLIDE 10

OpenPaaS

  • Multi-Language
  • Ruby, Java, Scala, Node.js, Erlang, Python, PHP..
  • Multi-Framework
  • Rails, Sinatra, Spring, Grails, Express, Lift
  • Multi-Services
  • MySQL, Postgres, MongoDB, Redis, RabbitMQ
  • Multi-Cloud, Multi-IaaS
  • vSphere, MicroCloud, OpenStack, AWS

10

slide-11
SLIDE 11

The Open PaaS

C l

  • u

d P r

  • v

i d e r I n t e r f a c e Application Service Interface Private Clouds Public Clouds Micro Clouds

11

Data Services Other Services Msg Services

vFabric Postgres vFabric RabbitMQTM

slide-12
SLIDE 12

What is

  • ur Goal?

12

slide-13
SLIDE 13

What was our Goal?

13

Raise the unit of currency to be the application and its associated services, not the infrastructure

slide-14
SLIDE 14

What was our Goal?

14

Best of breed delivery platform for all modern applications and frameworks

slide-15
SLIDE 15

What was our Goal?

15

Favor Choice and Openness

slide-16
SLIDE 16

How was it Built?

16

slide-17
SLIDE 17

How was it Built?

  • Kernel (CloudFoundry OSS)
  • Core PaaS System
  • Kernel and Orchestrator Shells
  • Layered on top of IaaS
  • Orchestrator
  • IaaS creation, management and
  • rchestration

17

slide-18
SLIDE 18

High Level

18

IaaS Orchestrator CF Kernel Hardware - CPU/Memory/Disk/Network Clients (VMC, STS, Browser)

slide-19
SLIDE 19

Basic Premises

  • Fail Fast
  • Self Healing
  • Horizontally Scalable Components
  • Distributed State
  • No Single Point of Failure
  • Should be as simple as possible

19

slide-20
SLIDE 20

Basic Patterns

  • Event-Driven
  • Asynchronous
  • Non-blocking
  • Independent, Idempotent
  • Message Passing
  • Eventually Consistent

20

slide-21
SLIDE 21

Basic Design

  • All components loosely coupled
  • Few “Classes”, many “Instances”
  • Messaging as foundation
  • Addressing and Component Discovery
  • Command and Control
  • JSON payloads
  • HTTP or File/Blob for data transport

21

slide-22
SLIDE 22

Kernel Components

  • All dynamically discoverable
  • Launch and scale in any order
  • Can come and go as needed
  • Monitor via HTTP and JSON
  • Location independent

22

slide-23
SLIDE 23

Kernel Components

  • Router
  • CloudController
  • DEA
  • HealthManager
  • Service Provisioning Agent
  • Messaging System

23

slide-24
SLIDE 24

Logical View

24

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-25
SLIDE 25

25

A r c h i t e c t u r e

slide-26
SLIDE 26

Messaging

26

slide-27
SLIDE 27

Messaging

27

“The Nervous System”

slide-28
SLIDE 28

Messaging

28

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-29
SLIDE 29

Messaging

  • Addressing and Discovery
  • No static IPs or DNS lookups req’d
  • Just Layer 4
  • Command and Control
  • Central communication system
  • Dial tone, fire and forget
  • Protects *itself* at all costs
  • Idempotent semantics

29

slide-30
SLIDE 30

Router

30

slide-31
SLIDE 31

Router

31

“Traffic Cop”

slide-32
SLIDE 32

Router

32

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-33
SLIDE 33

Router

  • Handles all HTTP traffic
  • Maintains distributed routing state
  • Routes URLs to applications
  • Distributes load among instances
  • Realtime distributed updates to

routing tables from DEAs

33

slide-34
SLIDE 34

CloudController

34

slide-35
SLIDE 35

CloudController

35

“The King”

slide-36
SLIDE 36

CloudController

36

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-37
SLIDE 37

CloudController

  • Handles all state transitions
  • Deals with users, apps, and services
  • Packages and Stages applications
  • Binds Services to Applications
  • Presents external REST API

37

slide-38
SLIDE 38

HealthManager

38

slide-39
SLIDE 39

HealthManager

39

“Court Jester”

slide-40
SLIDE 40

HealthManager

40

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-41
SLIDE 41

HealthManager

  • Monitors the state of the world
  • Initial value with realtime delta

updates to “intended” vs “real”

  • Determines drift
  • Complains to the CloudControllers

when something is not correct

  • No power to change state itself

41

slide-42
SLIDE 42

DEA

42

slide-43
SLIDE 43

DEA

43

“Droplet Execution Agent”

slide-44
SLIDE 44

DEA

44

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-45
SLIDE 45

DEA

(Droplet Execution Agent)

  • Responsible for running all applications
  • Monitors all applications
  • CPU, Mem, IO, Threads, Disk, FDs, etc
  • All apps look same to DEA
  • start and stop
  • Express ability and desire to run an application
  • runtimes, options, cluster avoidance, memory/cpu
  • Alerts on any change in state of applications
  • Provides secure/constrained OS runtime
  • Hypervisor, Unix File and User, Linux Containers*
  • Single or Multi-Tenant

45

slide-46
SLIDE 46

How does it all Work?

46

slide-47
SLIDE 47

Pushing an App

  • Client (VMC/STS) pushes meta-data to CC
  • Client optionally pushes resource

signatures (diff analysis, sys wide)

  • Client pushes app resources to CC
  • CC puts app together
  • CC stages app asynchronously
  • CC binds and stages services
  • Droplet ready

47

slide-48
SLIDE 48

48

A r c h i t e c t u r e

slide-49
SLIDE 49

Running an App

  • CC asks DEAs for “help”
  • First DEA back wins! Simple
  • CC sends start request to selected DEA
  • DEA pushes the “green” button
  • DEA waits and monitors pid and ephemeral

port for app to bind

  • When app is healthy, sends “register” message
  • Register message is seen by HM and Routers
  • Routers bind URL to host:port

49

slide-50
SLIDE 50

DEAs answer?

  • DEAs first determine YES or NO
  • correct runtime, options, memory, etc
  • Then calculate a Delay Taint
  • SHA hash of application
  • memory
  • cpu
  • Taint allows balancing and selection

50

slide-51
SLIDE 51

Scale up & down?

  • Exact steps as running the app

the first time

  • SHA1 taint helps avoid clustering
  • memory/cpu taint helps distribute

as evenly as possible

  • Nothing pre-computed
  • Nothing assumed

51

slide-52
SLIDE 52

Crashes?

  • If your app stops and we did not tell

it to, that is a crash

  • Crashed apps are immediately

detected by DEA and messaged

  • Routers disconnect route instantly
  • HM will signal CC
  • something is wrong
  • CC will issue run sequence again

52

slide-53
SLIDE 53

53

A r c h i t e c t u r e

slide-54
SLIDE 54

Access to my App?

  • All routers understand where all

instances of your application are running

  • Will randomly pick backend, not

semantically aware.

  • Will remove routes that are stale or

unhealthy

  • Session stickiness and replication

available, but best to avoid if possible

54

slide-55
SLIDE 55

What about Services?

55

slide-56
SLIDE 56

Services

56

VMC client STS plugin Browser (user app access) Routers CloudControllers App Services App HealthManager DEA Pool Messaging

slide-57
SLIDE 57

Services

  • Service Advertisement
  • Service Provisioning
  • Gateway fronts multi-backends
  • Service Nodes scale independent
  • App and service talk directly
  • API to register into system
  • Closure for additional value

57

slide-58
SLIDE 58

Provisioning

58

VMC/STS Routers CloudControllers Services Gateway Service Node MySQL Service Node Redis Service Node Redis Messaging Application

1 2 3 4 5 6

slide-59
SLIDE 59

Access (Direct)

59

Routers CloudControllers Services Gateway Service Node MySQL Service Node Redis Service Node Redis Messaging Application

1 2

Browser (user app access)

slide-60
SLIDE 60

Services

60

Cloud Foundry

vSphere

core services

Enterprise Services

SQLFire

apps service controller service broker provision/bind

consume

consume bind VMware Dev Tools Partner Dev Tools

Data Director

Relational DB

slide-61
SLIDE 61

Learn more:

www.cloudfoundry.org blog.cloudfoundry.com support.cloudfoundry.com

61

slide-62
SLIDE 62

62

Thank You

slide-63
SLIDE 63

63

Questions?

dcollison@vmware.com derek.collison@gmail.com twitter: derekcollison