Der Blog

6 DevOps-Fallstudien

von Chris Riley 26. April 2016 | 5 Minuten Lesezeit

Zugegeben, vor zwei Jahren war ich ein wichtiger Mitwirkender am DevOps-Rummel mit Gesprächen, die in der Bewegung rund um Kultur, Prinzipien und Ziele wurzelten. Und obwohl all diese Elemente von DevOps-Umgebungen wichtig sind, habe ich festgestellt, dass die größte Herausforderung jetzt ein Mangel an Verständnis dafür ist, warum DevOps von Vorteil ist. Es geht darum, die Räder in Gang zu bringen oder einfach den nächsten Schritt zu machen. Der beste Weg, den Weg zur Veränderung zu beginnen, besteht darin, sich die Unternehmen anzusehen, die bereits große Fortschritte bei der modernen Softwarebereitstellung gemacht haben. Es gibt kein DevOps, das für alle passt, aber es gibt vorhandene Implementierungen, die eine Fundgrube an Tipps und Tricks und manchmal sogar direkte Implementierungsstrategien für enthalten robuste DevOps .

Hier sind sechs DevOps-Implementierungen, bei denen es meiner Meinung nach darum ging, Methoden in Ergebnisse umzusetzen (mit Präsentationen von jedem Unternehmen in der Liste):

Docusign

Die Entwicklung von Docusign war schon immer agil. Aber der nächste Schritt in Richtung DevOps-Prozesse war nicht so einfach. Aufgrund der Art ihres Geschäfts (Verträge und Unterschriften) sind Dinge wie kontinuierliche Integration und Bereitstellung zweifellos eine ernsthafte Herausforderung. Sie leben und sterben von Transaktionen, nicht von Geldtransaktionen, sondern vom Austausch von Unterschriften und Genehmigungen. Wenn etwas schiefgehen und beispielsweise eine Genehmigung falsch zugeordnet würde, wäre dies ein ernsthaftes Problem. Um die moderne Entwicklungsgeschwindigkeit zu unterstützen, nutzen sie ein sehr cooles Tool namens Anwendungsmock – in diesem Fall ein Mock für ihre interne API. Das Tool bietet einen Mock-Endpunkt und liefert Mock-Antworten. Sie können dies mit dem Vorfallmanagement kombinieren und die Anwendung vor der Veröffentlichung mit Simulationen testen, die dem realen Austausch sehr nahe kommen. Slideshare anzeigen »

Forter

Ähnlich wie Docusign ist die Anwendung von Forter auf schnelle und sensible Transaktionen angewiesen. Forter legt großen Wert auf die Selbstheilung von Problemen, die durch ein starkes Vorfallmanagement vorangetrieben werden. Sie haben eine gute Architektur für die Behandlung aller Probleme aufgebaut. Sie verfügen über einen Filterprozess, um häufige Probleme zu identifizieren, um zu versuchen, sie automatisch zu lösen, oder um sie später zu referenzieren und in ihr System zu integrieren. Dieser Fokus nicht nur auf die Lösung von Problemen, sondern auch auf deren Vermeidung in der Zukunft wird es ihnen ermöglichen, ihre Lieferkette zu verbessern. Slideshare anzeigen »

Turnitin

Turnitin ist eine Plattform, die Schülern hilft, ihre Schreibfähigkeiten zu verbessern. (Das hätte ich in der Schule gut gebrauchen können.) Ich habe viel von Samantha, einer Datenbankmanagerin bei Turnitin, gelernt, als sie in ihrer Präsentation zeigte, wie man die Datenbankleistung in ihrer Anwendung durch Überwachung verbessern kann. Ich bin kein DBA, aber für jede Anwendung ist es wichtig, normale und anormale Spitzen erkennen, die Backend-Antwortzeit überwachen und so schnell wie möglich auf anormale Spitzen reagieren zu können. Slideshare anzeigen »

Gengo

Gengo ist eine Übersetzungsplattform. Sie wird sowohl von kommerziellen Endbenutzern als auch von Entwicklern zur Integration in ihre Anwendungen verwendet. Sie vertreten einen ähnlichen Standpunkt wie Forter, wo sie sich für intelligentes Monitoring entschieden haben, nicht nur um bessere Produktionsanwendungen zu erreichen, sondern auch um größere Ziele zu erreichen, wie etwa dem Team mehr Zeit für Innovationen zu geben. Insbesondere aufgrund der verteilten Natur ihrer API können Probleme, die als Ergebnis eines Updates auftreten, besonders schwer zu erkennen sein. Slideshare anzeigen »

 

Was mir an den oben genannten vier Implementierungen wirklich gefällt, ist, dass es sich dabei nicht um die Einhörner von DevOps handelt und auch nicht um die Aushängeschilder von DevOps (wie etwa Netflix oder Etsy), was ihre Geschichten für alle Anwendungen relevanter macht.

Aber schauen wir uns auch die beiden Aushängeschilder an:

 

Etsy

Etsy ist ein vielfach zitierter DevOps-Praktiker und Mitwirkender am Technologie und Werkzeuge im Raum verfügbar. Sie zeigen einen Top-down-Ansatz zur Einführung von DevOps. Die gesamte Organisation hat früh verstanden, dass sich langfristige Veränderungen auf Kultur, Einstellungsansätze, Motivationstechniken usw. konzentrieren müssen. Aber auf der taktischen Seite (Infrastruktur) konzentrierten sie sich auf die gegenseitige Befruchtung der Teams, eine Politik der offenen Tür und Sichtbarkeit für alle. Slideshare anzeigen »

 

Netflix

Noch mehr als Etsy wird Netflix als der DevOps-Traum präsentiert. Und es gibt keinen Mangel an Beispielen, die zeigen, wie ihre Umgebung auf Hochtouren läuft (und was für coole Dinge sie tun). Achten Sie in ihrer Präsentation auf die Referenzarchitekturen und darauf, wie sie sicherstellen, dass ihre Cassandra-Datenbank nicht ausfällt. Boom! Sie investieren viel Aufwand in umfassende Datenbanktests während des Release-Prozesses. Backends werden oft erst nach mehreren Releases und in begrenzten Szenarien getestet. Slideshare anzeigen »

 

Finden Sie Ihr eigenes Playbook

Es ist üblich, eine Implementierung zu finden, die zu Ihrer eigenen passt, und sie kann als Schritt-für-Schritt-Anleitung für die Implementierung von DevOps in Ihrer eigenen Organisation dienen. Aufgrund der Unterschiede bei Stacks, Anwendungen und Teams ist es jedoch nicht möglich, den Prozess einer anderen Organisation zu duplizieren. Dennoch kann man von denen, die Erfolge mit ihren DevOps-Praktiken verbuchen, viel lernen, und man kann auf dem aufbauen, was sie gelernt haben.