Interview mit Andreas Schmidt

Wie DevOps Entwickler dazu zwingt, mehr Verantwortung zu übernehmen

Redaktion JAXenter

Neben dem Enthusiasmus um DevOps gibt es auch Bedenken, die im Sinne der Entwickler auf eine Antwort drängen und die in den Fragerunden auf der DevOpsCon in Berlin mit Händen zu greifen waren. Was bedeutet es für Entwickler, zu mehr Ops-Verantwortung gezwungen zu werden? Ob es der Entwickler-Welt gefällt oder nicht: DevOps ist here to stay. Auf der DevOpsCon sprachen wir mit dem DevOps-Berater Andreas Schmidt darüber, warum es sich lohnt, die ersten Hürden im Wechsel hin zu einer DevOps-Kultur zu nehmen.

JAXenter: Ist die Erweiterung der Verantwortlichkeiten ein Umstand, den alle mit DevOps konfrontierten Enterprise-Entwickler verkraften müssen?

Andreas Schmidt: Leider ist das so. Wenn ich mich an meine Zeit als Entwickler erinnere, vor etwa zehn Jahren, hatte ich nicht viel Ahnung von Netzwerk-Sicherheit und diesem Kram. Und das hat mich nie beunruhigt. Ich wollte coden und Software bauen und nicht darüber nachdenken, wie man sie zum Laufen bringt. Aber am Ende geht es nicht um die Software. Es geht um laufende Systeme. Und wenn sich Entwickler darum nicht kümmern, muss sich in einem späteren Stadium ein Anderer der Sache annehmen. Es ist das Gleiche wie in der Software-Entwicklung. Einen Bug, den man noch in der Requirement-Phase aufspürt, ist einfacher zu fixen, als wenn er erst in der Produktionsphase entdeckt wird. Das Bugfixing kostet in der Produktion einfach wesentlich mehr.

Und das Gleiche ist es mit dem Netzwerk. Wenn man sich nicht schon in der Building-Phase darüber Gedanken macht und einfach nur Container oder Software über die Mauer wirft, wird ein Anderer später feststellen: „Hmm, das funktioniert nicht“. Und dann muss man von vorne anfangen. Das treibt die Kosten in die Höhe und nimmt mehr Zeit in Anspruch.

Also, das ist die Idee – sich dieser Probleme so früh wie möglich anzunehmen. Vielleicht müssen Entwickler dabei gar nicht unbedingt entscheiden, welches IP-Netzwerk und welche Overlays gebraucht werden, aber vielleicht sind sie dazu in der Lage, zwischen einem Web-Netzwerk, einem Frontend-Netzwerk und einem Backend-Netzwerk zu unterscheiden. Das sind drei Arten von Komponenten, die ich bauen will. Also sage ich meinen NetOps- oder DevOps-Leuten, dass wir drei Netzwerke brauchen. Und auch auf einer späteren Stufe in der Produktion ist das ein VXLan oder eine Standard-Lösung – das ist dann egal.

JAXenter: Also würdest du letztlich sagen, dass Entwickler sich an die Tatsache gewöhnen müssen, dass das Spektrum ihrer Zuständigkeiten breiter wird?

Andreas Schmidt: Ja, ich glaube, das wird es. Ich weiß, dass es schwer ist und dass vielleicht nicht alle Entwickler diese Dinge lernen wollen. Und ich kann das verstehen, schließlich ist es schwer genug, auf eine möglichst gute Art und Weise Software zu bauen. Man will da keine weiteren Belastungen auf sich nehmen.

Aber ich denke, wenn man DevOps anwendet und es im Scrum-Team eine DevOps-Person gibt, die diese Art Arbeit erledigt, dann reicht das schon aus. Dann muss auch nicht jeder Entwickler genau über die Netzwerk-Details im Bilde sein, sondern eben nur diese eine Person. Die Entwickler nehmen diese Dinge dann einfach mit in die Produktion.

JAXenter: Wie sehr gehören DevOps, Container, Continuous Delivery und Microservices zusammen? Müssen Unternehmen gleich alle übernehmen oder können sie getrennt voneinander  zur Anwendung kommen?

Andreas Schmidt: Nun ja, das ist eine organisatorische Frage. Natürlich kann man Continuous Delivery ohne DevOps betreiben. Aber es ist schwerer. Man hat dann getrennte Silos und mehr formelle Kommunikation. Und DevOps wäre hier gerade die Lösung, um alles zu vereinfachen. Und ganz sicher kann man auch Microservices ohne Container verwenden. Aber die Nutzung von Containern macht es viel einfacher, die Microservices zu deployen. Ich glaube also schon, dass das alles zusammengehört.

Man kann Dinge auch einzeln anwenden, wenn man zum Beispiel nur Microservices haben will, aber kein DevOps oder irgendetwas anderes… Aber das bringt einen nicht sonderlich weit. Schau dir mal die kleinen Firmen und Start-ups an. Die denken gar nicht darüber nach, ob sie DevOps machen oder nicht. Die machen es einfach. Sie übernehmen die Technologien sehr schnell, sie nutzen Docker und sie nutzen Microservices. Typischerweise agieren diese Firmen auch schneller, und das zeigt uns, dass die Kombination all dieser Dinge einen positiven Unterschied machen kann.

JAXenter: In deiner Session hier auf der DevOpsCon beschäftigst du dich mit den Veränderungen im Bau von Netzwerk-Infrastrukturen für Container-basierte Systeme. Was sind dabei die häufigsten Hindernisse?

Andreas Schmidt: Netzwerke bauen normalerweise auf physischen Typologien auf. Sie sind verkabelt, und Anwendungen werden damit weitaus dynamischer. Tatsächlich hat sich die Dynamik so sehr verändert, dass das Netzwerk dabei nicht mitkommt. Man kann nicht einfach in das Datenzentrum rennen und fröhlich ein- und ausstöpseln. Also macht man das in der Konfiguration der Netzwerk-Virtualisierung, wo man virtuelle Netzwerke konfigurieren und die sich ändernden Anforderungen der Software besser übernehmen kann.

Eine weitere Herausforderung ist auf jeden Fall die Sicherheit. Wir sehen, dass das klassische Sicherheitskonzept der Network-Perimeter-Security irgendwie nicht mehr tragfähig ist. Und das kommt daher, dass mittlerweile eher mit den Komponenten im Anwendungslayer für Sicherheit gesorgt wird als in der Netzwerkinfrastruktur. Man hat nicht mehr die Kontrolle über die gesamte Netzwerkinfrastruktur. Vielleicht kann man seine Netzwerkinfrastruktur dahingehend anpassen, aber vielleicht eben auch nicht – vielleicht weil man sich in einer privaten Cloud bewegt. Das ist ein weiterer wichtiger Aspekt.

JAXenter: „You build it, you run it.“ In der DevOps-Welt haben wir diesen Satz nun immer wieder und wieder gehört. Aber funktioniert das auch mit Firewalls?

Andreas Schmidt: Nicht besonders gut, vermutlich. Die klassiche Firewall ist zentralisiert und die NetOps-Leute sind ihre „Besitzer“. Ich denke, in einem guten Unternehmen haben die Ops- und die NetOps-Abteilung Zugang zur Firewall und können die Befehlsbasis anpassen. Die Frage ist: Sind sie schnell genug? Können sie mit den Entwicklern Schritt halten? Wenn also Entwickler neue Komponenten mit individuellem Informationsfluss rausbringen, können die NetOps-Leute mit der Implementierung der Änderungen hinterherkommen?

Das ist das eine. Das andere ist, dass klassische Netzwerksicherheit vielleicht nicht mehr mit einer zentralen Firewall bewerkstelligt wird. Eben was die NetOps-Leute mit einer Firewall machen – und das wird schwierig. Ich habe ein wenig Erfahrung in der Automatisierung der Befehlsbasis-Generierung und im Ausrollen. Aber gleichzeitig sehe ich, dass es sehr schwer ist, mit der Geschwindigkeit der Entwickler mitzuhalten, weil moderne, agile Organisationen Scrum in zwei-Wochen-Sprints praktizieren und dann alle zwei Wochen etwas Neues passiert. Das bedeutet Datei-Ändern im Dauerlauf. Und das wird anstrengend.

Andreas Schmidt is an infrastructure coder and systems engineer, into combining deployment, virtualization and network topics. He started to work with Docker’s container engine and is interested in integrating containers into the IT environments of enterprise customers. He works for Cassini, a management and technology consulting company operating in Germany.
DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Verwandte Themen:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: