2. Why containerize
Windows .NET
Workloads
Driving Business Outcomes
● OS Versioning
● Operational efficiency / Patching
● Reduce licensing costs
● Simplify Scalability
● Improve Availability
● Increase Development Agility
3. Cloud Native Journey
Cloud Native
Cloud Resilient
Cloud Friendly
Cloud Ready
● Microservice Architecture
● Function/Event/API first design
● Design for failure
● Proactive testing for failure
● Apps are unaffected by
dependent service failure
● 12 Factor apps
● Horizontally scalable
● Leverage platform for HA
● No file system requirements
● Containerized
● Platform managed addresses and ports
● Consume Platform services
● Integrated Metrics and
Monitoring
● Cloud agnostic runtime
implementation
4. Windows
Containers
Win-C Standard Containers
● Officially supported in Windows 2016 – We been
doing containers since Windows 2012R2
● Win-C container standard
● Support for Kubernetes deployed containers in
Windows 2019 (Build 1903+)
● Containers need to be rebuilt for major version
releases of Windows
● Hyper-V isolation for kernel-mode isolation for
enhanced security
● Implemented using Microsoft Container APIs
5. What fits in a
Windows
Container?
Supporting legacy applications
● Minimal operating system
● Full Windows install (C:Windows)
● Structured file system (C:, C:Program Files)
● Registry
● .NET runtime
● Different .NET runtimes side by side - host OS is
neutral to the version(s)
● Patch host operating system with no regard to
apps within
6. Writing Twelve Factor ASP.NET Applications
● Avoid in-process session state*
● For ASP.NET override MachineKey in web.config and on ASP.NET Core avoid
persisting keyring to filesystem*
● On ASP.NET avoid environment specific configuration in web.config
● Avoid Integrated Windows Authentication
● Avoid the GAC
● Avoid custom IIS handlers
● Avoid anything that uses the Windows registry
● Avoid libraries that depend on DPAPI
● Avoid using local disk for storing application state*
● Avoid using any Windows specific or disk-based logging*
● Avoid any 32-bit specific libraries or libraries that can’t be bin deployable*
● Platform dependent naming conventions - i.e. environment variables
● MSI deployed libraries requiring host level access
7. Benefits of PCF
for .NET Apps
How Pivotal Application Service
(PAS) and PAS for Windows
evolves the .NET DevOps
experience.
● Deploy .NET Core or .NET Framework apps.
● For .NET Framework, uses Windows Server Containers,
first delivered with Windows Server 2016.
● Automatically builds a full, OCI-compliant container
image, supplying key .NET, IIS, and Windows features.
● Transparently patches all .NET applications with
updated container base images from Microsoft, live in
production with no downtime.
● Scale out .NET running apps, manually or based on CPU
load or traffic.
● Deploy Windows Updates in rolling fashion to all live
Windows VMs with BOSH.
● Provide .NET debugging and troubleshooting features.
8. Deploy source code
that the platform
containerizes for
you
or
Deploy container
images that you
build yourself
push source
code
Developer
Cloud Foundry
Cloud Controller
triggers staging
Diego creates
container
Diego mounts
root file system
Diego lays down
buildpack,
source code
Diego builds and
uploads droplet
Diego schedules
containers onto
Cells
Running app!
9. Focus on developer productivity
Build all things .NET... Run all things .NET...
✓ .NET Full Framework/.NET Core
✓ Early application lifecycle and
evolving CI/CD pipelines
✓ Limited testing coverage
✓ Frequent changes to code
✓ Complex deployments with many
service dependencies
✓ On-demand services
✓ Multi-tenant deployments
✓ High-compliance requirements
✓ .NET Core
✓ Mature application lifecycle and
CI/CD pipelines
✓ Comprehensive testing coverage
✓ Infrequent changes to code
✓ Self contained application
deployments
✓ Service deployments
✓ Customer hosted deployments
✓ Flexible compliance requirements
“Use the right tool for the job”
12. Externalized Configuration
• Built on ASP.NET Core Configuration & Options extensions
• https://github.com/aspnet/Configuration
• https://github.com/aspnet/Options
• https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration
13. Dealing with Failures
• Stop sending requests to a failing
service (allowing time to recover)
• Fail gracefully by implementing fall-
back behavior
• Open Circuit = Failed method
• Closed Circuit = Successful method
14. Dealing with Failures
Implement HystrixCommand
RunAsync() Method
Runs every time, in own
thread
RunFallbackAsysnc() Method
Only run when RunAsync() fails
(Circuit is now open)
19. Here is my .NET code
Run it in the cloud for me
I do not care how
Editor's Notes
How Cloud Foundry supports containers as a deployment unit (vs buildpacks)
When staging complete the output consists of metadata from the buildpack and a droplet, which is an archive of files that should be layered on top of the Root Filesystem. Cloud Controller asks Diego to launch instances of the application. Diego does this by scheduling containers on the Cells.
File System: The running application container contains the Root Filesystem and a copy of the application droplet.
Metadata: Cloud Controller provides Diego with metadata to launch the correct process within the Cloud Foundry Container Environment and to monitor the process’ health.