Zum Inhalt wechseln

Was ist die beste DevOps-Topologie für mein Unternehmen?

Technology

10 März 2023 - 9 Minuten lesen

800_DevOps_blog_article_illustration
Łukasz Uruski Java Guild Master

Lukasz führt die Java-Abteilung und ist Enthusiast der DevOps-Bewegung und von Teal-Organisationen. 

Alle Beiträge von Łukasz anzeigen

1394 DE Resources Thumbs

Teilen

Inhaltsverzeichnis

  1. Was mich jedoch am meisten beeindruckte waren seine Worte:  
  2. Die 3 gängigsten DevOps-Topologien 
  3. Fully Shared Ops Responsibilities  
  4. Wann ist der Einsatz sinnvoll? 
  5. Zusammenfassend 
  6. Ops als Infrastructure-as-a-Service 
  7. Wann ist der Einsatz sinnvoll? 
  8. DevOps Advocacy 
  9. Wann ist der Einsatz sinnvoll? 
  10. Zusammenfassung und Fazit 

Vor einiger Zeit lernte ich auf einer Konferenz Dave kennen, einen Betriebsleiter eines in Großbritannien ansässigen Automobilunternehmens. Wir haben eine ganze Weile damit verbracht, über ihren Weg in die Cloud und die gleichzeitige DevOps-Transformation zu diskutieren. Die Ergebnisse waren ziemlich beeindruckend. Innerhalb von weniger als einem Jahr wurde aus einer isolierten Organisation mit Development und Operations, die kaum miteinander redeten, eine geschäftsorientierte Einheit. Mit einem Team spezialisiert auf eine Plattform, die Tools bereitstellt, und autonomen, funktionsübergreifenden DevOps-Teams. Dadurch verkürzte sich die Time-to-Market, während die Qualität der Software und die Stabilität der Services stiegen. Unter Verwendung der Terminologie und Kriterien aus den State of DevOps-Berichten von DORA würde ich sie als hochleistungsfähige Teams einstufen. 

Was mich jedoch am meisten beeindruckte waren seine Worte:  

„Wir wussten, dass wir als Operations-Team keine Erfahrung mit der Cloud und DevOps hatten, aber gleichzeitig wollten wir diesen Service nicht an ein Softwarehaus auslagern; wir wollten auch niemanden entlassen. Am Ende des Tages stellten wir mehrere Vertragspartner ein, deren Ziel es war, uns alles beizubringen.“ 

Erstens stimme ich vollkommen zu, dass es das Schlimmste ist, erfahrene Mitarbeiter mit Fachkenntnissen zu entlassen, nur weil ihnen einige technische Fähigkeiten fehlen. 

Zweitens gibt es verschiedene DevOps-Arbeitsmodelle (Topologien) und sie haben sich intuitiv für eines davon entschieden. 

Die 3 gängigsten DevOps-Topologien 

Als ich in den letzten zwei Jahren unsere internen Teams analysierte, die an verschiedenen Projekten für verschiedene Kunden arbeiteten, stellte ich fest, dass diese spezielle Topologie relativ oft verfolgt wurde. Aber es ist nicht die einzige Option. In ihrem Buch „Team Topologies“ haben Matthew Skelton und Manuel Pais zehn verschiedene Topologien identifiziert. 

In diesem Blogbeitrag werde ich mich nur auf die drei häufigsten konzentrieren und basierend auf unserer Erfahrung werde ich versuchen vorzuschlagen, wann es empfehlenswert ist, diese auszuwählen. Außerdem werde ich auf die wichtigsten Vorteile und Risiken hinweisen. 

Fully Shared Ops Responsibilities  

In diesem Modell, das manchmal einfach als vollständiger DevOps oder DevOps Managed Service bezeichnet wird, ist ein Produktteam vollständig für einen von ihm erstellten Service verantwortlich. Sie haben ein hohes Maß an Autonomie und ein breites Spektrum an Verantwortlichkeiten. Einerseits wählen sie Frameworks, Services und Tools selbst aus, aber gleichzeitig müssen sie über breitere Kompetenzen verfügen und wenn sie falsche Entscheidungen treffen, werden sie die Konsequenzen tragen. Hier gilt als zentrale Herausforderung eine minimalen Anzahl von Personen mit ausreichenden Fähigkeiten. Lassen Sie uns kurz die Verantwortlichkeiten zusammenfassen: 

Entwicklung – Dies umfasst das Architekturdesign, die Entwicklung neuer Funktionen und die Fehlerbehebung. Es kann vorkommen, dass andere Produktteams, Änderungen am Service des betreffenden Teams implementieren, einfach weil sie diese benötigen und es in Organisationen mit einer DevOps-Kultur so üblich ist. Alle Änderungen müssen jedoch immer von dem verantwortlichen Team überprüft und akzeptiert werden. Denken Sie daran, dass sie für diesen Service voll verantwortlich sind. Wenn der Dienst ausfällt, akzeptiert niemand Erklärungen wie „Es ist nicht mein Code, der kaputt ist“. 

Umgebungsbereitstellung – das Team muss sicherstellen, dass es über die erforderliche Infrastruktur verfügt. Sie bereiten und warten Tools zur Bereitstellung (und Außerbetriebnahme) von IT-Umgebungen. Darüber hinaus entscheiden sie, ob etwas ein spezielles Tool und einen speziellen Prozess erfordert. Vielleicht ist es keine übliche Aktivität und es macht keinen Sinn, in Automatisierung zu investieren? Das liegt an Ihnen. Wenn man genau abschätzen kann, welche Ressourcen benötigt werden (z. B. soll es eine Anwendung sein, die von internen Mitarbeitern genutzt wird), dann geht das auch ohne Cloud. Andernfalls ist es einfach zu riskant oder sogar unmöglich. 

Build, Package, Release – das Team entscheidet, wie ein Bereitstellungsprozess aussieht, von der Programmierung bis zum Release in der Produktion. Wie werden sie integriert, welche Tests werden wann durchgeführt, wie wird der Sicherheitsaspekt berücksichtigt? Teams, die als Elite-Performer eingestuft werden, können die Zeit die erforderlich ist, um neuen Code in die Produktion zu bringen, auf weniger als eine Stunde verkürzen. Da das Team in dieser Topologie für die gesamte Lieferkette verantwortlich ist, gibt es keine Grenzen und es ist nur eine Frage der Kompetenzen und Prioritäten, eines dieser supereffizienten Teams zu werden. 

Monitoring & Alerting – Das Team ist für die Verfügbarkeit des Dienstes verantwortlich, daher ist es in seinem besten Interesse, einen Einblick in die Vorgänge zu haben und proaktiv über Störungen informiert zu werden und benötigen Informationen darüber, was in der Produktionsumgebung vor sich geht. 

Wann ist der Einsatz sinnvoll? 

Es gibt viele Aspekte, die das Team verwalten muss, aber sobald es die richtigen Ressourcen hat, kann das Team sehr effektiv sein. Diese DevOps-Topologie funktioniert gut, wenn Sie Produktideen schnell entwickeln und mit dem Markt konfrontieren müssen; wenn Ihre oberste Priorität eine kurze Markteinführungszeit ist oder wenn Sie einen Proof-of-Concept oder ein Pilotprodukt erstellen müssen. Es kann jedoch vorkommen, dass das Team Zeit investieren muss, um das Produkt und den Lieferprozess an die vom Unternehmen befolgten Standards anzupassen, sobald ein Geschäftsinhaber bestätigt, dass dieser neue Service wertvoll ist. 

Diese Teamtopologie kann die richtige Wahl sein, wenn Ihre Organisation nur wenige Produktteams aufweist und die Standardisierung keinen großen Wert hat. Wenn Sie nur ein paar Fahrräder in Ihrer Garage haben, werden Sie schließlich kein Geld und keine Zeit für Werkzeug investieren, die von professionellen Fahrradwerkstätten verwendet werden. 

Wenn Sie in einer stark regulierten Branche arbeiten und jedes Produkt vom ersten Tag an konform sein muss, müssen Sie besonders darauf achten, ob das Team diese Richtlinien kennt. Es ist absolut machbar aber geschieht eher durch Schulung des Teams als durch einen formalen Bereitstellungsprozess oder bereitgestellte Tools. 

Zusammenfassend 

Kurz gesagt, die zentrale Herausforderung ist die Ressourcenbeschaffung und das Team muss sehr gut darin sein unnötige herauszufiltern. Unweigerlich werden sie ihre eigenen Lösungen und internen Tools entwickeln. 

Ops als Infrastructure-as-a-Service 

In Team Topologies prägten Skelton und Pais den Namen Ops als Infrastructure-as-a-Service, ich nenne es aber auch gerne „Mature Operations“. Dies unterstreicht die Tatsache, dass dieses Modell von einem echten Plattformteam abhängt und diese wurden in vielen Fällen von ehemaligen Ops/Infra-Teams gebildet. 

In dieser Topologie kümmert sich das Team um den gesamten Service, ähnlich wie bei Full DevOps. In diesem Fall können und sollten sie jedoch Tools verwenden, die vom Plattformteam bereitgestellt werden. 

Umgebungsbereitstellung – Nehmen wir an, das Hosting erfolgt in der Cloud, sodass das Plattformteam Skripte (z. B. Terraform-Skripte) bereitstellen kann, um die Bereitstellung zu vereinfachen. Natürlich muss das Team es nicht verwenden und es kann alles von Grund auf selbst vorbereiten, ABER wenn es Probleme mit den bereitgestellten Ressourcen gibt, hilft das Plattformteam bei der Lösung. Darüber hinaus stellen solche Tools im Falle von Elementen, die standardisiert werden müssen (z. B. einheitliche Kennzeichnung von Ressourcen, die für Kostenmanagementaktivitäten erforderlich sind), diese kostenlos zur Verfügung. 

Build, Package, Release – ausgereifte Plattformteams bieten nicht nur Automatisierungsserver als Service, sondern auch Pipelines als Code (Jenkins Pipelines, Azure Pipelines, Circle CI Pipelines, um nur einige zu nennen). Das Team muss sich darauf konzentrieren, wie es sie effektiv nutzt und dem Plattformteam kontinuierlich Feedback dazu geben, welche neuen Funktionen erforderlich sind. 

Monitoring & Alerting – einige Unternehmen übertragen die Verantwortung nach wie vor auf Support-Teams, sobald neue Dienste stabilisiert sind und die Anzahl neuer Funktionen und aktiver Entwicklung minimal ist. In diesem Fall vereinfacht die Standardisierung im Bereich Monitoring & Alerting den Übergangsprozess erheblich. 

Wann ist der Einsatz sinnvoll? 

Dies ist eine sehr gute Teamtopologie, wenn Ihr Unternehmen viele interne Teams aufweist oder mit mehreren Anbietern zusammenarbeitet. Wiederverwendete Komponenten bieten Standardisierung, daher ist es für den Kunden einfacher, das Eigentum an einem gelieferten Produkt zu übertragen. Dieselbe Standardisierung kann dabei helfen, regulatorische Anforderungen zu erfüllen. 

Das größte Risiko hängt mit dem Grad der Zusammenarbeit zwischen Produktteams und Plattformteams zusammen. Produktteams sollten so weit wie möglich darauf verzichten, benutzerdefinierte Tools zu erstellen, aber um dies tun zu können, müssen Plattformteams Feedback sammeln und die angeforderten Funktionen schnell implementieren. Das Fehlen einer solchen Kultur, multipliziert mit der Tatsache, dass die Produkt- und Plattformteams physisch getrennt sind, ist zum Scheitern verurteilt. 

DevOps Advocacy 

In diesem Modell steht das Team zwischen Devs (Produktteams) und Ops/Infra. Sein Hauptziel ist die Verbreitung von DevOps-Konzepten durch Wissensaustausch, Transparenz und Zusammenarbeit. Sie schulen und fördern effektiv das Ops as Infrastructure-as-a-Service-Modell. Sie bereiten Tools für Produktteams vor und führen bei Bedarf Standards und Richtlinien ein. Schauen wir uns ein paar Beispiele an: 

Umgebungsbereitstellung – das Team kann alles erweitern und bereichern, was von Betriebs- und Infrastrukturteams bereitgestellt wird. Eine häufige Herausforderung besteht darin, dass diese Tools nicht in einem Self-Service-Modell bereitgestellt werden. Das Hauptziel des Teams ist es, dies zu beheben. Ein Beispiel kann ein Automatisierungsserver (z. B. Jenkins) als Service sein, jedoch ohne vordefinierte Pipelines. Durch die Kenntnis der Best Practices, kann das Team solche Pipelines erstellen und die Kick-off-Phase jedes neuen Produkts beschleunigen. Darüber hinaus kann das Team regelmäßig überprüfen, ob die von den Produktteams erstellten Umgebungen und Dienste sowohl den Best Practices als auch den Unternehmensregeln entsprechen. 

Build, Package, Release – wenn das Ops- oder Infrastructure-Team über ein Angebot verfügt, das von Produktteams genutzt werden könnte, aber nicht als Self-Service verfügbar ist, versucht das Team dies abzumildern. Auch hier könnte es sich um einen Automatisierungsserver, eine statische Codeanalyse oder Sicherheitsscans handeln. Einer unserer Kunden hatte einen Prozess, bei dem jeder Veröffentlichungskandidat von einem speziellen Team analysiert wurde, was normalerweise zwei Wochen dauerte. Das Team fand heraus, dass dieser Schritt durch die Integration von Zed Attack Proxy und Trivyscans in den Integration-Prozess effektiv ersetzt werden kann. Auf diese Weise kann es in weniger als 30 Minuten erledigt werden. 

Monitoring & Alerting – Einerseits stellt das Team Tools bereit, die sich auf den Bereitstellungsprozess auswirken, die sich um die Standardisierung kümmern und somit die Überwachung vereinfachen können (z. B. Namenskonventionen von Ressourcen, Tagging, Protokollierungsinfrastruktur, Offenlegung von Metriken). Auf der anderen Seite vereinfacht das Team durch die enge Zusammenarbeit mit Operations und deren Schulung die Ops-Arbeit erheblich und erhöht den Gesamtautomatisierungsgrad. 

Wann ist der Einsatz sinnvoll? 

Wenn es darum geht, Lieferprozesse zu optimieren und die Time-to-Market durch die Einführung von Automatisierung zu verkürzen, ist ein solches Team die richtige Wahl. Sie werden entscheiden, was eine Automatisierung wert ist (weil es von mehreren Teams verwendet wird) oder was manuelle Arbeit bleiben soll (z. B. benötigt ein kleiner neuer Service, der in zwei Wochen erstellt wird, keine vollständige Pipeline). Um effizient zu sein, brauchen sie jedoch Zeit, um die Herausforderungen der Organisation sowie ihre Struktur zu verstehen. 

Dank eines Einblicks in die Verwendung ihrer Tools können sie entweder Gatekeeper oder Advocate (Fürsprecher) werden. Ein Gatekeeper passt auf, dass nichts schief läuft, und ein Advocate klärt Kollegen über gute und schlechte Praktiken auf. DevOps-Paradigmen deuten stark auf Letzteres hin, aber seien wir realistisch. Unterschiedliche Organisationen haben unterschiedliche Anforderungen, daher ist es sehr oft eine Kombination aus beidem. Wie das Team arbeiten wird, hängt von der Strategie des Unternehmens in Bezug auf die Zusammenarbeit mit Anbietern ab. Wenn ein Anbieter nur Software herstellt und diese an den Kunden zurückgibt, ist ein Gatekeeper sinnvoller. Wenn ein Anbieter Software produzieren muss und für diesen Service mindestens einige Monate lang verantwortlich sein wird, ist ein Advocate möglicherweise die bessere Wahl. 

Ein weiterer Anwendungsfall für diese Teamtopologie ist, wenn Sie Ihr Betriebsteam in ein Plattformteam umwandeln möchten. Ein gut ausgestattetes Team verfügt nicht nur über die technischen Kompetenzen, die zur Umsetzung der Unternehmensstrategie erforderlich sind, sondern ist auch sehr gut im Coaching und Wissensaustausch. Gleiches gilt, wenn Sie die Arbeitsweise Ihrer Entwicklungsteams ändern wollen. Wenn Sie im DevOps-Modus arbeiten und den Service End-to-End verantworten möchten, dann ist dies auch Ihr Modell. 

Denken Sie daran, dass das Team, das in diesem DevOps-Modell arbeitet, möglicherweise auf Bereiche beschränkt ist, die dem Betriebs-/Infrastrukturteam gehören. Um den Wandel optimieren zu können, benötigen sie ein starkes Mandat von Geschäftsinteressenten, aber noch wichtiger ist, dass alle Seiten die wichtigsten DevOps-Paradigmen verstehen und befolgen müssen - Wissensaustausch, Transparenz und Zusammenarbeit. 

Zusammenfassung und Fazit 

Mit diesem Modell können Sie schnell viel Wissen und Fachwissen in Ihr Unternehmen einbringen, ohne die aktuelle Struktur zu beeinträchtigen und genau das haben Dave und sein Unternehmen getan. Sie baten den Anbieter nicht, das gesamte Team bereitzustellen, sondern stellten mehrere Auftragnehmer ein – das Modell ist jedoch dasselbe. 

Nachdem die Produktteams und der Betrieb nach mehreren Monaten neue Techniken und Tools erlernt und sich an das Modell der gemeinsamen Verantwortung gewöhnt hatten, wechselten sie reibungslos zu Mature Operations oder Ops as Infrastructure-as-a-Service. Gut gemacht! Bedenken Sie jedoch, dass nicht jedes Unternehmen dieses Modell anstreben kann oder sollte. Was die beste DevOps-Teamtopologie bestimmt, ist die Größe Ihres Unternehmens, das Maß an Vorschriften in Ihrem Geschäftsbereich und die Art und Weise, wie Sie mit Anbietern interagieren möchten. 

1394 DE Resources Thumbs
Łukasz Uruski Java Guild Master

Lukasz führt die Java-Abteilung und ist Enthusiast der DevOps-Bewegung und von Teal-Organisationen. 

Alle Beiträge von Łukasz anzeigen

Was Sie noch interesieren könnte

Kontakt

Starten Sie Ihr Projekt mit Objectivity

CTA Pattern - Contact - Middle