Als die Cloud zum ersten Mal aufkam, gab es viele, die ihre turbulenten Auswirkungen auf Unternehmen vorhersagten. Viele betrachten die bevorstehende Disruption im Hinblick auf ihre Auswirkungen auf den traditionellen Infrastrukturmarkt, da der Übergang von einem greifbaren Produkt zu einem nahezu flüchtigen Produkt sehr schwierig ist. Und obwohl das stimmt, war es eine holprige Fahrt, da der Infrastrukturmarkt wieder zu einer softwarebasierten Perspektive mit Blick auf die Cloud zurückkehrt (beachten Sie, dass es sich um eine Rückkehr und nicht um eine Transformation handelt).
Weniger Experten stellten fest, dass es nicht nur in der physischen Welt zu Umbrüchen komme, sondern auch in der Geschäftswelt. Cloud und ein stärker softwareorientierter Ansatz zum Aufbau der Netzwerke und Infrastruktur, die für den Erfolg in einer Anwendungs- (und API-)Ökonomie erforderlich sind, erforderten auch eine Änderung der Geschäftsmodelle. Insbesondere, wie die unzähligen Netzwerk- und Infrastrukturkomponenten verwaltet wurden – einschließlich der Lizenzierung.
Sie sehen, die Lizenzierung einer einzelnen Box ist (vergleichsweise) einfach. Eine Lizenz wird gekauft, beantragt und voilà! Es gehört dir. Aber Software war noch nie (und ich meine noch nie ) so einfach. Einige von Ihnen erinnern sich vielleicht noch an den Sturm, der Anfang der 2000er Jahre von gewissen Softwaregiganten entfacht wurde, die ziemlich verzweifelt versuchten, das seit Jahren verwendete Single-CPU-Lizenzmodell auf einen mathematischen Albtraum mit mehreren CPUs und mehreren Kernen umzustellen, den nicht einmal die „neue Mathematik“ so leicht lösen konnte.
Dasselbe passierte mit der Cloud. Das Abrechnungsmodell auf Utility-Basis machte die Rückkehr zur Software viel schwieriger, als einfach etwas Code so zu optimieren, dass er in einen virtuellen oder Cloud-basierten Hypervisor passte.
Nun kommt DevOps mit seinem Konzept der „Kontinuität“ aller Abläufe auf den Markt, und plötzlich stellt die Lizenzierung eine erhebliche Hürde dar, die der Netzwerk- und Infrastrukturmarkt überwinden muss. Problematisch ist nicht nur die Geschwindigkeit, mit der Netzwerk- und Infrastrukturdienste plötzlich bereitgestellt und konfiguriert werden müssen, sondern auch die Änderungsrate. Früher haben Sie eine Infrastrukturkomponente bereitgestellt und sie blieb dort, wo sie war. Doch mittlerweile stellen Sie zahlreiche Infrastrukturkomponenten bereit, manchmal mehrmals am Tag/in der Woche/im Monat. Die Häufigkeit der Änderungen nimmt zu und die Nachfrage nach diesen Änderungen schleicht sich (zwangsläufig) in das Netzwerk ein. Continuous Integration (CI) und Continuous Delivery (CD) fallen in den Zuständigkeitsbereich der App-Entwicklung und des App-Betriebs. Allerdings erfordert kontinuierliche Bereitstellung eine Zusammenarbeit über das gesamte Spektrum der Softwarebereitstellung hinweg – und das bedeutet auch die Produktion.
Das Testen zu einem früheren Zeitpunkt in dieser Pipeline (z. B. im Test oder in der Qualitätssicherung, nicht in der Produktion) ist von entscheidender Bedeutung, um nicht nur schnelle, sondern auch zuverlässige Bereitstellungen zu erreichen. Bereitstellungen, die den Entwicklern keine Zeit rauben, weil sie aufgrund von Unterschieden in der Netzwerk- und Infrastrukturarchitektur in der Produktion auf Probleme stoßen.
Ein flexibler, softwaregesteuerter Ansatz zur Lizenzierung kann diese Herausforderung sowie den Bedarf an mehr Agilität im Produktionsnetzwerk mildern. Durch die Bereitstellung von Mitteln zum Bündeln, zentralen Verwalten und Verteilen von Lizenzen mithilfe eines einfachen API-Aufrufs können Unternehmen Entwicklung und Produktion angleichen (wichtig für Zuverlässigkeit und Konsistenz) und gleichzeitig die erforderliche Skalierung der Produktion bei der Verwendung von Softwareversionen von Netzwerk- und Infrastrukturplattformen unterstützen.
Aus diesem Grund unterstützen sowohl BIG-IQ 5.0 als auch iWorkflow 2.0 die agile Lizenzierung für Tausende von BIG-IP-Instanzen. Die Notwendigkeit, Lizenzen zu verwalten (aber nicht notwendigerweise die lizenzierten Instanzen) ist von größter Bedeutung, um Entwicklung und Betrieb in die Lage zu versetzen, früher in den Bereitstellungsphasen vor der Produktion zu integrieren und zu testen. BIG-IQ 5.0 konzentriert sich zwar auf die Verwaltung von BIG-IP, kann aber auch die Lizenzen für bis zu 5000 BIG-IP-Instanzen in einem flexiblen Modell verwalten, das die schnelleren, agileren Entwicklungsumgebungen unterstützt, die heute von DevOps geschaffen werden. Dies ist insbesondere deshalb wichtig, weil sich Architekturen weiterentwickeln und App-Dienste wie der Lastenausgleich immer enger mit Apps (und Microservices) als Teil der Architektur verknüpft werden und nicht mehr als externe „Anbaueinheiten“ dienen.
Die mit der Cloud verbundenen Umbrüche sind sowohl im Betriebs- als auch im Geschäftsmodell noch heute spürbar. Es muss jedoch mehr sein als nur ein „Platzieren Sie Ihren Code in einer VM/einem Container“-Ansatz. Darüber hinaus muss es sich an die veränderten Geschäftsmodelle anpassen, die durch die Cloud entstanden sind und die vielleicht unbeabsichtigt dazu geführt haben, dass dies auch in absehbarer Zukunft so bleiben wird. F5 BIG-IP 5.0 und iWorkflow 2.0 sind so konzipiert, dass sie sich in diesen „Weg“ einfügen und sicherstellen, dass die benötigten App-Dienste umgehend bereitgestellt werden, wenn Unternehmen diese Grundlage in ihren eigenen Rechenzentren übernehmen – egal, ob diese physisch oder flüchtig sind.