Cloud, Releases und Betrieb: Praxiserfahrung mit Azure und AWS.
Ich habe hauptsächlich mit Azure und AWS gearbeitet und in geringerem Maße mit Google Cloud. Mein Beitrag hängt davon ab, wie das Projekt organisiert ist: Anwendungsentwicklung und Integration, Arbeit mit einem Plattformteam oder direkte Verwaltung von Umgebungen und Releases.
AzureAWSTerraformRelease-PipelinesÜberwachung
Cloud-Plattformen
Ich arbeite an cloudgehosteten Anwendungen und Integrationen, mit Verantwortlichkeiten, die je nach Projekt variieren.
Meine bedeutendste Erfahrung liegt bei Azure und AWS. Ich habe Anwendungs- und Infrastrukturservices genutzt, um Systeme zu verbinden, Daten zu verarbeiten und das Verhalten von Anwendungen beobachtbar zu machen. In größeren Projekten verwalten Spezialisten die Plattform; in anderen übernehme ich auch Konfiguration, Releases und Überwachung der Umgebung.
Zwei Arbeitskontexte
01
Plattformen mit eingeschränktem Produktionszugriff
In Projekten mit strengen Sicherheitsanforderungen verwaltet ein dediziertes Team die Produktion.
Wenn ich keinen direkten Zugriff auf die Produktionsumgebung oder Datenbanken habe, sind Protokolle und Überwachungstools entscheidend, um Anomalien zu erkennen und ihre Ursachen zurückzuverfolgen. Dies erfordert sorgfältiges Protokollieren und Nachverfolgbarkeit ab der Entwicklungsphase.
Bei einigen Projekten habe ich bei der Vorbereitung von Konfigurationen mit Terraform geholfen, damit Infrastrukturänderungen versioniert, überprüft und mit dem Release-Prozess koordiniert werden konnten.
Mein Beitrag
Untersuchung von Problemen anhand von Protokollen und Überwachung
Anwendungsprotokollierung und Nachvollziehbarkeit
Zusammenarbeit mit den für die Plattform zuständigen Teams
Infrastrukturkonfiguration mit Terraform, wo geeignet
02
Direkte Verwaltung von Umgebungen und Releases
Bei anderen Projekten bin ich stärker in die Betriebsabläufe eingebunden, von der Entwicklung bis zur Produktion.
Ich habe Release-Pipelines konfiguriert, einschließlich solcher, die mehrere verschiedene Dienste wie Anwendungen, CRM und Service Bus aktualisieren. Ich habe in Entwicklungs-, Test-, Staging- und Produktionsumgebungen gearbeitet, Dienste überwacht und Anomalien untersucht.
Je nach Projekt umfassten Integrationen und Datenflüsse Azure Functions, Service Bus und Stream Analytics sowie Netzwerkkomponenten wie Azure Firewall und Application Gateway. Ich habe auch Entra ID für die Identität und Azure Synapse für Datenworkloads genutzt.
Aktivitäten und Dienste
Pipelines und Releases in mehreren Umgebungen
Überwachung und Fehlerdiagnose
Integration: Azure Functions und Service Bus
Daten: Stream Analytics und Azure Synapse
Netzwerk und Identität: Firewall, Application Gateway, Entra ID
Entwicklungs- und Freigabeprozesse
Tools sind nützlich, wenn sie zur Arbeitsweise des Teams passen.
Ich habe Azure DevOps, Jira und SonarQube in sehr unterschiedlichen Organisationen eingesetzt: von Teams, die Work-Items als gemeinsame Notizen nutzen, bis hin zu strukturierten Agile-Programmen, die mehrere Teams umspannen. Ich habe sowohl häufige Freigaben in Testumgebungen als auch Tests am Ende eines Sprints erlebt. In einigen Fällen half ich bei der Konfiguration von Tools und Pipelines; in anderen Fällen trat ich in etablierte Prozesse ein und arbeitete mit den dafür zuständigen Teams zusammen.
Ich beschreibe, wie ich Verantwortung in einem Projekt übernehme, ausführlicher auf der Arbeitsweise Seite.
Verwandte Erfahrungen
Drei Projekte zeigen unterschiedliche Kontexte und Rollen.
C-01 — Managed Services für Unternehmen: Backend-Entwicklung und technische Koordination auf einer Cloud-Plattform mit Microservices, Messaging und IoT-Daten.
C-05 — Finanzen: .NET-Anwendungen auf AWS und automatisierte Releases mit Terraform.