Kolumne: Stropek as a Service

Warum die Entscheidung für Docker noch keine Cloud-Strategie ist
1 Kommentar

Docker ist seit Monaten in aller Munde. Das junge Unternehmen hat es geschafft, Containertechnologie aus dem Dornröschenschlaf zu wecken und zu einem Massenphänomen zu machen. Ich beschäftige mich ebenfalls seit Längerem mit Docker. Einerseits sind Docker-Container mittlerweile fixer Bestandteil meiner eigenen Entwicklungswerkzeugkist, andererseits helfe ich SaaS-Entwicklungsteams im Rahmen von Workshops, Vorträgen und Artikeln, Docker in ihren Technologiestack zu integrieren.

Bei der Arbeit mit Kunden kommt es häufig vor, dass die Erwartungen an Containertechnologie und Docker überzogen sind. Speziell in Westeuropa findet man immer noch eine tief sitzende Angst und Ablehnung von Cloud Computing. Viele Firmen würden am liebsten einen großen Bogen um US-amerikanische Cloud-Anbieter machen. Die Funktionen, die Docker bietet, sind verlockend für sie. Schwankende Systemlast? Wir können doch einfach je nach Bedarf Container starten und stoppen, und schon brauchen wir Microsoft Azure, Amazon oder Google nicht mehr. Ärger mit der Wartung von Basissoftware? Kein Problem mehr mit Docker. Wir holen uns einfach jede Nacht die aktuellen Images aus dem Docker Hub, und schon sind wir genauso effizient wie die öffentlichen Clouds. Continuous Delivery? Mit Docker kein Thema mehr. Unsere Software wird in Container gepackt, und schon rollen wir Updates unserer Software täglich aus und das ohne Downtime.

Docker ist kein Allheilmittel

Wer mit dieser Haltung an Docker herangeht, wird eine unangenehme Überraschung erleben. Ohne Zweifel, Docker-Container sind richtig praktisch. Egal, ob ich MongoDB, Postgres, einen nginx Load Balancer oder die aktuelle Preview von .NET Core brauche, in wenigen Momenten ist das entsprechende Image von Docker Hub heruntergeladen und als Container auf meinem Entwicklungslaptop gestartet. Das reduziert den Administrationsaufwand gewaltig und steigert meine Produktivität.

Viele übersehen jedoch, dass für eine echte Cloud Docker in eine entsprechende Rechenzentrumsinfrastruktur eingebettet sein muss. Man will auf eine plötzlich massiv erhöhte Systemlast durch das Hochfahren neuer Container reagieren? Schön und gut, doch woher kommen die dafür notwendigen Server? Wie werden sie dynamisch und ohne Downtime in den Containercluster integriert? Ohne ein komplett softwaregesteuertes Rechenzentrum und Netzwerk kommt man nicht weit. Einen einzelnen Docker-Host zu betreiben, ist ein Kinderspiel, ein Cluster z. B. mit Docker Swarm stellt uns aber vor eine ganz andere Liga an Problemen. Hat man die Hausaufgaben dafür schon gemacht, und ist das Ops-Team bereit dafür?

Erleben Sie Rainer Stropek live auf der BASTA! Herbst 2016 – z.B. in diesen Talks:
· C#-Revolution
· Surviving C#-Codereviews
· Neues in Visual Studio „15“ für C# Entwicklung

Docker in der Public Cloud ist reizvoll

Docker in einer professionellen Public-Cloud-Umgebung ist ohne Zweifel reizvoll. Die Cloud-Rechenzentren bieten die notwendige Basisinfrastruktur (Infrastructure as a Service, IaaS) und Skalierbarkeit. Durch Docker können die gebotenen Ressourcen besser genutzt werden, da Container einen kleineren Fußabdruck haben als virtuelle Maschinen. In einer Welt, die immer mehr durch viele getrennte Microservices geprägt ist, macht sich das durch spürbar reduzierte Kosten bemerkbar. Darüber hinaus kann man den Verwaltungsaufwand durch konsequentes Arbeiten mit automatisiert erstellten Images deutlich reduzieren.

Trotzdem darf man nicht übersehen, dass Installation und Betrieb eines größeren Docker-Clusters auch in der Public Cloud keine Kleinigkeit sind. Es braucht echte Profis im Administrationsteam, um diese Herausforderung zu meistern. Die großen Public-Cloud-Anbieter sind bereits dabei, zu reagieren. Microsoft bietet in Azure beispielsweise den Dienst Azure Container Services an. Damit erstellt man einen elastisch skalierenden Docker-Cluster in kürzester Zeit. Administration und Wartung sind aber trotzdem nicht zu unterschätzen.

Container sind teures Spielzeug

Ich werde häufig gefragt, ob wir unsere SaaS-Lösungen bereits alle auf Docker betreiben. Nein, tun wir nicht. Tatsächlich verwenden wir für unsere Produktivumgebungen keinen einzigen Container und auch keine IaaS-VMs. Der Grund dafür ist schnell erklärt: Wir können und wollen es uns nicht leisten. Es ist eine Sache, während eines Unit-Tests eine Datenbank in einem Docker-Container zu starten und danach rasch wieder zu beenden. Installation, Verwaltung, Monitoring, Schutz, Sicherung etc. von Produktionsumgebungen mit SLAs jenseits der 99,9 Prozent ist allerdings etwas ganz anderes. Zugegeben, es wäre eine spannende Materie. Da wir als kleines Team aber mit unseren Ressourcen haushalten müssen, würde die beschränkte Zeit für Administration das Projekt zu einer unprofessionellen Herumspielerei verkommen lassen.

ML Conference 2021

Efficient Transformers

Christoph Henkelmann, DIVISIO

Enhancing Page Visits by Topic Prediction

Dieter Jordens, Continuum Consulting NV

Machine Learning on Edge using TensorFlow

Håkan Silfvernagel, Miles AS

ML & Python Summit 2021

PaaS als Alternative

Meine Antwort für den Produktivbetrieb in der Cloud heißt Platform as a Service (PaaS). In unserem Fall – wir setzen ganz auf die Microsoft Azure Cloud – bedeutet das die Verwendung von Diensten wie Azure SQL Database, Azure App Services, Azure Storage, mLabs (MongoDB) auf Azure und vieles mehr. Natürlich gibt es ähnliche PaaS-Angebote auch in anderen Public Clouds. Das Entscheidende ist, dass diese Produkte fix und fertig einsetzbar sind. Keine Installation, Security-Best-Practices sind von Haus aus eingebaut, fertige Administrationstools, ohne sie vorher kompliziert konfigurieren zu müssen, Verfügbarkeits- und Performance-SLAs, bei Bedarf automatisch oder per Klick im Portal skalierbar – all das erhält man ohne ein einziges Dockerfile, ohne PowerShell und ohne Bash Scripts.

Docker also viel Lärm um nichts? Keineswegs!

Containertechnologie und Docker sind faszinierende Technologien. Serverressourcen werden effizienter genutzt, Zeit für manuelle Administration fällt weg und für DevOps-Teams werden durch Integration von Containern in den Entwicklungsprozess ganz neue Arbeitsweisen möglich. Wie vieles in der IT sind aber auch Docker-Container keine „Silver Bullet“. Meiner Ansicht nach macht Docker anstelle von PaaS für eine produktive SaaS-Umgebung nur beim Vorliegen bestimmter Gründe Sinn. Hier einige Beispiele:

  • Eine bestehende Rechenzentrumsinfrastruktur soll weiter genutzt werden. In diesem Fall rate ich jedoch dazu, die Summe aller Betriebskosten inklusive Personalaufwand kritisch zu hinterfragen. Manchmal ist es kostengünstiger, ein paar physische Server früher in Rente zu schicken und stattdessen auf PaaS zu wechseln.
  • Der Einsatz zentralisierter Cloud-Infrastruktur ist nicht möglich, da z. B. zwingende rechtliche Rahmenbedingungen (unbedingt kritisch hinterfragen!) dagegen sprechen oder zum Schutz vor großflächigen Ausfällen des Internets unbedingt lokale Server zum Einsatz kommen müssen.
  • Man arbeitet in einer sehr großen Firma, die sich ein eigenes Team zum Betrieb einer professionellen Docker-Infrastruktur leisten kann. In diesem Fall baut man sich quasi seine eigenen, containerbasierenden PaaS-Dienste auf.
  • Legacy-Software, die ganz spezielle Serverkonfiguration braucht, verhindert oft den Einsatz von PaaS. Bei PaaS nimmt man reduzierte Flexibilität wegen geringerem Administrationsaufwand in Kauf. Alte Software kommt damit manchmal nicht zurecht.

Wir sind Profis, keine Bastler

Bei allem, was wir tun, sollten wir unterscheiden, ob es sich um professionelle Arbeit oder das Stillen von Neugier durch Basteleien handelt. Nur weil ein Produkt oder eine Technologie in allen Medien ist, heißt das noch nicht, dass man sofort auf den Zug aufspringen muss. Ich bin fasziniert von Containern und Docker und möchte auf diese Werkzeuge in meiner Entwicklungsarbeit nicht mehr verzichten. Für den Produktivbetrieb muss man sich aber fragen, ob man gewillt ist, so tief in die Ops-Welt einzutauchen oder ob Fokussieren auf die eigentliche Entwicklungsarbeit nicht die effizientere Strategie ist.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
1 Kommentar
Inline Feedbacks
View all comments
trackback

[…] Die Containertechnologie von Docker wird oft als Allheilmittel für schwankende Lasten, Continous Delivery oder für die Systemwartung gesehen. Doch ohne eine entsprechende Einbettung in eine Rechenzentrumsinfrastruktur gestaltet sich dies schwierig. Gerade in einer Public Cloud Umgebung ist dies reizvoll. Worauf man bei der Entscheidung für Docker achten sollte und welche Hürden es zu überwinden gibt, darüber schreibt Stropek in… Weiterlesen »

X
- Gib Deinen Standort ein -
- or -