Site Reliabily Engineering und Platform Engineering DevOps im Vergleich zu SRE und PE

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Site Reliability Engineering und Platform Engineering denken die DevOps-Idee weiter drängen sich immer weiter in den Vordergrund. Doch wo liegen eigentlich die Unterschiede – und können die beiden eher praktischen Ansätze die DevOps-Philosophie ersetzen?

Die meisten Software-orientierten und -entwickelnden Unternehmen dürften sich inzwischen darüber einig sein, dass der DevOps-Ansatz nicht nur modern, sondern auch effizient ist – und die Software-Entwicklung je nach Umgebung und Mindset im Unternehmen deutlich beschleunigen kann. Neuerdings ist allerdings auch immer öfter von Site Reliability Engineering und Platform Engineering die Rede

Hier und da werden diese beiden Strategien als „DevOps-Nachfolger“ gehandelt. Das stimmt in dieser Form aber nicht: Wie der Begriff „Engineering“, also „Ingenieurswesen“ oder auch „Technik“ suggeriert, handelt es sich um Versuche, den theoretischen DevOps-Ansatz in eine konkrete Form zu packen – und Developern die nötigen Plattformen und Tools an die Hand zu geben.

Zunächst ein Blick auf DevOps. Bei diesem Konzept der Softwareentwicklung soll die Zusammenarbeit zwischen Software-Entwicklung und IT-Betrieb optimal ablaufen. DevOps-Teams sind typischerweise viel damit beschäftigt, Tools und Workflows zu finden, zu entwerfen oder zu entwickeln, damit die Zusammenarbeit und der DevOps-Ansatz an sich möglichst reibungslos funktionieren – eine zusätzliche Belastung, die von der eigentlichen Arbeit, der Entwicklung, abhält.

Genau hier setzt Platform-Engineering an. Mithilfe einer zentralen Plattform für die benötigten Tools und Workflows sollen Entwicklerinnen und Entwickler entlastet werden, während sich zum Beispiel ein separates Platform-Team und die Definition und den Bau der benötigten Grundlagen kümmert. Der Ansatz ist ein wenig vergleichbar mit dem Handwerk in Deutschland und den USA. Während in den USA nämlich jeder Handwerker sein eigenes Werkzeug besitzt, wird in Deutschland üblicherweise auf das Inventar des Arbeitgebers zurückgegriffen.

Die „alte“ DevOps-Praxis entspräche demnach der Vorgehensweise des US-Handwerks: Jedes DevOps-Team, möglicherweise jede Person im Entwicklungsteam, greift auf sein eigenes Handwerkszeug zurück. Das kann zwar die Produktivität fördern, schluckt aber viel Zeit für Nebenaufgaben wie Evaluation und Pflege der Werkzeuge und Entwicklung der nötigen Strukturen. Hier sprechen Profis von sogenannter „Mental Load“, also geistiger Belastung.

SRE gab es schon Jahre vor DevOps

Platform Engineering – und auch Site Reliability Engineering – verfolgen eher den „hiesigen“ Handwerksansatz: Entwicklerinnen und Entwickler erhalten ihr Handwerkszeug durch das Unternehmen, wodurch sowohl Overhead für die Zusammenstellung und Pflege der Werkzeuge und Workflows entfällt. Developer können sich also auf ihre Kernaufgaben konzentrieren. Die Schattenseite: Unternehmen müssen hierfür je nach Bedarf natürlich einen Verantwortlichen oder sogar ein ganzes Teams aufstellen – und die Entwickelnden dürfen möglicherweise nicht ihre beliebtesten Tools verwenden.

Site Reliability Enginieering, kurz SRE, ist ein zusätzliches Standbein dieser Idee. Beim SRE geht es darum, eine möglichst zuverlässige und skalierbare technische Grundlage für DevOps zu schaffen. Damit ist Site Reliability Engineering also auch keine Weiterentwicklung von DevOps, sondern eher eine zusätzliche Möglichkeit zur konkreten Umsetzung, hauptsächlich in größeren Unternehmen. Schließlich kommt die Idee ursprünglich von Google, wo Site Reliability Engineers erstmals 2003 eingesetzt wurden

Die Technik wurde bei zahlreichen großen Unternehmen übernommen, lange bevor DevOps überhaupt ein Thema war. SRE war der finalen DevOps-Idee immerhin sechs Jahre voraus. Inzwischen zeigt sich aber, dass SRE DevOps unter die Arme greifen kann. Inhaltlich setzt die Technisch auf kosteneffektive Automatisierung, Systemdesign und Messbarkeit sowie Ansätze zur praktischen Umsetzung des Pareto-Prinzips, um unnötigen Perfektionismus zu vermeiden – ideale Voraussetzungen, um den DevOps-Ansatz aufblühen zu lassen.

Somit sind beide Techniken damit heutzutage in Unternehmen im Grunde die Folge der Entscheidung, auf DevOps zu setzen und optimal umzusetzen. Beide Strategien können gemeinsam oder einzeln gefahren werden und benötigen je nach Unternehmensgröße und -zielen mal mehr, mal weniger personellen Aufwand.

Oftmals werden Site Reliability Engineering und Platform Engineering auch erst umgesetzt, wenn der DevOps-Ansatz bereits vorhanden ist. Gleichzeitig sorgt die Trennung von DevOps-Teams und Engineering-Lösungen dafür, dass auch komplexere Aufgaben effizient bewältigt werden können – und Developer in ihren Kernbereich bearbeiten können, ohne sich um die Technik an sich kümmern zu müssen.

Effiziente Prozesse für alle

Doch nicht nur Entwickler und Entwicklerinnen können von der Ergänzung profitieren. Site Reliability Engineering und Platform Engineering helfen im gesamten IT-Bereich dabei, eine gemeinsam nutzbare Infrastruktur aufzubauen, die sich im Hinblick auf Messbarkeit – etwa für Daten-Analysten – oder auch Automatisierung und Wartung – etwa durch Self-Service-Lösungen – auch in anderen Bereichen einsetzen lassen. So kann letztlich ein großer Teil der der Unternehmensstruktur von den angelegten Techniken, Plattformen und Workflows profitieren.

Die konkrete Umsetzung von SRE und Platform Engineering kann übrigens wahlweise in der Cloud oder über eigene Lösungen erfolgen. Allerdings gibt es derzeit eine Tendenz, die verstreuten Cloud-Dienstleistungen wieder zentralisiert zur Verfügung zu stellen. Das können Dienstleister sein, die eingekauft werden – die Bereitstellung von Tools und Plattformen kann aber durchaus auch inhouse erfolgen. Das allerdings benötigt Zeit.

Wie schon beim DevOps-Ansatz gilt es, bestehende Strukturen gegebenenfalls aufzubrechen und alte Arbeitsweisen zu revidieren. Wer sich hier nicht flexibel ist, wird auch durch Einrichtung von Teams für DevOps, SRE und Platform Engineering wenig bewegen. Zunächst müssen alte Monolithen geprüft und neue Strukturen etabliert werden. Dieser Prozess kann je nach Unternehmensstruktur langwierig sein, zahlt sich aber am Ende höchstwahrscheinlich durch höhere Qualität der entwickelten Software und schnelleren Entwicklungszyklen aus.

(ID:49641630)