Priyanka Sharma: "Gesunder Menschenverstand statt allgemeiner Trends"

Inhaltsverzeichnis

heise Developer: Priyanka, Marc Andreessen hat einmal gesagt: "Software is eating the world". Es fühlt sich an, als ob Kubernetes jetzt diese Rolle einnimmt. Was denkst du über die Entwicklung der Container-Orchestrierung?

Priyanka Sharma: Ich stimme definitiv zu, dass Kubernetes überall ist und das Potenzial hat, "die Welt zu fressen". In den letzten Jahren haben wir große Fortschritte im Kubernetes-Ökosystem gesehen, von Interesse, über den Hype und die Bekanntheit bis hin zu Unternehmen, die tatsächlich Kubernetes in ihre Arbeitsabläufe integrieren und es für die Container-Orchestrierung nutzen.

Mehr Infos

Priyanka Sharma ist Director of Technical Evangelism bei GitLab. Sie ist außerdem Mitglied des Governing Boards der Cloud Native Computing Foundation (CNCF) und in dieser Rolle verantwortlich für Budgetentscheidungen der Stiftung.

Damit Kubernetes aber auch in zehn Jahren noch eine entscheidende Rolle spielt, muss es für Entwickler wirklich einfach zu verwenden und zugänglich sein. Vergleichen wir es mit Cloud Computing: AWS hat die Türen für das Cloud Computing geöffnet, weil jeder Entwickler auf einmal sehr einfach ein Projekt starten und es mit deren Cloud-Ressourcen veröffentlichen kann. Die Leute aus dem operativen Bereich wussten schon vorher, wie man Ressourcen zuweist, das war nichts Neues für sie. Aber erst wenn Entwickler die Macht in den Händen halten, werden Trends zu echten Stützpfeilern der Industrie.

heise Developer: Welche Ratschläge kannst du aus deiner Sicht bei GitLab anderen Unternehmen bei folgenden Fragen geben: Wann sollten sie Kubernetes in Betracht ziehen und wie können sie mit Kubernetes anfangen?

Sharma: Es ist wirklich wichtig, mit dem Einsatz von Techniken zu beginnen, wenn die Voraussetzungen dafür geschaffen sind. Das Wichtigste ist, sich darauf zu konzentrieren, seine Engineering-Kultur zu verändern und extrem reaktionsfähig zu sein. Wenn Leute den Code regelmäßig deployen und mergen, nachdem sie die Qualität überprüft haben, dann ist der richtige Zeitpunkt gekommen, um mit Kubernetes zu beginnen. Firmen können es in ihre Continuous-Delivery-Prozesse integrieren und Entwicklern den Zugriff wesentlich erleichtern, wenn sie wissen, dass Qualität für sie oberste Priorität hat.

heise Developer: Dieser Gedanke findet sich in der Idee hinter DevOps wieder, die schon viel länger als Kubernetes existiert. Aber viele Unternehmen kämpfen offenbar immer noch mit dem kulturellen Wandel. Wie verlief dieser Prozess bei GitLab?

Sharma: Wenn wir über den kulturellen Wandel in einem Unternehmen sprechen, denken wir an eine abstrakte Sache – man kann Kultur nicht anfassen und sie ist nicht kontrollierbar.

Der fortlaufende Prozess definiert Kultur neu. Die Art und Weise, wie Softwareentwicklung und Softwarelebenszyklus eingerichtet sind, bestimmt das Verhalten der Entwickler. Wenn Entwicklungsleiter eine Kulturänderung beeinflussen wollen, sollten sie die Prozesse betrachten und sie langsam ändern, um die gewünschten Verhaltensweisen zu belohnen.

Bei GitLab haben wir mit einer monatlichen Deadline für Codeänderungen für die nächste Version begonnen. Dadurch wollte jeder Entwickler am Abend davor schnell mergen – danach hatten sie ja noch zwei Wochen Zeit, um Fehler zu beheben. Das Delivery-Team wechselte dann zu wöchentlichen Deadlines. Das hat die Leute entspannt – wenn das Feature nicht in einer Woche kommt, kann es immer noch in der nächsten Woche kommen. Dieser Wechsel reduzierte auch den Bugfixing-Zeitraum auf eine Woche, was wiederum die Leute dazu brachte, sich von Beginn an mehr auf die Qualität zu konzentrieren. Jetzt gibt es einen kontinuierlichen Zyklus.

heise Developer: Fast jeden Tag gibt es eine neue Version eines neuen Tools im Kubernetes-System. Das klingt nach einer immensen Herausforderung. Wie können Unternehmen deiner Meinung nach mit dieser Entwicklung mithalten?

Sharma: Es ist gewaltig. Kubernetes kam wie ein Big Bang daher. Wir haben all diese Projekte, all diese Unternehmen und jeder versucht, das Thema mit einem spezifischen Tool für spezielle Anforderungsfälle besser zu machen.

Ich denke, es ist besser, ein schneller Follower zu sein und nicht unbedingt ein Vorreiter in Sachen Adaption. So gehen wir das Thema bei GitLab an. Unsere Vision ist, dass die Menschen eine einzige DevOps-Plattform als einzige Anwendung für ihren gesamten Entwicklungs- und Bereitstellungsprozess nutzen können. Um das zu erreichen, müssen wir das Wichtigste, das Neueste und Beste einbeziehen.

Aber wir müssen uns eine Meinung zu den Produkten bilden. Wir warten daher ab, was wirklich auf dem Markt Erfolg hat, und bewerten die Gründe dafür. Erst dann beziehen wir eine Neuerung ein . Man schaue sich Serverless an: Wir konnten erkennen, dass es immer mehr zu einem Thema wurde und unsere Kunden wollten es dann auch umsetzen. Also entschieden wir uns dafür und nutzen Knative, weil es das Werkzeug ist, hinter dem die Community steht.

Ich denke, es ist gut, nicht bei jedem Projekt mitzumachen. Das Ziel ist es, schnell und zuverlässig Software auszuliefern. Wenn Unternehmen das gut machen, dann brauchen sie keine neuen Werkzeuge. Schließlich gibt es nichts anzupassen. Wenn sie allerdings bestimmte Probleme haben oder bestimmte Vorteile sehen, dann sollten sie es sich überlegen. Es ist nicht nötig, Trends ohne jeden Grund zu folgen – gesunder Menschenverstand statt allgemeiner Trends.

Was steckt hinter Severless Computing?

heise Developer: Du erwähntest Serverless Computing. Es scheint immer noch eine Skepsis in der Branche zu geben, Anwendungen auf diese Weise auszuführen. Was denkst du darüber?

Sharma: Die Cloud-Anbieter haben gute Arbeit geleistet, um Serverless wirklich populär zu machen, denn Serverless bietet eine Menge Sparpotenzial. Sie geben die Vorteile an ihre Kunden weiter und ermutigen sie zu einer "Serverless First"-Mentalität, und ich bin manchmal überrascht, traditionelle Unternehmen unter diesen Kunden zu sehen. Das ist für sie jedoch oft eine reine Geschäftsentscheidung: Sie sparen damit Geld.

Ich denke, dass man bei der Implementierung von Serverless die Bedenken hinsichtlich des Datenschutzes tatsächlich beachten muss. Niemand sollte unbedarft Code in die AWS-Lambda-Konsole einfügen und ausführen. In Wirklichkeit wollen die großen Unternehmen "serverlose" Anwendungen genauso wie ihre anderen Sachen ausführen. Deshalb haben wir GitLab Serverless veröffentlicht, bei dem alles an einem Ort ist, einschließlich der Serverless-Workloads, denn dann haben Kunden mehr Kontrolle.