DevOps Meetup Freiburg - DevOps in Practice

718 Aufrufe

Veröffentlicht am

Describing the Lexware Download Manager on Azure serving 15 Million Downloads

Veröffentlicht in: Software
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
718
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
12
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

DevOps Meetup Freiburg - DevOps in Practice

  1. 1. DevOps in der Praxis Entwicklung und Betrieb einer Anwendung in Azure Helmut Strasser, Karsten Gaebert DevOps MeetUp 20.10.2015
  2. 2. 20.10.2015Seite 2 FDS Karsten Gaebert, Helmut Strasser Agenda • Historie • Projektziele • Technische Umsetzung • Deployment • Test • Betrieb • Fazit Azure, Dev, Ops
  3. 3. 20.10.2015Seite 3 FDS Karsten Gaebert, Helmut Strasser Die Lösung Microsoft Azure
  4. 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. 5. 20.10.2015Seite 5 FDS Karsten Gaebert, Helmut Strasser Wo ist das passende Problem?
  6. 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. 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. 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. 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. 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. 11. 20.10.2015Seite 11 FDS Karsten Gaebert, Helmut Strasser FDS TFS Build SAP XI Support Upload D ow nload
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. 20.10.2015Seite 23 FDS Karsten Gaebert, Helmut Strasser Ende Danke für eure Aufmerksamkeit!

×