Unter den Wolken...

Beyond Cloud: Public Cloud, ja oder nein?

Torsten Köster

© Shutterstock / mindscanner

„Public Cloud, ja oder nein?“ – Eine Frage, radikal überholt vom Zug der Technik. Mehr und mehr Unternehmen beschäftigen sich mit den Vor- und Nachteilen einer Public-Cloud-Infrastruktur. Vorteile hat die Public Cloud ohne Zweifel. Für bestimmte Anwendungen ist ihre Elastizität, hohe Fertigungstiefe und globale Verteilung wie geschaffen. Allerdings wird dies von den wenigsten Anwendungen wirklich benötigt und genau hier lohnt es sich, genauer hinzuschauen.

DevOps Conference 2018

Wer Torsten Köster einmal live erleben möchte, der hat die Chance auf der diesjährigen DevOps Conference 2018 in München Gelegenheit dazu. Am Mittwoch, 05. Dezember hält er dort seinen Vortrag mit dem Titel „Beyond Cloud: A road trip into AWS and back to bare metal“. Darin erzählt er von der Reise des Unternehmens Shopping24 in die Cloud und wieder zurück auf Bare-Metal-Systeme. Dabei geht er auf die Vor- bzw. Nachteile von Cloud-Infrastrukturen ein und zeigt, wie man Automatisierung auch mit klassischen Datenzentren durchführen kann. Und natürlich, welche Rolle Kubernetes dabei spielt.

Kosten & Kostentransparenz

Transparenter als auf den Webseiten der Cloud-Anbieter können Preise nicht ausgewiesen sein. Und das Beste: Man zahlt nur die Ressourcen, die man auch wirklich verbraucht, dazu noch in einer kleinteiligen Taktung – ideal, oder?

Vielleicht blenden die geringen Einzelpreise. Die errechnete Summe aus dem Gesamtkostenrechner aber taugt meist nur zu einer groben Vorhersage. Wie bei jedem Infrastruktur-Sizing weichen tatsächlich benötigte Ressourcen teilweise deutlich von den errechneten ab. Dazu ergeben sich viele Details erst im laufenden Betrieb. Bei verteilten Anwendungen (und welche Anwendung ist das heute nicht?) ist Netzwerkdurchsatz das entscheidende Skalierungswerkzeug. Ein stabiles 10G-Netzwerk ist unerlässlich, ist aber z.B. bei Amazon AWS erst bei den großen (also teuren) Instanzgrößen verfügbar.

DevOps-Kultur

Public Cloud ist ein Katalysator für die DevOps-Kultur. Jedem Entwickler brennt es wohl unter den Fingernägeln, zumindest testweise ganze Server-Cluster inklusive Networking zu stanzen und seine Anwendung unter Live-Bedinungen zu testen. Besser geht es nicht!

Bis eine Organisation dies leisten kann, muss sie große Schritte in Richtung „DevOps-Kultur“ gehen. Dazu gehört wahrlich keine dedizierte DevOps-Stelle oder gar DevOps-Abteilung, sondern nichts weniger als der Abriss der Mauer zwischen Entwicklung und Betrieb sowie die Einsicht, dass Operations keine dunkle Magie, sondern auch nur Softwareentwicklung ist (halt in Ansible, Puppet oder Konsorten).

Besonders eindrucksvoll kann eine Organisation am dann gerne ausgerufenen Credo „You build it, you run it“ scheitern. Der Pager wandert ins Entwicklungsteam und nach dem ersten Pageralarm um drei Uhr nachts ändern sich Prioritäten schlagartig. Im schlechtesten Fall werden Arbeitsverträge und Betriebsvereinbarungen studiert, im besten Fall gemeinsam mit Operations an Skalierung, der Continuous-Delivery-Pipeline und der Testing-Pyramide gearbeitet.

Das Wissen über moderne verteilte Anwendungen befindet sich in den Köpfen der Entwickler. Wenn es hart auf hart kommt, müssen sie ihre Anwendung wieder aus dem Schlamm ziehen. Dabei ist Ops-Wissen in der Softwareentwicklung extrem wichtig: Wie überwache ich meine Anwendung? Wie skaliere ich bei Lastspitzen?

Aber auch in Operations sind moderne Entwicklungsmethoden unverzichtbar. Die vollständige Eleminierung der „Snowflakes“, dieser unter obskuren Umständen von Hand zusammenkonfigurierten Server, sollte das Ziel sein. Der SSH-Login auf einem Server muss zum Anti-Pattern erhoben werden. Auf dem Weg lassen sich viele Methoden aus der Softwareentwicklung übernehmen (Versionskontrolle, Tests, Continuous Delivery), denn die Benutzung von Ansible, Puppet und Co ist – Überraschung – hauptsächlich Softwareentwicklung.

Lock-in-Effekt

Gefühlt verdoppelt sich Anzahl und Fertigungstiefe der Dienste bei Amazon AWS nach jeder Re:Invent-Konferenz. Spezialisierte Dienste wie Lambda oder Sagemaker entfernen überflüssigen Boilerplate-Code und ermöglichen einen einmalig schnellen Start in komplexen Themen.

Doch die Fertigungstiefe hat ihren (nicht nur monetären) Preis. Mangels offener Schnittstellen lassen sich Anwendungen nur auf dem Dienst des einen Anbieters betreiben. Querschnittsaspekte wie Logging und Monitoring (z.B. in Lambda-Umgebungen) vervollständigen den Vendor-Lock-in. Mit dem vorher noch so attraktiven Cloud-Anbieter hat man sich möglicherweise ein Microsoft der 2000er oder ein IBM/SAP der 2010er ins Haus geholt.

Single-Vendor

Oftmals wirkt Amazon AWS als Synonym für „Public Cloud“, doch auch andere Anbieter bieten in den Basisdiensten Compute und Storage mit absolut vergleichbarer Leistung. Wer von Anfang an auf mehrere Cloud-Anbieter setzt, minimiert nicht nur den Vendor-Lock-in, sondern erhöht seine Ausfallsicherheit enorm.

Beyond Cloud

Weshalb aber ist die Frage nach der Public Cloud meiner Meinung nach überholt? Betrachtet man die Entwicklungen moderner Container-Scheduler, allen voran Kubernetes, erkennt man, dass diese ideal sind, eine Klammer um beliebige Infrastrukturen zu bilden.

Denn eigentlich möchte sich niemand damit beschäftigen, auf welchem Host in welchem seiner Datacenter seine Anwendung nun läuft. Eigentlich soll sie einfach nur laufen – mit den Ressourcen, die sie benötigt sowie der Redundanz und Verteilung, die einen sicheren Betrieb ermöglichen. Genau das bieten Container-Scheduler als Bonus ganz ohne Lock-in-Effekt. Der Scheduler bietet ein einheitliches Deployment- and Administrations-API für meine gesamte Infrastruktur. Kubernetes läuft auf beliebiger Compute-Hardware und so fungiert das Datacenter (Public, Private Cloud oder Bare Metal) nur noch als CPU-, GPU- und RAM-Lieferant für meine Kubernetes-Cluster.

Ach ja: Und die Antwort auf die Eingangsfrage lautet ganz klar „jein“ 😉

Geschrieben von
Torsten Köster
Torsten Köster
Torsten Köster ist CTO der Shopping24 GmbH und verantwortet dort Entwicklung und Betrieb der hauseigenen Produktsuchen. Aktuell beschäftigt er sich mit innovativen, schlanken Technologien rund um Suche und Event-Stream-Processing.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: