Wie bereits im ersten Teil des Artikels beschrieben, kann sich in einem Unternehmen innerhalb des Lizenzmanagements sehr viel ändern, je nachdem was sich im Einsatz befindet und wie man einzelne Komponenten betrachtet. Im Fall von reinen Userlizenzen in der Cloud handelt es sich noch um einfache Zählweisen und auch um einfach zu adaptierende Lizenzmodelle.

Auf Ebene der Serverlizenzierung sieht das ganz anders aus. Warum eigentlich? Und wie werden die Lizenzmodelle der Zukunft aussehen? Oder können wir in diesem Kontext überhaupt noch von „Lizenzen“ sprechen?

Wie eine einfache Erfindung die Transportwelt revolutioniert

Im Jahre 1956 war es soweit: Zum ersten Mal war ein Schiff mit den heute bekannten Containern unterwegs auf der Reise von Newark nach Houston. Dass diese Erfindung ab diesem Zeitpunkt die Transportwelt verändern sollte, war jedoch erstmal nicht klar. Auch wenn erst zehn Jahre später die ersten dieser Container am Bremer Hafen umgeschlagen wurden, sind sie heute aus dem weltweiten Güterverkehr nicht mehr wegzudenken. Doch was hat das alles mit Lizenzierung, Cloud und Co. zu tun? Es könnte sich ein nächstes Zeitalter anbahnen, in denen Container die Welt verändern! Jedoch dieses Mal nicht in der Transportindustrie, sondern in der IT.

Kubernetes, Docker, OpenShift – Der neue Containerhafen

Vor allem in der heutigen schnelllebigen Welt ist es notwendig, auch innerhalb der IT schnell auf Bedürfnisse zu reagieren. „Time to Market“ ist hier das eigentliche Schlagwort. Also: Wie lange dauert es, bis eine neue Funktion innerhalb meiner Software den Weg in die produktive Umgebung findet. In einer Zeit, in der jede noch so kleine Firma relativ schnell eine Infrastruktur zur Verfügung gestellt bekommen kann (siehe Amazon Web Services (AWS), Google Cloud, Microsoft Azure, etc.) kommen vor allem die großen, oft unbeweglichen Containerschiffe der Industrie mit der Innovation nicht mehr hinterher, da sie mit aufwändigen Releasezyklen und Testszenarien zu kämpfen haben. Die kleinen Containerschiffe setzen zum Überholmanöver an! Man vergleiche nur die starren deutschen Banken in Konkurrenz zu den agilen Modellen einer Wirecard oder N26.

Vor allem diese Techfirmen haben den Trend bereits frühzeitig erkannt und an Lösungen hierfür gearbeitet. Wer sich heute mit Entwicklern dieser Firmen unterhält, bemerkt schnell, dass hier oftmals im Kontext DevOps (Development + IT Operations) über ein Continuous Deployment, also eine kontinuierliche Releasemöglichkeit, gesprochen wird; dass dies auf Basis der alt eingesessenen Technik nicht machbar ist, war schnell klar. Lösungen mussten her, wie man von einem Source Code schnell ein Testsystem aufbauen und etablieren kann um dann, nach erfolgreichem Test, dieses schnellstmöglich in eine Produktion zu spielen.

Das wohl wichtigste Ergebnis dieser Lösungsfindung ist Kubernetes, von einigen Google Mitarbeitern im Jahr 2014 erstmals veröffentlicht und mittlerweile der De Facto Standard in allen Cloud Umgebungen, aber auch in proprietären Ablegern wie OpenShift von Red Hat. Das System an sich wurde unter der Open Source Apache 2.0 Lizenz veröffentlicht. Ziel dieser Master/Slave Architektur ist es, sogenannte Pods als kleinste Menge der Architektur auf Basis der Vorgaben eines Kubernetes Masters zu deployen. Diese Pods laufen auf dedizierten Kubernetes Nodes, die innerhalb eines Rechenzentrums oder eines Cloud Anbieters konfiguriert sind und auf Basis eines vorher gebauten Container Images diesen jeweiligen Container als 1-n Pods über mehrere Instanzen hinweg deployen und orchestrieren. Dies ermöglicht vor allem eine ausgeklügelte Lastverteilung durch automatische Podskalierung, aber natürlich auch ein hervorragendes High Availability Konzept.

Es war einmal VMware

Vor allem die Skalierung sowie das High Availability (HA) nagen an den Vorzügen von VMware. VMware basiert immer noch auf der Annahme, ein dediziertes System inkl. Vorgaben bzgl. CPU, RAM, HDs sowie der dort zu tätigenden Installationen aufzusetzen. Hier wird nicht auf ein Minimum reduziert und man bewegt sich zwangsläufig nur in seiner eigenen Umgebung. Des Weiteren ist diese VMware Umgebung immer verfügbar, da sie lokal im eigenen Rechenzentrum auf den dafür notwendigen physischen Maschinen aufgebaut wurde. Was erstmal als ein großer Vorteil klingt, wird später zu einem Nachteil, doch darauf wird später noch eingegangen. Zwar versucht VMware nun, mit vSphere Integrated Containers auf den selben Zug aufzuspringen, jedoch sind alleine durch die flexible Nutzung von Kubernetes vor allem in den Cloud Umgebungen fast keine Grenzen gesetzt. Die Frage hier ist vor allem: In welchem Szenario bewege ich mich und brauche ich VMware, als eine der größten Kostentreiber im Lizenzmanagement, überhaupt noch?

Was heißt das jetzt alles für die Lizenzierung?

Vor allem in Projekten, in denen häufige Eigenentwicklungen im Fokus stehen, wird man frühzeitig Entscheidungen treffen müssen. Wo liegt meine Entwicklungsumgebung? Muss ich hierfür noch eigene Hardware, ja gar Platz in einem Rechenzentrum verschwenden? Das gleiche gilt für die Testumgebungen, in denen ich meine funktionalen Tests durchführen möchte. Doch ein wichtiger Aspekt kommt hier noch mit dazu: Wie werden die tatsächlichen Kosten in diesen Szenarien eigentlich berechnet?

Im klassischen Setup besteht meine IT Infrastruktur aus einem großen Batzen an fixen Kosten. Dazu zählt zu einem Großteil die Hardware, aber auch die jeweiligen Lizenzen + Wartung & Support sowie die Rechenzentrumsleistungen (Housing, Strom, Security, etc.). Diese fixen Kosten hat man immer, ob das System nun genutzt wird oder nicht. In den neueren Strukturen sieht dies völlig anders aus! Denn: Die Infrastruktur, die man in einer Cloud bezieht, wird nach der tatsächlichen Last bezahlt, die man mit dem System erzeugt. Nutzen die Entwickler die Platform nur zu ihren Arbeitszeiten, also von 9-18 Uhr? Wunderbar: Man kann die Entwicklungssysteme dann eben nur in dieser Zeit hochfahren und muss auch nur diese Zeit bezahlen! Gleiches gilt natürlich ebenso für die Testumgebungen.

In unseren Kundenkontexten kommt es dabei häufig zu genau diesem Szenario:

  • Entwicklungsumgebung in der Cloud
  • Funktionale Testumgebung in der Cloud
  • Lasttestumgebung in einem dedizierten Rechenzentrum (Produktionsgleich)
  • Produktionsumgebung in einem dedizierten Rechenzentrum

Darüber hinaus bieten die Cloudanbieter bereits Modelle an, bei denen ebenfalls die notwendigen Lizenzen on demand bereitgestellt werden. Ich zahle also selbst bei den Lizenzen nur noch dann, wenn ich das System tatsächlich nutze! Im Normalfall können auch bestehende Lizenzverträge und Lizenzen zu einem Cloudanbieter mitgebracht werden. Jedoch hat sich herausgestellt, dass es notwendig ist, die jeweiligen Lizenzmodelle und Nutzungsbedingungen genau zu prüfen. In diversen Szenarien haben wir mit unseren Kunden bereits festgestellt, dass eine Nutzung in der Cloud mit sehr großen Hürden verbunden war, die wir jedoch in den meisten Fällen klären und neu verhandeln konnten.

Natürlich ist es in diesem Kontext wichtig, die Gesamtkosten korrekt zu berechnen. Man tendiert dazu, blind alles in die Cloud zu verlegen, um dann doch später zu merken, dass es anders hätte kostengünstiger und praktikabler sein können. Dabei sind vor allem die folgenden Fragestellungen zu beantworten:

  • Volle Cloudintegration oder umgebungsspezifisches Deployment?
  • Zu welcher Zeit benötige ich welche Umgebung?
  • Will ich die Lizenzen vom Cloudanbieter on demand erwerben?
  • Will ich meine eigenen Lizenzen nutzen?

Diese Fragen sind in aller Ruhe zu beantworten und auch dazugehörige Modellrechnungen anzustellen. Wichtig dabei: Den Gesamtfokus im Blick haben! Lasse ich mir z. B. alle Lizenzen vom Cloudanbieter on demand bereitstellen, kann ich mir für diese Dinge das Lizenzmanagement sparen, da es vom Anbieter selbst durchgeführt wird. Dies resultiert natürlich in einem deutlichen reduzierten Aufwand für das Verwalten der jeweiligen Lizenzen. Auf der anderen Seite nehme ich meine Verträge und Konditionen nicht mit.

Schnell deployen heißt auch: Schnell sehr teuer bzw. incompliant!

Beim Deployment sind mir standardmäßig keinerlei Schranken geboten. Ich kann alles deployen, was ich entweder selber als Container mit eigenem Source Code gebaut habe oder ich benutze einen vorgefertigten Container, wie es sie zu Hauf bei Dockerhub gibt (https://hub.docker.com/).

Nun gibt es in diesem Kontext häufig den folgenden Satz: Out of Scope, Out of Control! Hat jeder Entwickler die Möglichkeit, ein Deployment zu starten, kann es schnell dazu kommen, dass extrem viele Ressourcen innerhalb der Cloud zur Verfügung gestellt werden, was wiederrum zu nicht geplanten Kosten führt. Hier ist es wichtig, die Grenzen vor allem auch auf prozessualer Ebene einzubeziehen. Des Weiteren ergeben sich auch potentielle Risiken, sofern die Lizenzen durch den Kunden mit eingebracht werden. Insbesondere muss ganz klar definiert werden, wie viele Instanzen einer bestimmten Software oder des OS (vor allem bei Microsoft) genutzt werden können.

Darüber hinaus kann es natürlich vorkommen, dass ein Entwickler etwas deployed, was eigentlich ein lizenzpflichtiges Produkt wäre. Sollte dies innerhalb des Deployments, also außerhalb der Verantwortung des Cloudanbieters liegen, hat der Kunde diese Lizenz selbst nachzuweisen. Oftmals kommt es hier aber zu unwissenden Lizenzverstößen seitens des Entwicklers. Vor allem bei Produkten wie Confluence, GitLab oder Artifactory ist ein zugehöriger Lizenzschlüssel notwendig, die das potentielle Risiko einer Incompliance zumindest  reduzieren können. Hier ist bei den Entwicklern zu diesem Thema dringend eine Awareness zu schaffen! Die größten Gefahren lauern aber anderswo.

OpenSource als Compliancefalle

Vor allem OpenSource Software ist als große Compliancefalle bekannt, besonders wenn es um die Nutzung von unter GPL lizenzierter Software geht. Entwickler tendieren zurecht dazu, bestehende Codeschnipsel zu nutzen. Jedoch wird dabei häufig nicht das zugrunde liegende Lizenzmodell betrachtet und erst recht nicht die sich dadurch ergebenden Folgen für den eigenen Sourcecode. Da dieses Thema so komplex ist, werden wir in einem weiteren Blog Artikel dieses Thema nochmal genauer beleuchten. Falls Sie in der Zwischenzeit bereits Fragen zu diesem Thema haben, können Sie sich gerne an uns wenden!

Die Lizenzmodelle ziehen nicht nach!

Bereits bei der Transition von dedizierter Hardware zu VMware Lösungen gab es eine lange Zeit eine Grauzone in der Lizenzierung. Vor allem Microsoft, Oracle und IBM zogen erst mit einiger Verzögerung ihre Lizenzmodelle gerade. Das gleiche gilt aktuell für das Container Deployment. Durch die massiven Skalierungsmöglichkeiten dieser Lösungen ergeben sich völlig andere Nutzungsszenarien, die von wenigen Herstellern bislang angegangen wurden. Red Hat ist hier natürlich federführend unterwegs, liefert aber auch mit OpenShift eine der etabliertesten „proprietären“ Containerlösungen und hat deshalb auch lizenztechnisch eine Lieferpflicht einzuhalten. Wie sich dies jetzt durch die Übernahme von IBM darstellen wird (wir berichteten: https://sam.news/news-ibm-uebernimmt-redhat/) bleibt natürlich abzuwarten. Hoffen kann man nur das Beste!

Wie es hier weitergeht ist daher aktuell noch fraglich. Eine Lizenzierung auf Basis von Cores ist fragwürdig, da man auf einer kleinteiligen Plattform eines Pods bereits in Segmentierung des tatsächlichen Cores denken muss. In OpenShift reden wir hier zum Beispiel von Millicores bei denen ein Core 1000 Millicores entspricht, die ich ressourcentechnisch verteilen kann. Das gleiche gilt für Lizenzmodelle eines physischen Clusters, welches natürlich vor allem bei einer Nutzung innerhalb der Cloud schwierig wird. Eine Lizenzierung auf Basis der tatsächlichen Nutzung (bei Nutzung eigener Verträge und somit Einbringen der eigenen Lizenzen) ist eine faire Behandlung der neuen Modelle, könnte aber schnell zu einer Kostenfalle und auch einer Transparenzfalle werden. Dies liegt vor allem daran, da ich diesbezüglich den Herstellern gewisse Rechte einräumen muss, die tatsächliche Nutzung – wohlmöglich noch durch herstellereigene Tools – nachzuweisen.

Aus Compliance Sicht ist es am empfehlenswertesten die Angebote der Cloudanbieter zu nutzen und sich die Lizenzen auf Basis der Nutzung beistellen zu lassen. Zumindest bewegt man sich dort dann in einem relativ ruhigen Fahrwasser. Für größere Kunden könnte dieswiederum ein Problem darstellen, da sie ihre mühsam ausgehandelten Verträge mit sehr guten Konditionen und ggf. ihren Lizenzpool nicht einbringen können. Eine Risiko/Kostenanalyse ist hier definitiv von Nöten.

Wie im Transportwesen: Die Revolution braucht Zeit

Wie bereits damals, als die Container die Transportwelt revolutionierten, braucht es auch hier eine gewisse Zeit, bis eine bahnbrechende Technik sich tatsächlich durchsetzt bzw. breiten Anklang findet. Es funktioniert! Das zeigen vor allem die großen Techfirmen, aber auch viele Start-Ups auf der ganzen Welt. Ein weiteres großes Problem, dass vor allem die Lizenzmodelle noch nicht da sind, wo sie für so eine Technik sein sollten, hat bereits die Vergangenheit gezeigt. Jedoch wird im immer weiterwachsenden Cloudgeschäft dieses Thema in den nächsten Jahren sehr spannend bleiben.

Stehen Sie vor der Entscheidung, ihre IT neu zu organisieren? Ihre Entwicklungseinheiten, Tester und Operational Teams in DevOps Einheiten zu bündeln? Denken Sie dabei auch an die unterschiedlichen Modelle, die Ihnen die Cloud oder die neuen Produkte ggf. auch in Ihrem eigenen Rechenzentrum bieten können. Das Lizenzmanagement der Zukunft wird immer mehr zu einem Service Management. Das für viele lästige Erbsenzählen könnte durch diese neuen Modelle immer mehr in den Hintergrund rücken. Die Frage die hier eigentlich nur offen bleibt ist: Zu welchem Preis? Es gibt viel zu lernen, vieles mitzugestalten und vieles zu ändern! Lassen Sie uns zusammen den großen Kahn mit Containern bestücken und in ruhiges Fahrwasser führen!