Describing the Lexware Download Manager on Azure serving 15 Million Downloads

1. DevOps in der Praxis
Entwicklung und Betrieb einer Anwendung in Azure
Helmut Strasser, Karsten Gaebert
DevOps MeetUp 20.10.2015

2. 20.10.2015Seite 2
FDS
Karsten Gaebert, Helmut Strasser
Agenda
• Historie
• Projektziele
• Technische Umsetzung
• Deployment
• Test
• Betrieb
• Fazit Azure, Dev, Ops

3. 20.10.2015Seite 3
FDS
Karsten Gaebert, Helmut Strasser
Die Lösung
Microsoft Azure

4. 20.10.2015Seite 4
FDS
Karsten Gaebert, Helmut Strasser
Partnerprogramm
• 2012 - Start Azure Partnerprogramm mit Microsoft
• Ziele:
• Anwendungen auf Azure entwickeln
• Traffic + Umsatz generieren
• Premiumsupport durch Microsoft nutzen

5. 20.10.2015Seite 5
FDS
Karsten Gaebert, Helmut Strasser
Wo ist das passende
Problem?

6. 20.10.2015Seite 6
FDS
Karsten Gaebert, Helmut Strasser
Projekt Downloadmanager
Themen + Ziele
•Distribution und Aktualisierung der Lexware Desktopprodukte
•Hohe Bandbreite bei Lastspitzen
•Kostensenkung beim Traffic
•Anbindung an Shop -> Downloads von Produkten, eBooks etc.
•Integration in die Haufe Systemlandschaft
Timeline
•Projektstart Mitte 2012
•Livegang V1 (POC) im Januar 2013
•Ständige Weiterentwicklung seit März 2013

7. 20.10.2015Seite 7
FDS
Karsten Gaebert, Helmut Strasser
Teamaufstellung
• Projektmanagement
• Entwicklungsteam
• QK-Team
• Betriebsteam
=> Aufwandsabschätzung
Ergebnis
Kosten zu hoch
Entwicklungsdauer zu lange
Risiken zu hoch
Und jetzt?

8. 20.10.2015Seite 8
FDS
Karsten Gaebert, Helmut Strasser
„DevOps“ Ansatz
• QK ersetzen durch automatisierte Tests
• Betrieb im Entwicklungsteam
• Monitoring mit Integrationstests
• Vollständige Testabdeckung der businesskritischen Funktionen
• Tracking aller relevanten Ereignisse und Zustände
Team
• Projektleitung, Consulting, Businessanalyse: 1 FTE
• Entwicklungsteam + Architekt: 1-3 FTE
• Betriebsteam: -
• QK: -

9. 20.10.2015Seite 9
FDS
Karsten Gaebert, Helmut Strasser
Konsequenzen
• Anwendung muss „testbar“ entwickelt werden
• Viel Aufwand in die Testautomatisierung investieren
• Entwickler erstellen Tests parallel zu den Features
• Test laufen regelmäßig über das Produktivsystem
• Aufwände für die Transition zu IT und QK werden in Automatisierung investiert
• Verantwortung für Betrieb liegt im Entwicklungsteam
• Selbstverständnis für den gewählten Ansatz bei allen Beteiligten

10. 20.10.2015Seite 10
FDS
Karsten Gaebert, Helmut Strasser
Features
• Verwaltungsportal für:
• > 10.000 Produktuploads + Aktualisierungen
• 1800 eBooks
• Rest-API für Downloadlinks
• Geschützte Downloadlinks (Klickzahl und Laufzeit)
• Freigabeworkflow für neue Produktversionen
• Skalierung bei Lastspitzen
• Echtzeittracking
• Installations- und Aktualisierungstests für neue Uploads
• Personalisierte Wasserzeichen

11. 20.10.2015Seite 11
FDS
Karsten Gaebert, Helmut Strasser
FDS
TFS Build
SAP XI
Support
Upload
D
ow
nload

12. 20.10.2015Seite 12
FDS
Karsten Gaebert, Helmut Strasser
Cloud Service
FDS
Queue
Tracking Cloud Service
Tracking
Cloud Service Cloud Service Cloud Service Cloud Service
Queue
Install
Cloud Service
Install
Virtual
MachineVirtual
MachineVirtual
Machine

13. 20.10.2015Seite 13
FDS
Karsten Gaebert, Helmut Strasser
Tracking
 Serverseitiges Tracking
 Angebunden über Queue
 Echtzeit und Statistik
 Feedback über Events
 Beliebige Ansichten
 ALLES tracken

14. 20.10.2015Seite 14
FDS
Karsten Gaebert, Helmut Strasser
Monitoring
• Nagios als führendes Tool
• Überwachung der Bandbreite (Downloadgeschwindigkeit) aller Storages
• Permanente Integrationstests über alle Inhalte + APIs
• Überprüfung der ausgelieferten Dateiversionen
• Überprüfung aller verfügbaren Inhalte
• Abgleich mit dem Shop

15. 20.10.2015Seite 15
FDS
Karsten Gaebert, Helmut Strasser
Dev (Implementierung)
• .NET/C# in Visual Studio
• Azure SDK
• Azure Emulator für lokale Entwicklung und Tests
• WorkerRole und CloudService Template (PaaS)
• Komponenten
• Azure SQL Datenbank
• Workflows (WF)
• Azure Queues für die Entkoppelung (z.B. Tracking)
• …
• Mehrere entkoppelte Services (Endpunkte)
• Unabhängige Deployments
• Unabhängige Skalierung
• CI

16. 20.10.2015Seite 16
FDS
Karsten Gaebert, Helmut Strasser
Deployments
• Build erzeugt fertige Azure Cloud Services (package)
• Lauffähig nur in Azure
• Deployment
• über Azure Management-Portal
• Visual-Studio
• Powershell (Automatisierung)
• Mehrere Environments
• Dev
• Integration (Stabilisierung)
• Production
-> nur ein Branch?!

17. 20.10.2015Seite 17
FDS
Karsten Gaebert, Helmut Strasser
Test
• Production- und Stagingumgebung in Azure (pro cloud service)
• Test auf Integration – Umgebung (Konfigurationsmangement)
• Lasttests bei neuen Features und geänderten Konfigurationen
• Integrations- und Freigabetests über das Monitoring

18. 20.10.2015Seite 18
FDS
Karsten Gaebert, Helmut Strasser
Releasefreigabe
• Blue/Green - VIP Swap
(Konfiguration muss stimmen)
• Keine Downtime
• Rollback sofort möglich
Betrieb
• Überwachung im Azure Portal (RAM, CPU etc.)
• Überwachungs-Scripte
• Nagios
• Backup
• Aufräumen
• u.v.a.m

19. 20.10.2015Seite 19
FDS
Karsten Gaebert, Helmut Strasser
Skalierung
• Benachrichtigung bei konfigurierbaren Ereignissen (z.B. CPU-Last größer 80%)
• Autoskalierung abhängig von CPU Last, Queue Einträgen etc.
• Manuell (Azure Portal)

20. 20.10.2015Seite 20
FDS
Karsten Gaebert, Helmut Strasser
Fazit - Azure
• Azure als Plattform von Anfang an sehr stabil
• Ständige Weiterentwicklung + neue Services durch Microsoft
• Einfaches Deployment (PAAS)
• Nachteil: Starke Bindung an die Plattform, Wechsel ist aufwändig
• Kosten nicht sofort sichtbar
• Sehr hohe Flexibilität (neue Server, Testumgebungen etc.)
• „SDK Version 1.8 is not supported any more – Please upgrade“
• Microsoft Support über Tickets aus dem Portal funktioniert gut
(5 Klicks, Mail aus Indien oder Anruf aus München – je nach Dringlichkeit)
• Gute Dokumentation zu Azure von MS und große Community mit Lösungen

21. 20.10.2015Seite 21
FDS
Karsten Gaebert, Helmut Strasser
Fazit - Dev
• Bei der Featureentwicklung auch die Testbarkeit im Fokus behalten
• Tests zusammen mit der Anwendung weiterentwickeln
• Mindestens 20% der Ressourcen für Automatisierung einplanen
• Laufende Integrationstests auf Production
(hilft auch beim blue/green swap)
• Als Entwickler wird man auch zum Operator
• Vorteil: keine Reibungsverluste zu einer IT-Abteilung
• Nachteil: Weniger Zeit zum Entwickeln, SSL Zertifikate etc.

22. 20.10.2015Seite 22
FDS
Karsten Gaebert, Helmut Strasser
Fazit - Ops
• Sehr viel Test-Automatisierung (CI) notwendig, damit
man sicher sein kann, dass die neue Version funktional stabil ist
• Infrastruktur ist eine Black Box
(z.B. Lasttests aus Kroatien werden geblockt, aus D nicht)
• CI langfristig notwendig (am Besten gleich zu Anfang)
• Verantwortung für Betrieb und Dev in einem Team. Keine „Schuldzuweisungen“
und unklare Verantwortungen
• Keine langen Abstimmungen zwischen den Teams
• Problem 24x7 allerdings noch ungelöst

23. 20.10.2015Seite 23
FDS
Karsten Gaebert, Helmut Strasser
Ende
Danke für eure Aufmerksamkeit!