Kemp Technologies Blogs

Warum Sie DevOps und NetOps auf eine gemeinsame Wellenlänge bringen müssen

Doug Barney | Posted on | Load Balancer

Load Balancers und Application Delivery Controllers (ACDs) sind ein wichtiger Bestandteil der Anwendungsinfrastruktur. Um mit den strengen und neuesten technologischen Anforderungen Schritt zu halten, ist eine hoch skalierbare, extrem zuverlässige und sichere Load Balancing-Architekturstrategie unerlässlich.

In diesem Webinar geht Maurice McMullin auf die Entwicklung des Load Balancing ein und erklärt, wie wichtig es ist, dass IT-Organisationen einen funktionsübergreifenden Ansatz wählen. Dieser Blog und das Webinar "Warum Sie DevOps und NetOps auf dieselbe Seite bringen müssen" diskutieren:

  • Die Entwicklung von Load Balancing und Application Delivery Controllern (ACD)
  • Die Vergangenheit: Rechenzentrumstechnik
  • Zukunft: DevOps und NetOps sollten einen einheitlichen Ansatz verfolgen
  • Warum ein einheitlicher Ansatz der Schlüssel zur Modernisierung Ihrer Load-Balancing-Strategie ist
  • So erstellen Sie eine einheitliche funktionsübergreifende DevOps- und NetOps-Strategie
  • So modernisieren und vereinheitlichen Sie die Load-Balancing-Architektur
  • Schließung von Qualifikationslücken durch siloübergreifende Partnerschaften
  • Die Bedeutung der Integration von Sicherheitsabläufen
  • Vorteile eines einheitlichen Ansatzes für Rechenzentren und Public-Cloud-Umgebungen

Eine großartige Ressource für die Analyse der Welt von DevOps und NetOps ist ein aktueller Forschungsbericht von Enterprise Management Associates (EMA): Load Balancing in a Hybrid and Multi-Cloud World. Die Studie befasste sich mit der Art und Weise, wie Unternehmen ihre Load-Balancing-Assets verwalten und betreiben, und lieferte einige interessante Erkenntnisse darüber, wie DevOps- und NetOps-Teams oft unabhängig voneinander arbeiten.


Die EMA hat herausgefunden, dass kleinere, mittelständische Unternehmen mit 1.000 bis 3.000 Mitarbeitern eher einen isolierten Ansatz für DevOps und NetOps verfolgen, wie die folgende Grafik zeigt. 


Befragte, die in der DevOps-Abteilung arbeiten, berichteten viel häufiger (75 %) von einem völlig isolierten Ansatz für das Load Balancing, was darauf hindeutet, dass DevOps-Gruppen häufig ihre eigenen Load Balancing-Plattformen verwenden, während sie Anwendungen entwickeln und testen. Sobald die Anwendungen in einer hybriden Cloud in Produktion gehen, wird das Infrastrukturteam die Verwendung einer standardmäßigen Load Balancing-Plattform verlangen.

Dies führt natürlich zu Verzögerungen bei der Bereitstellung neuer Anwendungen, aber auch zu potenziell zusätzlichen Kosten, da DevOps-Teams ihre Load-Balancing-Implementierungen überarbeiten. Es gibt mehrere andere Probleme, wie Sie unten sehen können.

Das große Problem, das identifiziert wurde, ist die Ineffizienz – und diese Ineffizienz kann so einfach sein wie die Identifizierung, wer für was verantwortlich ist, oder die Komplexität, sicherzustellen, dass Änderungen einer Gruppe keine Auswirkungen auf die andere haben.

Das Netzwerkteam – und ich schließe hier das Sicherheitsteam ein – hat sich traditionell auf die Verfügbarkeit und Sicherheit des Netzwerks konzentriert: Lassen Sie die Lichter an, erzielen Sie so viele Neunen wie möglich in der Betriebszeit und schützen Sie das Netzwerk.

Und obwohl sie Automatisierung und "Infrastructure as Code" nutzen können, kann die kulturelle Denkweise dennoch darin bestehen, mit Vorsicht vorzugehen. Hier müssen DevOps und NetOps aufeinander abgestimmt werden – beide Gruppen haben einen kulturellen und technischen Austausch und einen einheitlichen und gemeinsamen Ansatz, der eine bessere Agilität bei Netzwerk- und Anwendungsänderungen ermöglicht.

 

Ein weiterer Punkt der Ineffizienz ist die Fragmentierung der Tools und Technologien. Der EMA-Bericht betrachtet dies aus dem Blickwinkel von Multi-Cloud und Hybrid-Cloud und stellt fest, dass 57 % der Befragten virtualisierte Load Balancing Solutions von ihren lokalen Anbietern anstelle von nativen Cloud-Lösungen verwenden. Die Verwendung mehrerer Load Balancing-Lösungen für die Anwendungsbereitstellung erhöht deren Komplexität und damit die betriebliche Ineffizienz. Ein einheitlicher Ansatz für die Anwendungsbereitstellung, der auf ein und demselben Anbieter für On-Premises und Cloud basiert, wirkt sich nicht nur auf die betriebliche Ineffizienz aus, sondern trägt auch zum zweiten Punkt bei - der Transparenz.


DevOps- und NetOps-Gruppen haben eine andere Linse, durch die sie die Umgebung betrachten – und verwenden Toolsets, die ihnen diese Linse bieten. Die Fragmentierung der Rollen bedeutet jedoch, dass die End-to-End-Transparenz fehlen kann.

Vorteile eines einheitlichen Ansatzes für das Load Balancing

Wenn wir diese Liste durchgehen, sehen wir, dass die Probleme in den Bereichen Leistung, Sicherheit und Konformität sehr groß sind. Schauen wir uns an, wie ein einheitlicher Ansatz für Load Balancing es einfacher machen kann, DevOps und NetOps auf dieselbe Seite zu bringen.

Bevor wir uns mit den Einzelheiten befassen, sollten wir uns vergegenwärtigen, dass es hier ein größeres Bild gibt. Ein großes Problem ist die Anpassung der Kultur der Teams. Das geht weit über den Rahmen des heutigen Beitrags hinaus. Anstatt zu versuchen, diesen Ozean zum Kochen zu bringen, werden wir uns auf die zentrale Rolle konzentrieren, die die richtige Load Balancing-Strategie bei der Abstimmung der Teams spielen kann.


Abgesehen von den Kosten für betriebliche Ineffizienz kann ein Multi-Cloud-/Multi-Vendor-Ansatz deutlich teurer sein als eine herkömmliche Load Balancing Solution.

So gibt es beispielsweise einen fragmentierten Einkauf, der sogar innerhalb eines einzigen Cloud-Anbieters stattfinden kann. Die Leute kaufen Dienste auf Abruf, und die Unternehmen verpassen die Größenvorteile und die effizienten Lizenzierungssysteme wie gepoolte Lizenzen. Und wir alle kennen die Geschichten von der Cloud-Services-Spawl, bei der Gruppen unabhängig voneinander handeln und das gesamte Unternehmen viel Geld für die Dienste bezahlt.

Pay-per-Use-Funktionen sind ein weiteres Problem. Einige Cloud-Anbieter berechnen zusätzliche Tarife für Funktionen wie benutzerdefinierte Web Application Firewall (WAF)-Regeln, die bei AWS sehr schnell sehr teuer werden. Außerdem werden Dienste wie die Authentifizierung oft mit den Nutzungskosten pro Authentifizierung oder Captcha abgerechnet. Diese sind alle in die Load-Balancer-Funktionalität eingebettet, was die Budgetierung vereinfacht und tatsächlich weniger kostet.

Das Verständnis der Cloud-Kosten ist eine Herausforderung. Cloud-Plattformen verwenden mehrere Metriken, um die Kosten zu bestimmen, und eine Erhöhung einer einfachen Metrik wie der Anzahl der WAF-Regeln oder der Anzahl der Authentifizierungen kann zu erheblichen Kostenspitzen führen.

Hier zeichnet sich der traditionelle Load Balancer aus – die einzige Metrik ist der Durchsatz mit so vielen WAF-Regeln, wie Sie möchten, und so vielen Authentifizierungen, wie Sie möchten – keine Überraschungen. Und die Verwendung flexibler Lizenzierungsoptionen, wie z. B. gepoolte Lizenzierung, ermöglicht eine bedarfsgerechte Skalierung und maximiert die Kaufkraft, um das beste Preis-Leistungs-Verhältnis zu erzielen.

 

Herausforderungen bei der Skalierung und Leistung mit einer Cloud-basierten Load Balancing Solution wirken sich auf eine bedeutende Kohorte der befragten Unternehmen aus. Auch hier verstärkt die Fragmentierung der Verantwortung diese Probleme, da die Teams anfangen, mit dem Finger auf andere zu zeigen.


Mit integrierten DevOps und Netops können die Probleme der organisatorischen Verantwortung gelöst werden, aber die Herausforderung bleibt bestehen, Transparenz und Kontrolle über verschiedene Cloud-Architekturen für die Anwendungsbereitstellung hinweg zu haben. Hier kommt ein einheitlicher Ansatz für die Bereitstellung von Multi-Cloud-Anwendungen ins Spiel.

Die EMA-Mitarbeiter weisen in ihrem Bericht ausdrücklich auf die inhärenten Probleme beim Load-Balancing von Cloud-Anbietern hin und empfehlen die Verwendung virtueller Load Balancer von einem fokussierten Anbieter. Der Bericht zeigt, dass viele Unternehmen diesen Ansatz bereits gewählt haben.

So verwenden beispielsweise 38 % der Single-Cloud-Unternehmen bereits alternative virtuelle Appliances, und diese Zahl steigt auf 73 %, wenn drei oder mehr Clouds verwendet werden.

Dies deutet darauf hin, dass viele Unternehmen bereits den Wert eines einheitlichen Ansatzes für ihre Load-Balancing-Technologie und -Infrastruktur erkennen, wodurch die Herausforderung, DevOps- und NetOps-Gruppen – und Sicherheit – auf dieselbe Seite zu bringen, erheblich vereinfacht wird.

Ein interessanter Punkt in diesen Daten ist, dass viele Load Balancer einsetzen, denen es an fortschrittlichen Funktionen mangelt - obwohl sie eine umfassendere und integrierte Lösung nutzen könnten, die nicht nur Verfügbarkeit und Leistung, sondern auch Sicherheitsfunktionen und Multi-Site-/Multi-Cloud-Dienste abdeckt. Mit einer fortschrittlichen Load Balancing Solution wird die Komplexität reduziert, da die Teams keine externen Lösungen finden müssen, um Funktionslücken zu schließen. Weniger Komplexität, weniger Kosten und ein geringeres Risiko, Sicherheitslücken zu schaffen.

 
Isolierte DevOps/Netops leiden auch unter Qualifikationslücken. Dies ist keine große Überraschung, da Unternehmen Schwierigkeiten haben, qualifizierte Mitarbeiter einzustellen und zu halten.

Das Vorhandensein mehrerer Plattformen für die Anwendungsbereitstellung und das Load Balancing vergrößert dieses Problem noch.

Wir können sehen, dass die Konflikte zwischen den Teams mit 43 % sehr hoch sind. Dies ist unvermeidlich, wenn Teams unabhängig voneinander arbeiten und Prozesse und Systeme für die Verwaltung und Überwachung getrennt haben. 

DevOps-, Netzwerk- und Sicherheitsteams müssen lernen, wie sie auf einer gemeinsamen Plattform zusammenarbeiten können. Dies wird auch dazu beitragen, Best Practices zu fördern.

Ich möchte hier nur hinzufügen, dass die Sicherheit in alle Ansätze zur Anwendungsbereitstellung einbezogen werden muss, und dass die Zusammenarbeit der Sicherheitsfunktionen der Schlüssel zum Erfolg ist.
 

Der Ausgangspunkt für die Abstimmung von DevOps, NetOps und Sicherheit - nicht zu vergessen die Sicherheit - ist ein einheitlicher Ansatz für Load Balancing. Die Vereinheitlichung Ihrer Load Balancing-Strategie bietet eine einzige konsistente API für DevOps-, NetOps- und Sicherheitsteams - über alle Plattformen hinweg. Hier sind weitere Vorteile:

  • Vermeiden Sie die Komplexität der Cloud-Fragmentierung. Dies kann teaminterne Vorteile bringen.
  • Gemeinsame Fähigkeiten – erleichtert das Training.
  • Die gesamte Anwendungsbereitstellung kann zentral definiert, konsistent angewendet und über dasselbe Tooling in Logging- und Monitoring-Toolsets integriert werden.
  • Eine einzige Quelle der Wahrheit, die eine bessere betriebliche Effizienz, standardisierte Prozesse und weniger Fehleranfälligkeit und Konsistenz ermöglicht.
  • Bessere betriebliche Effizienz.
  • Bessere Transparenz über alle Clouds und On-Premises hinweg.


Ein Schlüsselelement für den Erfolg ist die Schließung der Qualifikationslücken. Die obige Tabelle zeigt, dass es in allen Kompetenzbereichen Herausforderungen gibt. Diese können angegangen werden, indem Teams zusammengebracht werden, um Fähigkeiten und Erkenntnisse bei der Arbeit an einem gemeinsamen Rahmen für die Anwendungsbereitstellung zu teilen. Hier sind drei Vorteile dieses Ansatzes:

  • Die DevOps-Mitarbeiter können den Netzwerk- und Sicherheitsteams Anwendungseinblicke vermitteln.
  • DevOps-Teams können Einblicke in Sicherheitsherausforderungen gewinnen.
  • Cloud-spezifische Herausforderungen beim Load-Balancing werden minimiert.

DevOps und NetOps zusammenzubringen, ist eine organisatorische Herausforderung. Es mag schwierig sein, da Teams in ihrer eigenen Sicht auf die Welt verwurzelt sind, aber die Vorteile können erheblich sein und zu einer effizienteren Bereitstellung von Diensten und einer besseren Erfahrung für die Benutzer führen.

Erfahren Sie mehr über DevOps- und NetOps-Synergien durch Teamintegration 


(Maurice McMullin hat zu diesem Bericht beigetragen.)