Interview mit Torsten Köster

Warum Cloud kein Allheilmittel ist & AWS alleine nicht die IT modernisiert

Dominik Mohilo

Torsten Köster

Die Public-Cloud ist inzwischen angekommen, und das so ziemlich überall. Auch Torsten Köster, CTO der Shopping24 GmbH, kann ein Lied davon singen. Im Interview zur W-JAX 2017 in München spricht er über die Vorteile einer Cloud-Lösung, worauf Unternehmen beim Umzug achten müssen und wie sich die Prinzipien einer Public-Cloud-Infrastruktur auf „Blechserversysteme“ übertragen lassen.

JAXenter: Hallo Torsten und danke, dass du dir die Zeit genommen hast. Immer mehr Unternehmen setzen auf die Cloud und besonders Amazon AWS sticht als Lösung heraus, auch ihr seid mit euren Systemen dorthin gewechselt. Welche Vorteile hat diese Auslagerung?

Torsten Köster: Amazon AWS hat sich sicherlich als de-facto-Standard im Cloud-Computing etabliert. Wir haben 2011 damit begonnen, unsere Auslieferung von Produktbildern nach AWS zu verlagern. Für weiteres Wachstum hätten wir bei unserem klassischen Hoster in einen extrem teuren Fileserver mit langen Vertragslaufzeiten investieren müssen. Gerade in der Startup-Welt mit unwägbaren Geschäftsmodellen sind lange Vertragsbindungen Gift und da kamen die Amazon-Dienste S3, EC2 und CloudFront wie gerufen. Für uns war es damals ein Ausbrechen und Aufatmen aus dem starren Hostingkorsett, das über die Jahre mit einem festen Dienstleister gewachsen war. Auf einmal waren wir in der Lage, das die Umsetzungsgeschwindigkeit im Hosting in Einklang mit der Softwareentwicklung zu bringen. Wir konnten mit Server-Setups experimentieren, ohne direkt Blech für Jahre fest zu bestellen.

Auf der anderen Seite hatten wir das, was ich liebevoll „Ryanair-Hosting“ nenne. Wir mussten bei AWS im Hosting (EC2) und im Netzwerk (VPC) alles selber machen. Für einen stabilen Produktivbetrieb war das eine ganz schön steile Lernkurve mit – sagen wir mal – nicht ganz so schönen Lernmomenten.

JAXenter: Worauf sollten Unternehmen besonders achten, wenn sie den Umzug in die Cloud anstreben?

Cloud-Computing ist kein „neues Rechenzentrum“, sondern folgt seinen eigenen Gesetzen.

Torsten Köster: Cloud-Computing ist nicht „ein neues Rechenzentrum“, sondern folgt seinen eigenen Gesetzen. Man benötigt eine vollständige Automatisierung der Server-Provisionierung, z.B. mit Puppet, Chef oder Ansible. Anders lässt sich der Cloud-Grundsatz „Cattle not Pets“ nicht umsetzen. Server werden nicht mehr wie Haustiere gehegt und gepflegt, sondern nach einem Deployment oder bei der kleinsten Dysfunktion terminiert und neu gestanzt. Ein weiterer Vorteil ist hier, dass die gesamte Server-Provisionierung nachvollziehbar in einem VCS (z.B. Github) abgelegt ist. Probleme in der Infrastruktur lassen sich so wesentlich schneller an VCS-Changes identifizieren und gezielt zurückrollen, ohne auf archäologische Spurensuche auf Serversystemen gehen zu müssen.

Alle (ernsthaften) Cloud-Anbieter bieten die Möglichkeiten, Assets und Server über eine API zu stanzen. Im Zusammenspiel mit z.B. Ansible lässt sich so die gesamte Infrastruktur inklusive Server und Netzerkkomponenten in einem VCS ablegen und beliebig herausstanzen. Das kann für Testsysteme aber auch für Disaster Recoveries in anderen AZs oder bei anderen Cloud-Anbietern genutzt werden, stellt aber vor allem eine gewisse Wiederholbarkeit sicher.

JAXenter: Welche Nachteile sind euch nach dem Umzug gleich aufgefallen (oder waren euch schon vorher bewusst), welche etwas später?

Torsten Köster: Die Flexibilität einer Cloud-Infrastruktur mit scheinbar unendlichen Ressourcen und minutengenauer Abrechnung erkauft man sich zu einem teilweise hohen Preis. Hier ist die aktuelle Geschäftsausrichtung entscheidend. In stürmischen Wachstumsphasen mit unsicherem Ausgang ist ein Cloud-Anbieter definitiv die erste Wahl. Sobald sich ein Geschäftsmodell „gesetzt“ hat, drücken die wesentlich höheren Kosten beim Cloud-Anbieter spürbar aufs Portemonnaie.

Man kann jede Software bei AWS betreiben, es macht aber nicht immer Sinn. Das gilt vor allem für große Monolithen.

Was wir schmerzhaft lernen mussten, ist dass man jede Software bei AWS betreiben kann, es aber nicht immer Sinn macht. Gerade große Monolithen, die über Jahre mit ihrem Rechenzentrum eins geworden sind, sind schwer zu portieren. Hier mussten wir bei vielen internen Softwaresystemen die Flex ansetzen, um sie portierbar zu machen. „Cloud-native“ ist (nicht nur) Marketingsprech, sondern muss Einzug in die Softwareentwicklung halten (Service-Discovery, Resilience etc.).

Wir haben uns bei der Nutzung von AWS-Diensten auf Compute (EC2), Store (S3) und Distribute (CloudFront) beschränkt. Das hat den Lock-in-Effekt bei uns minimiert. Mit den spezialisierten AWS-Diensten spart man sich eine Menge Administrationsaufwand (z.B. von Datenbank- oder Queueingsystemen), ist dann aber nicht mehr unabhängig vom Anbieter.

JAXenter: In deiner Session wirst du auch iLO und IPMI vorstellen, damit sollen sich die Prinzipien einer Public-Cloud-Infrastruktur auf „Blechserversysteme“ übertragen lassen. Was kann man sich unter iLO und IPMI vorstellen und wie soll das Ganze funktionieren?

Torsten Köster: Die Lights-Out-Systeme iLO (von HP) und IPMI (von SuperMicro) werden in Server-Chassis verbaut und ermöglichen es, das eigentliche Serversystem fernzusteuern. Die Differenz zwischen Cloud und „Blech-Hosting“ tut sich bei der Hardware-Provisionierung auf. Bei Virtualisierungslösungen wie KVM oder VMWare wie auch beim Cloud-Anbieter kann ich Serverparameter (IPs, RAID, Partitionierung) über APIs konfigurieren. Das Betriebssystem wird über ein Template geladen und fertig ist der Server. Bei echtem Blech hingegen hat uns die händische Konfiguration extrem gestört, da sie nicht wiederholbar in einem VCS abgelegt war. Unser Wunsch war, dysfunktionale Blechserver wie ihre virtualisierten Kollegen komplett automatisiert neu zu betankten.

Lesen Sie auch: „Das Aufbrechen eines Monolithen in Microservices ist keine triviale Aufgabe“

Da bilden die Lights-Out-Systeme gemeinsam mit einem Netzwerk-Boot eine schöne Brücke. iLO und IPMO lässt sich via SSH fernsteuern und ermöglicht eine gescriptete Konfiguration von IPs und Netzwerk-Boot-Adressen. Durch konsequente Automatisierung dessen lassen sich Blechserver bei uns inzwischen schnell in Betrieb nehmen – teilweise in unter 30 Minuten vom gesteckten Stromstecker bis zum Livebetrieb.

JAXenter: Welchen Vorteil hat es, auf eigene Datacenter zu setzen?

Torsten Köster: Für uns ist der Betrieb in einem eigenen Datacenter definitiv ein Kostenfaktor. Die Server sind im Schnitt um Faktor 10 günstiger als vergleichbare Maschinen beim Cloud-Anbieter. Dazu kommt, dass wir freier in der Konfiguration der Komponenten sind. Wir haben eigene Netzwerkhardware verbaut und haben einen garantierten 10G-Netzwerkdurchsatz. Wir sind – wenn überhaupt – unserer eigener Noisy Neighbour und haben keine störenden Einflüsse von anderen Kunden in unsere Hardware. Auch ein Grund, in einem Datacenter niemals z.B. shared Fileserver zu nutzen, denn das Oracle-Backup des anderen Kunden kommt immer zum maximal ungünstigsten Zeitpunkt 😉

JAXenter: Welches System ist unterm Strich das kostengünstigere, welches das sicherere?

Die Cloud ist kein Allheilmittel und die Nutzung von AWS alleine modernisiert keine IT.

Torsten Köster: Das kommt auf die Reife des eigenen Geschäftsmodells an. Für uns momentan ganz klar das eigene Datacenter. Vor fünf Jahren hatte ich da noch eine andere Meinung. Bestenfalls denkt man hier aber nicht schwarz & weiß, sondern nutzt einen Cloud-Anbieter, um neue Setups zu testen. Bei uns sind das momentan Server mit viel Grafikleistung. Wir schauen bei Amazon AWS, was uns solche Maschinen de facto für Machine Learning bringen, bevor wir sie uns im eigenen Datacenter anschaffen. Auch ist ein großer Teil unserer Disaster-Recovery auf Amazon AWS ausgelegt. Entsprechend betreiben wir immer noch VPCs in Frankfurt & Dublin.

JAXenter: Welche Kernaussage sollten die Besucher deiner Session in jedem Fall mit nach Hause nehmen?

Torsten Köster: Cloud ist kein Allheilmittel, die Nutzung von AWS alleine modernisiert keine IT. Fangt jetzt an, Euer Hosting aufzuräumen und konsequent zu automatisieren. Schneidet Eure Software in kleinere Komponenten und testet AWS ausgiebig bevor ihr „all in“ geht.

Vielen Dank für dieses Interview!

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 und steht immer mit einem Bein im Hosting.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: