The document discusses the transition from Cloud Foundry's DEA to Diego, which addresses various limitations of the DEA system by using a distributed architecture for managing containerized workloads. Diego supports multiple container formats and improves orchestration through its core components such as auctioneer, converger, and others. The document also outlines the migration process and new features available with Diego, emphasizing its capabilities for handling modern applications.

1. PCF1: Cloud Foundry Diego:
What to Expect
Amulya Sharma
amulya.sharma1@ge.com
@amulyasharma

2. 2PREDIX TRANSFORM
Agenda
Why Diego1
What is Diego
Migrating
Demo
2
3
4

3. 3PREDIX TRANSFORM
Why Diego?
I just pushed my apps to DEA and it’s working great!
Why change to Diego now?

4. 4PREDIX TRANSFORM
How DEA Works
Cloud
Controller
Router
Nats
Health
Monitor
DEA
Staging
Apps
Running
Apps
WardenPush App
https://

5. 5PREDIX TRANSFORM
Limitations of DEA
Orchestration
Cloud Controller
has too much responsibility
Cloud
Controller
DEA
Warden
DEA
Warden
DEA
Warden

6. 6PREDIX TRANSFORM
Limitations of DEA
Triangular Dependencies
CC
DEA HM
Cloud
Controller
DEA
Warden
DEA
Warden
Health
Manager
bye
all clear
start somewhere elsestart

7. 7PREDIX TRANSFORM
Limitations of DEA
Domain
Specific
Its all about apps
Makes it hard to
add new things:
Cron Job?
One time task?
Cloud
Controller
Router
Nats
Health
Monitor
DEA
Staging
Apps
Running
Apps
Warden
Push App

8. 8PREDIX TRANSFORM
Limitations of DEA
DEA and Warden
• Longed – lived processes
• Concurrency
• Low level OS Interactions

9. 9PREDIX TRANSFORM
Platform Specific
2009 20152014
Containers weren’t on
anyone’s roadmap
before 2014. They are
on everyone’s roadmap
now.
It is important for a
container runtime to
supports multiple
container formats.

10. 10PREDIX TRANSFORM
What is Diego
• Rewrite of DEAs in Go à DIEGO
• Supports multiple container image formats
• Supports multiple types of workloads
Distributed System
that Orchestrates
containerized workloads

11. 11PREDIX TRANSFORM
Diego Components
Diego Core
auctioneer
converger
bbs
rep
Dependencies
etcd
garden
CC-Bridge
stager
cc-uploader
nsync
tps
Routing Bridge
route-emitter
Cloud Controller
Go Router
cell

12. 12PREDIX TRANSFORM
Diego Core
cell
Garden Linux/Windows
Garden
rep
executor
brain
auctioneer
converger
database
bbs
etcd
• Platform independent server
and client to manage garden
containers
• Create containers
• Represents a cell
• Manage presence of cell in
other systems like bbs
• Decides optimal placements
• Compare desired and actual
fix discrepancies
• Maintains a real-time
representation of the state
of the Diego cluster
• API for clients
• Datastore for BBS

13. 13PREDIX TRANSFORM
Diego In action
Cloud
Controller
cf push
CC Bridge BBS
auctioneer
executor
Staging and
Running request
LRPS
LRPS
auction
Garden Linux/Windows
Garden
0 1 2
0 1
2
Diego cell
converger
metron-agentDoppler
go-router route-emitter

14. 14PREDIX TRANSFORM
DEA à Diego
Diego Enabler Plugin for CF CLI
cf
enable-­‐diego
<app
name>
cf
disable-­‐diego
<app
name>
cf
has-­‐diego-­‐enabled
<app
name>
cf
diego-­‐apps/dea-­‐apps
[-­‐o
ORG]
cf
migrate-­‐apps
(diego|dea)
[-­‐o
ORG]
[–p
MAX_IN_FLIGHT]
https://github.com/cloudfoundry-incubator/Diego-Enabler

15. 15PREDIX TRANSFORM
New with Diego
ü Route Services
ü .NET apps
ü TCP Routing

16. General Electric reserves the right to make changes in specifications and features, or discontinue the product or service described at any time, without notice or obligation. These materials do
not constitute a representation, warranty or documentation regarding the product or service featured. Illustrations are provided for informational purposes, and your configuration may differ. This
information does not constitute legal, financial, coding, or regulatory advice in connection with your use of the product or service. Please consult your professional advisors for any such advice.
GE, Predix and the GE Monogram are trademarks of General Electric Company. ©2016 General Electric Company – All rights reserved.