The document describes Cloud Foundry Diego, a new container-based runtime for Cloud Foundry that supports running heterogeneous workloads like Docker containers, .NET applications, and tasks on different infrastructure environments. Some key points:
- Diego is an extensible, distributed system that orchestrates and schedules containerized applications and tasks across Linux and Windows container execution nodes.
- It introduces new abstractions like tasks for running single units of work, and long-running processes. These can be distributed across cells for high availability.
- The runtime aims to support running Docker images, .NET applications natively on Windows cells, as well as traditional Cloud Foundry apps, through platform-neutral APIs.
- Developers
3. Open source and 6 commercial distros
Global 2000 focus
Launched 2011
Cloud Native Application Platform
A single API for managing applications on 4 infrastructures
4. 32,000 meetup members
2,100 committers
50+ foundation companies
Major enterprise adoption:
Huawei running 5,000+ apps
GE next-gen Internet of Things platform
Baidu has 700+ CF devs
$ cf scale
6. 1. Designed for openness and extensibility
2. Flexible cloud primitives and processes
3. A platform that can keep promises
What Makes This Runtime Interesting?
10. • Role-based to resource access
• Run code on demand
• Coordinate cross-service configuration
• Route public requests
• Read and write persistent data
• Record internal and external events
• Isolate resources and failures
• Measure performance/health
• Detect and determine failure
• Failure recovery
• Work tomorrow
• Add and remove resources
Runtime Capabilities
11. The Diego Runtime
A distributed system that orchestrates
containerized workloads
18. Run Dockerized applications
Run .NET applications
Run workers and tasks
Develop Cloud Foundry applications locally
Extending the Cloud Foundry Runtime
26. New Workload Types
Tasks
A single unit of work
Runs at most once
N long running instances
Distributed across cells for HA
Monitored and restarted
Long Running
Processes
27. RunAction: run process in container
DownloadAction: fetches and extract archive
UploadAction: POST file from container to URL
ParallelAction: run multiple actions in parallel
SerialAction: runs multiple actions in order
EmitProgressAction: wraps action and logs progress
TimeoutAction: wrap action and fail if timed out
TryAction: wrap action and ignore errors
Workload
Primitives
30. How can I develop Cloud Foundry
applications on my local machine?
31.
32. • Single-tenant
• Everyone is ‘cluster root’
• Wide-open networking
• Not all components are HA
• Red-black upgrades
• No data services
• Multi-tenancy with resource quotas
• Role-based access control
• Application security groups
• Highly-available components
• Zero-downtime, rolling upgrades
• Backing data service orchestration
Repackaging the Runtime
Production usage
with 20+ VMs
Local
development on a
single host
33.
34. 10,000 “real app” container instances (100 per cell)
4,000 concurrent tasks
4,000-instance LRPs
Scalability
Runtime testing with tens of thousands of containers:
Second, the original Cloud Foundry DEA runtime was only focused on Linux workloads.
You need .NET applications on Windows?
How much of the architecture would I need to redo?
Turns out the major change to add Windows support is to implement a cell and Garden container backend in Windows. You can build a distribute .NET workloads as MSIs and have a Windows server provide the same logging, routing and health monitoring