Die digitale Transformation ist eine unternehmerische Reise, die mit einer technologischen Weiterentwicklung einhergeht. Im Verlauf dieser Reise wird das digitale Geschäft durch den operativen Übergang von manuellen Methoden zu automatisierten Abläufen ermöglicht.
Auch wenn sicherheitsbezogene Technologien bei dieser Automatisierung aufgrund der ständigen Weiterentwicklung der Angreifer möglicherweise eine Vorreiterrolle einnehmen, liegt der IT-Betrieb tatsächlich gar nicht so weit zurück. Man denke beispielsweise daran, wie sehr wir uns auf die automatische Skalierung verlassen, um digitale Kapazitäten bei Bedarf zu erweitern. Früher wurde kontrovers darüber diskutiert, ob externe Systeme die Kapazitäten für digitale Ressourcen verwalten sollten.
Im Ernst.
Heute stellt sich diese Frage gar nicht mehr. Wir akzeptieren Auto-Scaling-Funktionen nicht nur, sondern erwarten sie als Bestandteil unseres Infrastruktur-Stacks.
Daher erscheint die Annahme durchaus logisch, dass ein höherer Automatisierungsgrad irgendwann als Grundvoraussetzung gelten wird. Früher oder später wird der Nutzen einer manuellen Verwaltung der Ressourcen, die digitale Erlebnisse bereitstellen und absichern, immer weiter abnehmen und einen Wandel hin zu mehr Vertrauen in die Technologie erforderlich machen.
Wir wissen, dass ein Infrastructure-as-Code-Ansatz (IaC) von großem Nutzen ist. Unsere Untersuchungen haben erhebliche Vorteile gezeigt: Unternehmen, die IaC einsetzen, stellen deutlich häufiger neue Versionen bereit. Mehr als die Hälfte (52 %) der Unternehmen behandelt ihre Infrastruktur als Code. Bei diesen Unternehmen ist die Wahrscheinlichkeit, häufiger neue Versionen bereitzustellen, mehr als doppelt so hoch. Noch wichtiger ist, dass die Wahrscheinlichkeit, über vollständig automatisierte Pipelines für die Anwendungsbereitstellung zu verfügen, viermal so hoch ist.
Dieser Zusammenhang ist besonders wichtig, da dies zu einer entscheidenden Fähigkeit für Unternehmen wird, die von den geschäftlichen Vorteilen adaptiver Anwendungen profitieren möchten.
Ereignisgesteuerte Infrastructure as Code
Der Unterschied zwischen Infrastructure as Code und ereignisgesteuerter Infrastructure as Code besteht im Wesentlichen darin, wodurch eine Bereitstellung ausgelöst wird.
Die meisten Unternehmen wechseln von manuellen Methoden zur Automatisierung mit Infrastructure as Code, behalten aber weiterhin die Kontrolle über die Bereitstellungen. Das heißt, zum Auslösen einer Bereitstellung ist nach wie vor ein Bediener erforderlich. Es handelt sich um eine Bereitstellung per Knopfdruck.
Bei einem ereignisgesteuerten Ansatz wird der Auslöser auf Grundlage eines Ereignisses automatisiert. Betrachten wir erneut die automatische Skalierung als Beispiel. Die eigentliche Bereitstellung der Konfigurationsänderungen und zusätzlichen Workloads wird durch ein Ereignis ausgelöst – häufig dann, wenn die Anzahl der gleichzeitigen Verbindungen einen zuvor festgelegten Schwellenwert überschritten hat. Dieses Ereignis – das Überschreiten eines definierten Grenzwerts – löst einen automatisierten Workflow aus.
Stellen Sie sich nun vor, dieser Prozess würde auf eine gesamte Anwendung ausgeweitet. Das umfasst alle Workloads und zugehörigen Technologiedienste, die für die Bereitstellung und Absicherung der Anwendung sorgen. Das auslösende Ereignis ist nun, dass die Leistung unter das Niveau fällt, das ein akzeptables digitales Erlebnis ausmacht. Dieses Ereignis signalisiert, dass eine „Anwendung“ automatisch auf der anderen Seite der Welt bereitgestellt werden muss, und löst einen automatisierten Workflow aus, der genau das an einem vollständig entfernten Standort erledigt.
Das ist keine (Computer-)Science-Fiction. Eine gesamte Anwendung – einschließlich ihrer Workloads, Infrastruktur und unterstützenden Dienste – wird häufig auf diese Weise automatisiert mithilfe von Orchestrierungswerkzeugen wie Terraform in einer Public Cloud bereitgestellt. Konfigurationsartefakte werden aus einem Repository, Container aus einer Bibliothek und Geheimnisse (Zertifikate und Schlüssel) aus einem sicheren Tresor abgerufen. Automatisch. Das ist der Kern von Infrastructure as Code: Konfigurationen, Richtlinien und Geheimnisse werden wie Codeartefakte behandelt, um die Bereitstellungspipeline zu automatisieren.
Was heute noch nicht automatisiert ist, ist der Auslöser. Derzeit lautet das Ereignis: „Der Bediener hat den Knopf gedrückt/den Befehl eingegeben.“ In Zukunft wird das Ereignis durch die Tageszeit, die Nachfrage an einem bestimmten Standort oder die Leistung in einer geografischen Region bestimmt.
Dies trägt wesentlich dazu bei, dass Anwendungen künftig adaptiv sein werden: Sie können automatisch auf Ereignisse reagieren und Standort, Sicherheit und Kapazität anpassen, um Service-Level-Ziele zu erreichen. Edge 2.0 wird mit seiner einheitlichen Steuerungsebene Unternehmen ermöglichen, Ressourcen über mehrere Clouds, Edge-Umgebungen und das Rechenzentrum hinweg zu nutzen, um dieses Ziel zu erreichen.
Ereignisgesteuerte Infrastructure as Code wird eine entscheidende Voraussetzung dafür sein, die Vorteile adaptiver Anwendungen für das Unternehmen nutzbar zu machen.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.