Interview mit Matt Waxman, Head of Products bei Puppet

Puppet Bolt: „Orchestrierungstools sind in der Serverless-Welt obligatorisch“

Dominik Mohilo

© Shutterstock / Pkk_John

Eine neue Version von Puppet Enterprise wurde vor Kurzem veröffentlicht (Puppet Enterprise 2019.1). Wir sprachen mit Matt Waxman, Head of Products bei Puppet, über die neuen Features, das Open-Source-Automatisierungstool Puppet Bolt und die Auswirkungen von Serverless Computing auf die Infrastructure-as-Code-Welt.
 

JAXenter: Welche neuen Features sind in Puppet Enterprise 2019.1 enthalten?

Matt Waxman: Als wir damit begannen, uns auf dieses Release konzentrierten, wollten wir ein Automatisierungsportfolio erstellen, das sowohl Privatpersonen als auch Teams anspricht, obwohl sie jeweils unterschiedliche Dinge benötigen. Der Einzelne möchte die Automatisierung schnell umsetzen und Teams wollen nach Möglichkeit die Automatisierung skalieren. Bislang gab es aber kein einziges Tool auf dem Markt, das dies ermöglichte.

Die Aktualisierungen in Puppet Enterprise 2019.1 konzentrieren sich sowohl auf Ad-hoc-Automatisierung als auch auf Enforced-State-Management für den Einstieg und die Skalierung der Automatisierung, ohne die bestehenden Automatisierungsbemühungen (wie Puppet-Module, bash, Python, Powershell-Skripte usw.) abzuschaffen. Wir sind der Meinung, dass Benutzer nicht zwischen agentenloser und agentenbasierter Automatisierung wählen müssen sollten. Mit den neuen Updates in Puppet Enterprise können Benutzer zwischen Transportprotokollen wie SSH oder WinRM und agentenbasierten Verbindungsmethoden für mehr Sicherheit wählen.

Einige meiner Lieblingsfeatures in dieser Version sind folgende:

  • Die tiefere Integration der agentenlosen Unterstützung in die Puppet-Enterprise-Konsole bietet vereinfachte Onboarding Workflows, einschließlich der Speicherung und Wiederverwendung von Anmeldeinformationen, um Targets ohne installierte Agenten einfach zu automatisieren.
  • Verbesserte Planungsfunktionen, die es Benutzern ermöglichen, Puppet Runs und Bolt Tasks zu planen, um verschiedene Jobs nach bestimmten Zeitplänen auszuführen, wie z. B. jeden Samstag um 2 Uhr morgens.
  • Verbesserte Unterstützung für Module beliebter Netzwerkgeräte, wie z. B. Cisco und Palo Alto Networks.
  • Die Möglichkeit, Continuous Delivery für Puppet Enterprise direkt aus der Puppet-Enterprise-Konsole heraus mit einem Klick zu installieren.

Wir haben auch einige Aktualisierungen an unserem agentenlosen Open-Source-Orchestrierungswerkzeug Bolt und an Continuous Delivery for Puppet Enterprise vorgenommen. Bolt wird jetzt mit YAML-Support zur Verfügung gestellt, sodass jeder, unabhängig von seinem Wissensstand, mit der Automatisierung beginnen kann. Im Fall von Continuous Delivery for Puppet haben wir es Benutzern leicht gemacht, CI/CD-Praktiken für ihren Infrastrukturcode zu übernehmen.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

JAXenter: Sind diese neuen Features lediglich für Nutzer der Enterprise Edition zugänglich oder werden sie (irgendwann) Teil der Open Source Suite sein?

Matt Waxman: Einige der oben aufgeführten Features sind in Bolt enthalten. Wir haben viele Bolt-Features in Puppet Enterprise eingefügt, um sicherzustellen, dass die Mitarbeiter nahtlos von Bolt zu Puppet Enterprise wechseln können, wenn der Bedarf an zentralisierter Automatisierung wächst. Teams können nun nutzen, was sie in Bolt erstellt haben, um Praktiken des Enterprise-Levels umzusetzen und die Verwaltung und Prüfbarkeit von einem zentralisierten Server aus mit Puppet Enterprise durchzusetzen.

Jenen, die mit der Automatisierung erstmal starten wollen, empfehlen wir Bolt, da dies die einfachste Möglichkeit darstellt, bereits vorhandene Befehle und Skripte in einer verteilten Infrastruktur orchestrieren zu können. Dafür ist nichts weiter nötig, als eine Verbindungsmöglichkeit via SSH oder WinRM. Eine Menge Privatpersonen nutzen Bolt bereits, aber auch Entwickler, die zwar Ops- und Automatisierungsaufgaben übernehmen müssen, allerdings eher dem „klassischen“ Bild eines Programmierers entsprechen, greifen darauf zurück.

JAXenter: Was genau ist Bolt und wie funktioniert es von technischer Seite aus betrachtet?

Matt Waxman: Bolt ist ein agentenloses Automatisierungstool, mit dem man Aufgaben, die auf der Infrastruktur bei Bedarf ausgeführt werden, orchestrieren kann. Zu diesen Aufgaben zählen etwa das Beheben von Systemfehlern, das Deployen einer Anwendung oder das Stoppen bzw. Neustarten von Services. Bolt automatisiert diese manuelle Arbeit zur Aufrechterhaltung der Infrastruktur und verbindet sich direkt mit entfernten Nodes über SSH oder WinRM.

Bolt automatisiert die manuelle Arbeit zur Aufrechterhaltung der Infrastruktur.

Andere Tools zwingen den Benutzer oft dazu, sich zwischen einem imperativen oder deklarativen Modell zu entscheiden, während Bolt hingegen beides unterstützt. Das macht es Usern möglich, deklarativen Puppet-Code mit imperativen Tasks zu kombinieren, die in jeder Sprache geschrieben sein können. Bolt gewährt seinen Usern die Flexibilität, eine Sprache ihrer Wahl zu verwenden. Dies bringt die Freiheit mit sich, Änderungen zu orchestrieren, ohne dabei ein Experte in einer bestimmten Sprache sein zu müssen. Darüber hinaus kann man mit Bolt Plans komplexe Workflows – wie etwa das Deployment einer Amwemdung, das mehrere Schritte und Logiken umfasst – einfach automatisieren.

Unternehmen können Tasks auch auf agentenlosen Zielen, wie beispielsweise Netzwerkgeräten, ausführen, sodass sie ihre gesamte Infrastruktur konsistent verwalten können. Bolt kann zudem über 5000 Module der Puppet Forge nutzen.

JAXenter: Chef hat vor einiger Zeit angekündigt, komplett auf Open Source umzustellen. Zusätzlich wird ein Paid-Support-Modell angeboten, so ähnlich macht es Red Hat mit Ansible. Wird auch Puppet irgendwann 100% Open Source verfügbar sein?

Matt Waxman: Wir glauben, dass es möglich ist, ein authentisches Open-Source-Unternehmen zu sein und ein Open-Core-Geschäftsmodell mit einer gesunden Community zu verfolgen. Dies ist ein wichtiger Teil der Strategie von Puppet und dient uns und den über 40.000 Organisationen auf der ganzen Welt, die die Technologien von Puppet einsetzen, sehr gut. Auf Puppet Forge gibt es über 32.650 einzigartige Releases, wir haben fast 30.000 Commits auf GitHub und unsere drei beliebtesten Module wurden allein über 60 Millionen Mal heruntergeladen.

Die Plattform ist unabhängig nutzbar und man kann neue Workflows und/oder Features auf ihr erstellen. Leute haben zum Beispiel komplett masterlose Workflows rund um unsere Open-Source-Komponenten erstellt und dies im großen Maßstab genutzt. Wir finden das fantastischen und fördern es!

JAXenter: Die Verbreitung von Serverless lässt Entwickler immer weniger über die Automatisierung der Infrastruktur nachdenken. Wie stehst du zu Serverless und wie wird sich die Welt der Infrastructur-Automatisierung verändern, um diesen Entwicklungen Tribut zu zollen?

Matt Waxman: Um ein System richtig managen zu können, muss man die Inputs ab einem gewissen Zeitpunkt zu diesem System verstehen und kontrollieren können. Dies hat sich, trotz vieler (teils fundamentaler) Veränderungen in der Infrastrukturtechnologie, als wahr erwiesen – und es wird sich sicher nicht im Kontext von Serverless ändern.

Package-Versionen nicht korrekt zu verwenden, kann desaströse Folgen haben.

Früher bestand der Input für Systeme meist aus Dateien auf einer Festplatte. Die Leute vom Operations-Team mussten deren Inhalt und Status über die gesamte Serverflotte richtig managen, um die Infrastruktur am Laufen zu halten. Dann kam das Package-Management (zum Beispiel in Form von apt oder yum). Plötzlich waren Inputs keine einzelnen Dateien mehr, sondern Versionen spezifischer Pakete, die auf einem spezifischen System installiert sind. Das Aufkommen von höherstufigen Abstraktionen hat es nicht unnötig gemacht, deren Parameter zu verstehen und zu kontrollieren. Package-Versionen nicht korrekt zu verwenden, kann desaströse Folgen haben. Im Jahr 2012 hat zum Beispiel Knight Capital einen Versionsfehler in der automatischen Handelsinfrastruktur übersehen. Ein Fehler, der das Unternehmen in nur 45 Minuten rund 440 Millionen US-Dollar kostete.

In der Serverless-Ära beginnen die Eingaben nun wie Konfigurationsparameter für Cloud-Dienste, Einträge in Key-/Value-Speicher, Einstellungen für einzelne Lambda-Funktionen oder komplexe, ineinandergreifende Sätze von Berechtigungen und Zugriffskontrollen für Cloud-Ressourcen auszusehen.

Ein falscher Parameter in einer automatisch skalierenden Gruppe von solchen kann massive Auswirkungen auf die Anwendung (und den eigenen Geldbeutel!) haben. Wenn man nicht die richtigen Werte für einen bestimmten Key eingibt, kann dieser Fehler schnell und einfach durch die gesamte Infrastruktur wandern und vielleicht sogar im gleichen Zug die Hälfte des Internets lahmlegen – ich beziehe mich hier natürlich auf die Geschichte mit Amazon DynamoDB.

In der Welt von Serverless ist der Einsatz hochentwickelter Orchestrierungs- werkzeuge wie Bolt obligatorisch.

Diese Plattformen verwalten sich nicht selbst. Der operative „Oberflächenbereich“ dieser Plattformen hat sich verändert, ist aber keineswegs eliminiert worden. Man könnte argumentieren, dass der funktionale Oberflächenbereich verteilter, Cloud-nativer Anwendungen tatsächlich größer als die Monolithen ist, die sie ersetzt haben. Die Kosten, die dabei entstehen, wenn wir diese Dinge falsch angehen, sind heute höher denn je, da die Bausteine, mit denen wir arbeiten, jetzt viel mächtiger und anspruchsvoller sind.

Daneben ist da der grundsätzlich verteilte Charakter von Serverless-Anwendungen. Sie bestehen aus vielen, individuellen Funktionen, die alle mit einer Vielzahl von anderen Cloud-Diensten kommunizieren. Alles ist aufgeteilt, alles ist verteilt und vieles davon ist vergänglich. In diesem Universum erfordert fast jede Art von Task den Kontakt mit vielen „Dingen“, die in einer bestimmten Reihenfolge zu erfolgen haben. Die Infrastrukturautomatisierung wird somit eher zur Orchestrierung von Tasks über eine große Reihe von Targets hinweg. In dieser Welt ist der Einsatz hochentwickelter Orchestrierungswerkzeuge wie Bolt nicht nur vorteilhaft, sondern obligatorisch.

JAXenter: Vielen Dank für das Interview

As Head of Product, Matt Waxman is responsible for driving Puppet’s product vision and direction and leading the Product Management, Program Management and UX teams. Matt joined Puppet in 2017 to champion the expansion of the Puppet product portfolio. Matt brings with him over 20 years of experience creating products and growing existing product at companies such as EMC and Dell. Matt Waxman is responsible for Puppet’s product vision, strategy and execution. He has spent close to 20 years creating new products and growing existing product lines for enterprise customers at companies such as EMC and Dell. He also has over 20 patents. A creative initiative taker, Matt optimizes product strategy through deep customer engagement, market-in business planning, and empowering engineering-driven innovation.

Verwandte Themen:

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
4000
  Subscribe  
Benachrichtige mich zu: