DevOps

DevOps. IT-Buzzword als auch Kunstwort, bestehend aus Entwicklung (Development) und Betrieb (Operations). DevOps verspricht ein enormes Potenzial für Softwareunternehmen: kürzere Entwicklungszyklen von Releases und Funktionen, dabei Reduzierung der Kosten von Auslieferung und Instandhaltung, verbesserte Qualität, Bugs werden schneller identifiziert, weniger Ausfälle als auch kürzere Durchlaufzeiten. Und zusätzlich der Kern der Philosophie: ein besseres Verständnis zwischen den Entwicklern und dem Betrieb - raus aus dem Silo, weg mit dem “Blame Game” und hinein ins abteilungsübergreifende Team Building und ins echte “Wir”.

Das hört sich fantastisch an, oder? Was wirklich dahinter steckt und wie auch dein Unternehmen davon profitieren kann, beleuchten wir in folgenden Abschnitten:

Tell us what you are working on and how a DevOps freelancer can support you!

Thank you for your message! We will get back to you as soon as possible.
An error occurred! Please try again.

Was ist DevOps?

Laut der aktuellen IDC-Studie “DevOps in Deutschland 2020” geben 77% der IT-Entscheider deutscher Unternehmen an, dass DevOps-Prozesse bei ihnen im Einsatz sind. Andere sprechen davon, dass sich DevOps langsam zum Industriestandard entwickelt. Dabei ist die Welt von DevOps ebenso aufregend wie überwältigend. Es gibt eine Vielzahl von Tools für jeden Teil des Zyklus: Source Code Management, Build, Test, Deploy, CI/CD, Security und mehr. Wer blickt da noch durch im DevOps-Jungle?
 
Quelle: SourceClear

Zunächst sei gesagt: DevOps erfindet das Rad nicht neu, sondern greift auf bekannte Ansätze zurück. Agile (Operations) und Continuous Delivery zum Beispiel.
Der große Unterschied und das Novum ist hier die Ergänzung um die zwischenmenschliche Komponente und die Auflösung der unsichtbaren Mauer, die zwischen der Entwicklungsabteilung und dem Betrieb besteht. Dabei priorisiert DevOps Mitarbeiter über Prozesse, und Prozesse über Werkzeuge (Tools). DevOps ist auch kein Framework, sondern eher eine Kultur. Eine Kultur, die Zusammenarbeit, Vertrauen, Eigenverantwortung (Ownership) und kontinuierliche Verbesserung schafft. Eine Kultur, die den Entwicklungsprozess in einer holistischen Weise sieht - und sämtliche involvierten Mitarbeiter sind Teil dieser Kultur.

Wobei kann ein DevOps-Freelancer dich unterstützen?

Ein DevOps-Engineer spielt eine wesentliche Rolle bei der Integration von Projektfunktionen und Ressourcen über den gesamten Produktlebenszyklus hinweg - von der Planung über die Erstellung, das Testen und das Deployment bis hin zum Support.

Dementsprechend umfangreich sind die Aufgaben eines DevOps Engineers:
  • Planung der Teamstruktur, der Aktivitäten und der Beteiligung an Projektmanagement-Aktivitäten
  • Implementieren verschiedener Entwicklungs-, Test- und Automatisierungswerkzeuge sowie Gestaltung der IT-Infrastruktur
  • Definieren und Festlegen von Entwicklungs-, Test-, Release-, Update- und Support-Prozessen für den DevOps-Betrieb
  • Verwaltung von Stakeholdern und externen Schnittstellen
  • Einrichten von (DevOps-)Tools und der erforderlichen Infrastruktur
  • Auswahl und Einsatz von geeigneten CI/CD-Tools (Continuous Integration / Continuous Delivery), z.B. Microsoft Azure Pipeline
  • Entwicklung und konstante Bereitstellung (CI/CD-Pipeline)
  • Technische Fähigkeit, den im Projekt entwickelten Softwarecode zu überprüfen, zu verifizieren und zu validieren
  • Techniken zur Fehlerbehebung und Behebung von Bugs
  • Überwachen von Prozessen während des gesamten Lebenszyklus auf ihre Einhaltung als auch Erstellung neuer Prozesse zur Verbesserung und Minimierung von Ineffizienz (DevOps Waste, Wastage)
  • Förderung und Aufbau automatisierter Prozesse, wo immer sie möglich sind (DevOps Automation)
  • Identifizieren und Einsetzen von Cybersecurity-Maßnahmen durch kontinuierliche Schwachstellenbewertung und Risikomanagement (DevOpsSec)
  • Vorfallsmanagement und Ursachenanalyse
  • Koordination und Kommunikation innerhalb des Teams als auch direkt mit Kunden
  • Mentoring und Anleitung von Teammitgliedern
  • Überwachung und Messung von Kundenerfahrung (Customer Experience) und der KPIs (Key Performance Indicators)
  • Regelmäßige Berichterstattung (Monitoring) über den Fortschritt an das Management und den Kunden

Find a DevOps freelancer!

Send us details about who you are looking for and we will get back to you within a few hours!

Thank you for your request! We will review it and get back to you as soon as possible!
Uh-oh, something went wrong. Please try again!

Wie starte ich ein DevOps-Projekt?

DevOps beginnt vor dem Code. Da es sich hier um eine Kultur handelt, muss zunächst der kulturelle Wandel im Unternehmen eingeleitet werden. Das macht man nicht mal eben nebenbei. Die Eingliederung von DevOps-Themen ist die hohe Schule des gesamten Prozesses. Hier ein paar Tips einer möglichen Strategie:
  • Fang klein an. Rom wurde auch nicht an einem Tag erbaut. Finde das Team, das sich kontinuierlich mit Problemen und unerreichten Zielen auseinandersetzt, also diejenigen, die am empfänglichsten dafür sind, eine andere Arbeitsweise in Betracht zu ziehen.
  • Zeige schnelle und frühe Erfolge, um Skeptikern und Kritikern den Wind aus den Segeln zu nehmen. Erkläre kontinuierlich, welche Probleme DevOps löst und welcher Wert geschaffen wird. Mit dieser Taktik erweiterst du DevOps nach und nach auf andere Bereiche deiner Organisation.
Oder du stürzt dich auf ein neues Produkt oder Service (Greenfield product/service) mit einem separaten Team, das (vor allem anfangs) in Isolation arbeiten kann. Auch hier ist ein schneller und früher Erfolg das Ziel, um eine Argumentationsbasis für DevOps zu schaffen. Ist erstmal die Grundlage vorhanden, wird der DevOps Betrieb von Experten durchgeführt. Damit stellt man sicher, dass man in den Genuss der eingangs erwähnten Vorzüge kommt, und hebt die Softwareentwicklung auf das nächste Level - wovon letztlich alle Beteiligten profitieren.

Wann ist DevOps nicht die richtige Wahl?

Oder besser gefragt: Wann ist es zu früh für DevOps? Wie eben erläutert wurde, muss eine Grundlage für DevOps-Prozesse vorhanden sein oder erstmal geschaffen werden.

Unpassend ist DevOps für die Unternehmen, die proprietäre Software nutzen und auf dem eigenen Systemen betreiben - dadurch hat man entsprechend kaum eine Chance, die agile Entwicklung jener Systeme zu beeinflussen. Eine Überprüfung und Optimierung der bisherigen IT-Prozesse ist an dieser Stelle sinnvoller. Die Cloud im Unternehmen ist ebenfalls sehr hilfreich für DevOps - allerdings kein Muss dafür. Weiterhin helfen folgende Fragen bei der Entscheidung zu DevOps:
  • Was muss in welchem Umfang von Entwicklung und Betrieb agil gesteuert als auch verwaltet werden?
  • Kosten-Nutzen-Prüfung - Wie viel darf die Umsetzung kosten? 
  • Kann man die Anwendungen vollständig zu automatisieren oder ist ggf. der Aufwand zu hoch?

Oder zusammengefasst: Muss es agil im Sinne von DevOps sein und rechnet sich das?

Alternativen zu DevOps

Da DevOps nicht eine einzelne Technologie abdeckt, sondern einer Philosophie gleicht mit einer ganzen Landschaft von Systemen, Tools, Prozessen und Denk- und Lösungsansätzen, gibt es nicht wirklich eine Alternative als den bisherigen nicht-agilen oder rein agilen Weg in der Softwareentwicklung. 

Quelle: Twitter @anjanijoshi13

Zu erwähnen wäre an dieser Stelle NoOps (= No Operations = kein Betrieb). Dieser Ansatz basiert auf DevOps und ist die konsequente Weiterentwicklung von davon (also keine Alternative). Wie es der Name offensichtlich verrät, fällt hier der Betrieb vollständig weg. Der NoOps-Ansatz unterliegt dem oft verwendeten Mantra „You build it, you run it!“, bei dem der Software-Entwickler sein Produkte sowohl entwickeln als auch selbst betreiben muss. Diese zusätzliche Last ist nur mit Hilfe der richtigen Mittel als auch ausgeklügelten Automation möglich, in der Software praktisch “auf Knopfdruck” erstellt, getestet und auch deployed wird. Beim radikaleren Schritt zu NoOps ist jedoch das größte Hindernis die Kompatibilität zu bestehenden Anwendungen, denn dieser Ansatz muss auf bestehende PaaS-Lösungen (Platform as as Service) passen. Bestehende, "alte" Software ist nicht für einen NoOps Ansatz entwickelt worden, und müsste komplett neu geschrieben werden.