1) The document discusses managing short-lived Kubernetes deployments and outlines the steps taken to implement a DevOps process using Kubernetes and Azure Container Services.
2) Key priorities included enabling CI/CD, automatic provisioning, and minimizing the need for operations work.
3) The solution implemented Kubernetes with Azure Container Services using Azure as the IaaS provider to enable on-demand development and test environments identical to production.
4. Strategic move
to containers Modular
Architecture
Without Container
Experience
Current Occupation – A Cloud Journey
Hosted with Hoster
Long Release
cycles
(LOTS of) Manual
Work for Releases
Little Operations
Insight
Error tracking
very difficult
Non-Parity
Dev/Test/Prod
(Cost!)
Legacy Web App
(Java based)
10. Steps to DevOps Happiness (for us)
Provisio
n
Deploy CI/CD
Weekly for Production, Daily for Dev/Test
Ship when ready!
11. But… Why?
Target
“No-Ops”
No long-running
systems
Enable validation of
3rd Party component
upgrades
Incremental
changes
Practice Disaster
Recovery Daily
100% Reproducible
Deployments
On-demand Production
Identical Environments
14. Full Provisioning
Create backup
Provision new
infrastructure
• From
backups
• Same as
disaster
recovery!
Deploy
components
• Using
deployment
pipelines
• Partly
parallelized
Top level DNS
switch
• Using DNS
traffic
manager
Destroy old
infrastructure
• If tests
succeed
15. Persistence Options
Roll your own persistence Persistence “as a service”
Self managed VMs (incl. NFS) Managed Disks
(AWS EBS, Azure Managed Disks)
DBaaS (many options)
Files as a service
(AWS EFS, Azure
Files)
Gluster/Ceph FS (cluster)
18. Example – SQL Schema Update
Create backup
Provision new
infrastructure
Deploy
components
Top level DNS
switch
Destroy old
infrastructure
Test/Validate
20. -as-a-Service
Less Complex
No Operations Overhead
Supports A+B, or AB?
If not: Can I live without Prod
Data in Dev/Test Envs?
Do I trust Service Provider
to live up to SLA?
In case of
What can I do?
25. NFS Storage/Postgres Storage
• Backup – Cloning disks from running system
• Restore – Cloning from backups
• Very much a transient technology!
• But it works…
• Moving to DBaaS (e.g. Cosmos DB) over
time
27. Conclusion and Takeaways
k8s Ops possible
as a Team
Requires full (test)
automation
Team dedication Rethinking ops is
challenging
No Silver Bullet
Assess your requirements
31. Persistence problems and possible
solutions
Data Type Solution Technology Backup/Restore Complexity
Plain Files NFS AB Low
CephFS/GlusterFS A+B High
SQL Database Azure SQL Server A+B Medium
Azure Postgres-aaS AB Low
AWS RDS for Postgres AB Low
NoSQL Azure Cosmos DB A+B Medium
AWS DynamoDB A+B (via tools) Medium
32. Integration
& e2e Test
Build &
Unit Test
Docker
Image
Deploy
Building blocks of CI/CD pipelines
• E.g., Blue/Green
• Rolling Updates
• Also used for initial
deployment
33. Incremental Frontend Deployment
Merge feature to
master
•After code
review
•Including test
suite changes
Build master
branch
•Includes unit
testing
•First integration
tests
Deploy to
integration system
•Run integration
tests
•Rollback if failing
Deploy to
Production
•Run e2e
integration tests
•Rollback if failing
34. Incremental Backend Deployment
Merge feature to
master
•After code
review
•Including test
suite changes
Build master
branch
•Includes unit
testing
•First integration
tests
Deploy to
integration system
•Blue/Green with
integration tests
Deploy to
Production
•Blue/Green with
integration tests
Editor's Notes
Remedies for our woes?
Yes-ish, but comes with a new set of problems!
Prereq: We must make it without extensive Ops/IT support
Enabling CI/CD (even if not yet implementing)
Decoupling deployments
Automatic Test strategy
Automated Provisioning of environments
Development,
Testing, and
Production
Application Insight
Logging
Monitoring
Alerting
Minimize OPs
As resilient as possible (tradeoff!)
As little ops as possible (”self healing”)
Side track: HR topics on taking over operations
Wahl Azure weil großen Einsatz für Kubernetes
Grund für Kubernetes könnte eigener Vortrag sein – wir sind bisher glücklich mit der Entscheidung
Guter Support, Haufe bereits MS-Partner
Aufsetzen eines Cluster sehr einfach, voll automatisierbar
Trotzdem: Ops-Verantwortung beim Team, auch das eine bewusste Entscheidung
Prereqs: Linux-Erfahrung im Team, keine Angst vor Komplexität
Genauso valide Wahl
Weniger Erfahrung im Team mit AWS als mit Azure