Zu Gast in dieser Folge ist Boris Schulz. Er ist DevOps Lead Consultant bei Eficode und ein echter DevOps Spezialist, der viele Jahre Erfahrung mitbringt. Wir reden über seine Sicht auf moderne DevOps-Beratung und die Unterschiede zwischen Start-Ups und Konzernen. Interessant sind seine Sichten auf Technologie und Kultur. Er berichtet aus DevOps-Assessments und -Projekten. Wir haben eine Reihe von Artikeln zum Thema DevOps und seinen Erfahrungen mit Reifegraden, die wir in unserem Gespräch kombinieren. Zum Schluss werfen wir einen Blick in die Glaskugel zur Zukunft von DevOps. Boris erklärt uns dabei den Zusammenhang zur Zeitzonen.
In dieser Folge des Podcasts wird die Rolle der DevOps-Beratung in modernen IT-Organisationen erörtert, mit einem besonderen Fokus auf die Balance zwischen technischen und kulturellen Aspekten. Der Gast, Boris Schulz von Eficode, erklärt, wie DevOps-Praktiken effektiv in verschiedenen Unternehmensumgebungen implementiert werden können, von Startups bis zu großen Konzernen. Es wird betont, dass neben technologischen Fähigkeiten auch eine starke Kultur und menschliche Faktoren für den Erfolg von DevOps entscheidend sind. Es werden Einblicke in die Herausforderungen und Best Practices bei der Implementierung von DevOps gegeben, sowie die Bedeutung von Assessments und individueller Beratung hervorgehoben.
Inhalt
- Einführung und Vorstellung von Boris Schulz und Eficode.
- Die Verbindung von Technik und Kultur in der DevOps-Beratung.
- Bedeutung von DevOps in verschiedenen Unternehmensumgebungen, insbesondere in Startups vs. Konzernen.
- Die Rolle von Assessments und individueller Beratung in der DevOps-Implementierung.
- Diskussion über Technikgetriebene Ansätze und ihre Grenzen.
- Wichtigkeit von Team-Kultur und menschlichen Faktoren in der technischen Entwicklung.
- Zukunftsperspektiven von DevOps und Remote-Arbeit.
Shownotes
1. Kostenloser DevOps Plattform Guide
2. Ergebnisse aus 19 DevOps Assessments
3. IDC Studie zum Stand von DevOps
4. Artikel in der Informatik Aktuell zu DevOps Plattformen und Architektur
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps . Von Dirk Söllner.
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer hochperformanten IT-Organisation.
Als Trainer und Coach mache ich Teams und Menschen erfolgreich, um die aktuellen Herausforderungen bewältigen zu können.
Ich bringe in meine Tätigkeit neben der persönlichen Coaching-Kompetenz eine breite und langjährige Fachkompetenz ein.
Der Forbes umfasst für mich kulturelle, organisatorische, prozessuale und technische Aspekte.
Diese diskutiere ich mit Experten aus der Praxis oder in einer Short-Story.
Heute freue ich mich besonders auf die Verbindung zwischen Kultur und Technik.
Wir haben heute das Thema, wie sieht moderne DevOps-Beratung aus?
Ich habe es schon gesagt, eine Verbindung zwischen Technik und Kultur.
Zu Gast habe ich heute Boris Schulz.
Boris Schulz ist seit kurzem Lead Consultant zum Thema DevOps bei Efficode.
Ein echter DevOps-Spezialist, der schon seit vielen Jahren in unterschiedlichen Unternehmen DevOps vorantreibt und DevOps-Teams leitet.
Also insofern freue ich mich hier.
Ich freue mich wirklich auf die Verbindung der Inhalte von Technik und Kultur.
Wie sieht eine DevOps-Beratung mit Technik und Kultur aus?
Und vielleicht noch ein Wort zu Efficode, bevor natürlich Boris auch sicherlich gleich noch ein bisschen was dazu erzählen wird.
Efficode ist ein finnischer DevOps-Spezialist mit Präsenz in Deutschland.
Und genau deswegen habe ich Efficode ausgewählt.
Wir haben eine ganze Reihe von tollen Artikeln, tollen Beispielen, die wir von Efficode auch haben.
Also insofern würde ich sagen, Boris.
Der Ball geht zu dir rüber.
Ich habe dich ja schon kurz vorgestellt.
Was habe ich vergessen?
Was würdest du aus deiner Sicht noch ergänzen?
Ja, guten Morgen erst mal.
Viel zu ergänzen ist nicht.
Die Kurzfassung war schon sehr gut.
Ich bin seit vielen, vielen Jahren im Management von Infrastruktur-Teams und Entwicklung-Teams unterwegs.
Ich habe die letzten Jahre immer sowohl Hands-on als auch Management gemacht.
Das heißt, ich habe niemals den Berührungspunkt zur Technologie.
Verloren, aber dann doch immer mehr den Fokus auf Menschen gesetzt, weil ich gemerkt habe, dass man die die besten Technik-Teams führen kann oder die Technik-Teams am besten führen kann, wenn man den Fokus eben nicht auf die Technik, sondern auf die Kultur legt.
Und genau deswegen bin ich jetzt bei Efficode.
Die haben eine sehr, sehr überzeugte Rede gehalten, warum sie der richtige Arbeitgeber für mich sind.
Und ja, da bin ich jetzt sehr zufrieden.
Das ist ja cool.
Interessant, denn diese Entwicklung oder diese Lernkurve habe ich beim Patrick de Bois auch festgestellt, der auch eher früher aus der Technik kam, aber dann auch von sich aus selber gesagt hat, es ist jetzt mittlerweile viel wichtiger für ihn, eben mit Menschen zu arbeiten und das eben auch in diesem technischen Umfeld.
Super.
Ja, wir sind im DevOps-Podcast.
DevOps wird ja von jedem gerne mal anders interpretiert und wir sind jetzt hier in der 34. Folge.
Insofern gibt es auch 33 unterschiedliche DevOps-Definitionen.
Weil ich ja zu Beginn immer frage, wie wirst du, also wie definieren die Teilnehmer, die Gäste in meinem Podcast DevOps?
Also insofern, wir kriegen heute bestimmt die 34. Definition von einer Beratungsfirma oder auch von dir.
Wie würdest du DevOps definieren?
Ja, ich habe mich natürlich gerade auf diese Frage sehr gut vorbereitet.
Und ich zitiere jetzt einfach mal die offizielle Definition von Efficode.
Using technology to make organizations operations more agile.
Agile and reactive to customer needs.
Also Technologie benutzen, um die Prozesse einer Firma agiler zu machen und dazu zu führen, dass Firmen schneller auf die Kundenwünsche reagieren können.
Das klingt für mich so ein bisschen technikgetrieben.
Ja, das ist tatsächlich so.
Die Definition ist technisch, leider bei uns in der Firma.
Ja.
Und sobald…
Die vorgelesen wird, zum Beispiel beim Onboarding, gehen dann zehn Hände hoch und dir sagen, ja, aber Kultur.
Und dann kommt immer der Nachsatz, ja, aber es ist 70 Prozent Kultur.
Okay, gut.
Du hast ja von deiner Historie ja eben kurz gesprochen.
Und in dem Vorgespräch haben wir auch ein bisschen darüber gesprochen, dass du eher aus dem Berliner Umfeld kommst, mit kleineren Startups.
Kannst du da ein bisschen was zu sagen?
Ja, also das Berliner Umfeld ist, wie ich finde, so eins der interessantesten in Deutschland.
Davor war ich in Karlsruhe, jetzt bin ich in Köln.
Und das, was Berlin so lebendig macht, das sind die ganzen kleinen Firmen, die teilweise sehr gute Ideen haben und die sehr schnell wachsen.
Und die auch sehr, sehr viel DevOps, um mal beim Thema zu bleiben, von Anfang an einführen.
Also ich glaube, wir haben so zwei, drei große, bekannte Berliner Firmen.
Und die, ob ich die jetzt namentlich nennen soll, weiß ich nicht, oder ob ich es darf.
Aber das ist, wo der Rest der Stadt hinguckt.
Und was die machen, machen alle anderen nach.
Und das Umfeld ist sehr schnelllebig.
Also wenn man bei uns in Berlin zwei Jahre in einer Firma geblieben ist, war das eigentlich schon lange.
Meine Karlsruher Freunde, die waren nach acht Jahren in einer Firma und haben sich langsam überlegt, ob sie mal wechseln sollen.
Und dieses schnelllebige Umfeld in Berlin sorgt dafür,
dass neue Trends und neue Technologien oder neue Arbeitsansätze sehr, sehr schnell umgesetzt und eingeführt werden können.
Jetzt haben wir die Berliner Startup-Szene.
Sind das auch die Kunden, die du von der Efficode-Seite aus betreuen würdest oder betreust?
Oder seid ihr eher in einem anderen Umfeld tätig?
Ich glaube, das ist so genau das Gegenteil der Kunden, die wir gerade betreuen möchten.
Ja, tatsächlich hatten wir uns überlegt,
wo denn für uns die Kunden in Deutschland sitzen.
Und wir haben dann eine große Karte genommen und einfach mal die Leute im Team gefragt,
wo sie glauben, dass die großen Firmen sitzen.
Das abgeglichen mit bekannten Hubs.
Keine Ahnung, München ist ja relativ groß bekannt.
Ruhrgebiet hat auch viele Firmen, von denen man weiß.
Und am Ende kamen wir zum Schluss, dass eigentlich die kleinen Berliner Startup-Klitschen
entweder keine Beratung brauchen,
oder keine wollen.
Also dieses Startup-Gefühl beinhaltet ja auch so ein bisschen dieses,
wir sind die Größten, wir werden es schaffen, den Markt aufzurollen.
Und das sind dann genau die Leute, die eigentlich keine Beratung annehmen.
Bis sie größer werden.
Ja, ist ja so.
Und dann brauchen oder dann vielleicht bitter erfahren, dass sie es brauchen.
Genau.
Und dann irgendwann kommt dann der Punkt, wo die Firmen groß genug sind,
aber auch reflektiert genug sind, um mit dem Rat anderer Leute anzunehmen.
Und dementsprechend konzentrieren wir uns mehr auf die großen Firmen.
Also Nordrhein-Westfalen hat natürlich viele, München, die ganze Gegend da.
Also wir haben auch Kunden in Berlin.
So ist das nicht.
Aber wir fokussieren uns nicht speziell auf den Berliner Startup-Markt.
Okay, gut.
Nachvollziehbar.
Also mir geht es ähnlich.
Wahrscheinlich würde ich genau mit der gleichen Sichtweise.
Entweder brauchen sie es nicht oder sie wollen es nicht.
Aber,
wenn wir uns auf uns jetzt wieder fokussieren, auf das Positive.
Das heißt, ihr seid eher so bei größeren Unternehmen und in Konzernen unterwegs, richtig?
Genau.
Also ich würde nicht ausschließen, dass wir auch kleine Firmen haben.
Es gibt da einen Kunden in Köln, der hat, glaube ich, 60 Mitarbeiter.
Da würde ich sehr, sehr gerne reinkommen, weil ich es technologisch sehr faszinierend
finde, was die machen.
Aber so insgesamt konzentrieren wir uns mehr auf die Konzerne.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Was auch so für uns wichtig ist, ist, dass wir uns mehr auf die Konzerne konzentrieren.
Also kleine Firmen, so, keine Ahnung, ein paar hundert Mitarbeiter habe ich jetzt so oft
selbst gemacht.
Da ist keine so große Herausforderung mehr.
Aber dann das Ganze zu transferieren auf eine Firma, die 3000 Entwickler hat oder 5000
Entwickler, das ist sehr interessant, sehr herausfordernd und das macht auch viel Spaß.
reduced mic Houston.
Okay.
Das heißt, warum braucht ein Konzern dann deiner Meinung nach einen DevOps-S스가,
einen DevOps-Berater, weil bei 3000
Leuten sollte man ja auch denken, dass
sie genug Know-how haben.
Konzerne
sind eben, ich sage das
mal ein bisschen neutral, träge.
Konzerne müssen auch träge
sein, glaube ich.
Und das
heißt, die sind nicht so richtig
bereit, auf den nächsten heißen
Hype aufzuspringen. Also genau das,
was die Berliner Szene hat,
dieses Schnelllebige,
dieses, ich mache mal eben was
und entweder werde ich groß oder gehe ein
und wenn ich eingehe, dann mache ich nächstes Jahr
eine neue Firma auf. Das macht ein Konzern
ja eben nicht. Die müssen sehr wohl überlegt
handeln, die müssen sehr
gezielt handeln.
Man kann nicht 3000
Techniker mal eben von heute auf morgen
auf ein neues Pferd setzen.
Und das heißt, tendenziell
sitzen da eher Leute, die
nicht ganz so
flexibel sind in der Änderung
ihrer Arbeitsgewohnheiten, die aber
dafür ein sehr gut funktionierendes,
meistens sehr komplexes System aufgebaut
haben. Und um so ein System zu
ändern, da braucht man, glaube ich, eher
externe Impulse,
die einem sagen, so,
wir haben das schon hundertmal gemacht, wir kennen
dein Problem, wir wissen, wie du rauskommst,
um da rauszukommen.
Und mittlerweile merkt man auch,
die großen Firmen, also Automobilhersteller
oder, keine Ahnung, Energieversorger
und Banken, die wollen sich ändern.
Also die sind träge und die
haben aber jetzt gesehen, okay, die
Industrie ist so weit gekommen, wenn wir
nicht aufspringen, dann haben wir einen
Wettbewerbsnachteil. Und
die sehen auch, dass sie nicht die Leute
haben, um den Sprung von
Bare Metal, also von der Hardware
im rechten Zentrum, in die Cloud
schnell und zielgerichtet durchzuführen.
Und ja, dazu
holen sie uns.
Okay. Wir haben ja vorhin schon
zu Anfang gesagt, es geht bei euch,
es geht bei dir um die Kombination
von Technik und Kultur.
Und wenn ich das richtig aus dem Vorgespräch
auch ja noch in Erinnerung habe, hast du ja gesagt,
du kümmerst dich eigentlich mehr um den menschlichen Teil.
Das hast du ja eben auch in deiner
Vorstellung gesagt. Wie funktioniert
das denn in einem techniklastigen
Umfeld?
Also der techniklastige Umfeld,
also gerade DevOps, der
ermöglicht ja sehr transparentes
Arbeiten. Man sagt ja auch,
man hat so ein, wenn man Agile
macht, dann sagen die meisten Philosophien,
man hat so ein Fullstack-Team,
das alles abdeckt
und alle haben Zugriff auf den Code
und man hat sowieso Infrastructure
as Code und eigentlich kann man sagen,
jeder innerhalb von einem Entwicklungsteam
hat vollen
Zugriff auf
alles vom Source-Code
bis zum Live-System.
Das heißt, da steckt wahnsinnig viel
Verantwortung drin und
ich denke, kulturell
am wichtigsten ist,
dass man eine
Umgebung schafft, in der
man diese Transparenz
verantwortungsvoll
nutzen kann. Das heißt,
Feedback-Kultur ist unglaublich wichtig.
Diese kurzen Zyklen,
die man immer hat bei agiler Entwicklung,
die funktionieren nur,
wenn das Team auch
damit umgehen kann und wenn es dem Team erlaubt
wird, offen und ehrlich Kritik zu
äußern oder auch
innerhalb vom Team Feedback
zu geben und
Feedback auch entgegenzunehmen, was ja auch sehr
schwer sein kann. Das
ermöglicht ja erst den Umgang
mit so einer transparenten Umgebung.
Also so als Beispiel,
wenn ich jetzt die Möglichkeit habe,
durch eine Änderung
im Source-Code die
Sicherheitsbestimmungen auf meinem
Cloud-Account zu ändern, dann kann es
ja vorkommen, dass ich irgendwas kaputt mache.
Da muss ich auf der einen Seite
willens sein,
anzunehmen, dass jemand zu mir kommt und
sagt, hey Boris, du hast ja was kaputt gemacht
und der andere muss aber auch zu mir kommen.
Und ich glaube,
Feedback-Kultur ist so das aller,
allerwichtigste, was man lernen muss.
Und das gerade große
Konzerne eher nicht zu haben.
Ja, okay.
In dem Zusammenhang fällt mir noch ein anderer
Punkt ein, der das Thema Verantwortung
oder Übernahme von Verantwortung
anspricht, den ich
erlebe. Das ist nämlich der Punkt, dass
ich ja, wenn ich Verantwortung übernehme
für etwas, mir auch der Tragweite
bewusst sein muss. Das heißt, das, was
du eben sagtest mit der Sicherheitseinstellung
beispielsweise, das bedeutet
ja, ich muss wissen,
wenn ich diese Verantwortung eben
annehme, was das wirklich auch schlussendlich
bedeutet. Wenn ich aber gar nicht abschätzen kann,
was ich da tue, also wenn ich mir der
Konsequenz nicht bewusst bin,
dann übernehme ich zwar Verantwortung,
aber bin auch mit den Konsequenzen
mir darüber nicht im Klaren.
Stellst du das auch fest,
dass diese Problematik da ist?
Ja, sehr.
Interessanterweise nicht bei
Konzernen oder Startups. Also das gibt’s
einfach, es gibt Firmen, da sagen
Leute, wenn die Firma
möchte, dass ich was Neues lerne, dann muss
die Firma mir das beibringen.
Und dann gibt’s Leute, die sagen,
oh, hier ist was Neues, ich habe hier neue Möglichkeiten,
ich habe Möglichkeiten, mich zu entfalten,
das will ich lernen.
Und ich glaube,
die aktuelle Entwicklung geht dahin, dass
der lebenslange
Willen zum Lernen, von dem immer
alle geredet haben, jetzt tatsächlich
notwendig wird.
Ja, der wird notwendig,
aber nur mit
Fingerschnippen oder mit dem Hinweis,
ich bin hier DevOps-Berater oder Coach,
versuch mal deine Einstellungen
zu ändern, funktioniert’s ja nicht.
Nein.
Also die Frage ist ja auch, wir haben ja auch
gesagt, der Titel heißt ja, wie
sieht moderne DevOps-Beratung aus?
Was sind denn dann deine typischen Aufgaben,
die du als DevOps-Berater
durchführst oder die du einer modernen
DevOps-Beratung zuschreiben
würdest? Okay, das ist jetzt
ein ziemlich großes Feld.
Die Aufgaben,
die wir als Firma übernehmen,
sind einfach tatsächlich alles
was DevOps
beinhaltet. Also wir sind,
wir haben Trainings zum Beispiel,
wir sind Atlassian Premium Partner
und irgendwie Partner of the Year
- Das heißt, wir decken den ganzen
Toolkit-Bereich
ab, wir können, wir haben Git-Trainings,
wir haben neulich eine Firma gekauft, die
nichts macht als, oder fast nichts macht,
als Trainings anzubieten.
Und das ist dann so dieses
Enablement. Man muss den Leuten
beibringen, die neuen Technologien
zu verstehen.
Dann natürlich ganz normal
Hands-On, also sich hinsetzen und
Terraform-Code schreiben.
Dann
haben wir ein Assessment, das ist
sehr interessant. Da geht es darum, dass man
den DevOps-Reifegrad von Kultur,
Prozessen und Technologien bewertet.
Wir bieten auch selbst ein Produkt
an, unsere DevOps-Plattform.
Und was ich persönlich am
liebsten mache, ist dieses kulturelle,
also zum Kunden gehen,
mir anschauen, was er da eigentlich
gerade macht und mir überlegen, wonach
er das macht.
Und das ist dann auch
meine Erfahrung heraus,
die Mitarbeiter oder die Teams
gecoacht werden müssen.
Und das ist dann aber sehr individuell.
Wie gesagt, es gibt Firmen, in denen ich
festangestellt war, die haben sich
geweigert zu lernen.
Und da war dann auch als
Abteilungsleiter meine Aufgabe viel
mehr, auf die Leute zuzugehen und
rauszukriegen, warum haben sie einen Block,
warum haben sie Angst zu lernen, warum
haben sie Angst, auf sehr persönlicher
Ebene zu arbeiten.
Und dann gibt es Firmen, die haben einfach
andere Probleme. Da ist das Problem,
die Angst, den Job zu verlieren,
wenn man in die Cloud geht,
zum Beispiel. Und da gibt es eigentlich
keine universelle Antwort.
Da muss man sich wirklich anschauen,
was macht die Firma und dann hilft nur
Erfahrung, Wissen und
das Anwenden auf die jeweilige Situation.
Ausprobieren
und reflektieren und wieder
ausprobieren und reflektieren, aber eben
mit einer gehörigen Portion Erfahrung,
um auch zu wissen, wo sollte man
den nächsten Schritt mal ausprobieren.
Was sind denn die nächsten Themen an der Stelle?
Genau. Und darum
bin ich ja jemand, der
von Efficode angeheuert wurde, weil
ich schon in mehreren Firmen
solche Transformationen durchgeführt habe.
Und entweder ich habe eine Lösung
oder ich kenne einen, der die Lösung
liefern kann.
Ja, sehr schön. Also über das Thema Assessment
denke ich, sollten wir auch noch sprechen.
Gerne nochmal auf das Thema Technik eingehen.
DevOps-Plattformen.
Ich bin ja
nicht der Techniker. Die Leute, die den Podcast
regelmäßig hören, wissen, dass ich eher aus der
BWL- und Prozessebene
und Framework-Ebene komme.
Ich habe zwar
ein paar DevOps-Plattformen von der
Begrifflichkeit, von dem Umfang, aber
konkrete Frage, was ist
oder was beinhaltet eure DevOps-Plattform?
Was kann die DevOps-Plattform
bieten und wer
braucht diese Plattform?
Ja, das ist eine schöne Frage.
Das Wort DevOps-Plattform
kannte ich nicht vor EFI-Code
und mittlerweile denke ich mir,
das sollte eigentlich
jeder haben.
Okay.
Aber nein, Spaß beiseite.
Also wirklich, eine DevOps-Plattform
ist, so wie wir das verstehen,
dieses ganze Drumherum, die ganze
Peripherie an Tools, die
man braucht, um in einer modernen
Entwicklungsumgebung
zu arbeiten. Also,
jeder hat ja irgendwie ein Ticketsystem
und ein Wiki. Dann hat man Source-Code-Management,
dieses GitHub oder GitLab.
Dann hat man irgendwelche Security-Tools,
die die Container scannen
und alles, was
da so zusammen… Achso, Monitoring.
Ganz, ganz wichtig. Monitoring und
Graphing.
Und da gibt es ja nicht so eine große
Auswahl.
Und jeder baut das gerade für sich selbst.
Und ich habe die letzten, ach, ich weiß nicht,
vier Firmen damit verbracht,
mehr oder weniger,
die gleiche Plattform aufzubauen.
Immer mit den gleichen Tools.
Und das ist eine inhärent undankbare
Aufgabe.
Die Firma dankt es einem nicht,
weil es Peripherie ist. Die muss da sein.
Aber da hängen keine Features dran.
Also, es gibt überhaupt
keine Ruhm und Ehre, wenn man so eine
Plattform perfekt aufbaut.
Man muss es nur tun.
Und dann
war ich relativ glücklich, als ich bei
Efficode beim Onboarding in Finnland gesehen
habe, dass die im Prinzip
eine Drag-and-Drop oder
wie heißt das eigentlich? Eine Point-and-Click-Lösung
anbieten, wo man sich
genau die üblichen Tools, die man braucht,
zusammenklickt,
auf Abschicken drückt und dann
kriegt man ein paar Minuten später einen Zugang
zum SSO mit Benutzerverwaltung,
schon den wichtigsten Graphen,
so High-Level
Informationen und Metriken.
Und das war’s.
Das heißt, die Arbeit, die ich mir vorher
in einem Jahr gemacht habe,
ist in fünf Minuten fertig.
Also, das klingt jetzt schon nach
Werbung, gebe ich zu, aber
wenn ich mir überlege,
wie viel böses Karma
daraus entstanden ist,
dass ich halt so ein Ding bauen musste in
mehreren Firmen,
aber es hat halt keine,
wie gesagt, es waren keine Features, die daran hingen.
Es war einfach nur Peripherie, die man gebraucht
hat. Dann muss ich sagen,
mir hätte das in der Vergangenheit
sehr, sehr viel Stress gespart.
Das glaube ich wohl.
Also, die
ganzen Tools, die es gibt,
die ja für mich erschlagend sind.
Wir hatten ja vor einigen Ausgaben,
in einer der ersten Ausgaben hatten wir auch
Xevia Labs da mit der
DevOps Tool,
mit dem Tool-Periodensystem.
Es gibt ja eine erschlagend
große Anzahl von Tools.
Jetzt hast du eben natürlich gesagt, die Firmen,
das ist undankbar, das
aufzubauen, weil die Firmen
eben erwarten, dass das da ist, also das Business
an dieser Stelle, wenn ich ja mal in meinem
Sprachgebrauch bleibe.
Aber natürlich, jetzt bin ich vielleicht ein bisschen
schubladendenkend unterwegs,
da haben wir ja Techniker.
Wir haben Menschen, die gerne Dinge ausprobieren,
die sich gerne in Dinge einarbeiten,
auch wenn das jetzt vielleicht
betriebswirtschaftlich gesehen nicht sinnvoll ist
und sie auch die Zeit gar nicht hätten
oder bekommen dürften,
sie tun es gerne.
Wie gehst du mit solchen Themen um?
Weil die würden sich ja eigentlich bei euch gar nicht melden,
weil ihr ja etwas Fertiges bietet
und man kann dann das ausprobieren,
sich sparen, was aber
ja vielleicht nicht in jedermanns Sinne ist.
Also tatsächlich ist meine Erfahrung,
dass die Leute, die gerne ausprobieren
und die Leute, die gerne
Dinge tun, eigentlich auch
ganz gerne dafür belohnt werden.
Und so eine,
ich bleibe einfach mal bei der
DevOps-Plattform, die Teams,
die sich um DevOps-Plattformen
kümmern intern,
die haben Spaß daran, das auszuprobieren,
aber das Beste, was sie
jemals erwarten können, ist, dass jemand
kommt und sagt, okay, läuft wie erwartet.
Und
darum denke ich schon, dass wir
die Teams auch ansprechen, weil dann
können die gleichen Leute, die gleichen Entwickler
ihr Wissen nutzen und Sachen
ausprobieren und Features bauen,
für die sie tatsächlich belohnt werden.
Okay. Das heißt, die Konzentration
auf das Wertschöpfende, auf die wertschöpfende
Tätigkeit, die dann natürlich auch belohnt wird.
Belohnt im Sinne von, der Kunde
ist zufrieden und
er freut sich auch über eine schnelle
Umsetzung. Genau. Also nach
meiner Erfahrung sind Infrastruktur-Teams
oder Backend-Teams diejenigen,
die zwar inhaltlich am weitesten
entfernt sind vom Kunden, aber auch
die, die sich eigentlich am meisten mit dem
Produkt identifizieren.
Ja,
okay.
Jetzt bin ich, also ich
bin nicht der Techniker und deswegen würde ich
jetzt weitere Technik-Fragen mir ersparen.
Es sei denn, du hast
noch ein paar konkrete Hinweise,
aber letzten Endes, es soll ja
auch wirklich kein Werbepodcast werden,
oder keine Werbeveranstaltung werden, aber
insofern die Begründung
dafür, dass es so eine Plattform geben sollte,
oder dass es sie gibt, die finde ich schon
nachvollziehbar. Jetzt haben wir ja auch
das Thema, wie sieht moderne DevOps-
Beratung aus? Wenn ich jetzt mal den Bogen
spanne, kommen die Firmen
auf euch zu und sagen, hey, ihr habt eine tolle
Technik, ich möchte eure Plattform kaufen,
oder kommen sie mehr über andere
Punkte, Stichwort
Assessment, und wie
sieht dann auch vielleicht die Aufgabe an
euch aus? Weil, wenn sie aus der Technik kommen,
und euer Tool kaufen,
oder die Plattform kaufen, dann könnte ich mir
vorstellen, dass die, dass der
Auftrag an euch anders aussieht, als
wenn sie sagen, hey Boris, komm mal her,
berate uns mal, und ach, du hast ja auch noch
eine Plattform mit dabei.
Puh, viele
Fragen.
Also das kann ich ehrlicherweise nicht beantworten.
Ich weiß nicht, wie die
Mehrzahl der Aufträge zu uns kommt,
weil ich kein Vertriebler bin.
Von dem, was ich so mitkriege,
haben wir für
Deutschland einen sehr fleißigen Vertriebler,
der Firmen anschreibt.
Auf der anderen Seite sind wir aber auch präsent
auf Konferenzen, auf Meetups,
oder wir haben unser
Blog, und
ich wurde zum Beispiel jetzt schon zweimal
angeschrieben von Firmen,
von sich aus,
die irgendwie unseren Namen gesehen haben,
und DevOps-Beratung, und ach hier,
du bist doch bei denen, ich hab dich irgendwie
in meinem riesigen LinkedIn-Netzwerk,
was macht ihr denn da genau?
Aber ich kann tatsächlich nicht sagen, wie die
Mehrheit der Firmen zu uns kommt.
Aber,
was ich gemerkt habe, wenn man
den Firmen sagt, was man anbietet,
dann lenkt man ja automatisch auch
die Nachfragen.
Und zum Beispiel merke ich
in dem Moment, wo ich komme und sage,
ich mache übrigens auch Kultur, also wenn ihr
Fragen habt zum Thema
Umstrukturierung von Teams, Team-Identifikation,
Kommunikation,
oder sowas wie
Kommunikation
ohne sauer zu werden innerhalb von Teams,
oder Angstbekämpfung, dann kommen schon
Firmen und sagen, ach, das macht ihr auch.
Ja, also dann lasst uns doch mal reden.
Ja, okay.
Na gut, das Thema ist ja moderne DevOps-Beratung,
und wenn man
auf das schaut, wie ich DevOps verstehe,
das ist ja ein sehr breites Feld, und ich glaube,
es gibt niemand, der sich in allen diesen
Feldern perfekt auskennt,
oder bis in die Tiefe gehen kann. Das heißt also,
du bringst deine Erfahrungen mit, du bringst die technische
Erfahrungen mit, du bringst die Plattform mit,
du bringst deine kulturellen
Erfahrungen mit. Bei mir
fehlt die Technik, da habe ich an anderen Stellen
vielleicht noch ein paar Punkte, die ich mitbringe,
aber genau das ist eben
die moderne DevOps-Beratung, dann auch aus meiner
Sicht, dass man
an ein paar Stellen tiefer gehen kann,
an ein paar Stellen noch ein Angebot machen kann,
und die Firmen, die Unternehmen merken ja selber,
ob derjenige, der das Angebot
macht, ob sie das dem auch entsprechend
zutrauen an der Stelle. Genau. Und ich glaube,
an der Stelle ist dann sehr stark der Vertriebler
gefragt, dass der so ein Händchen dafür hat,
rauszukriegen, wen man einsetzen
kann. Also wir haben natürlich Leute,
die sind nur auf Azure unterwegs
und dafür die Gurus, andere machen
nur Amazon oder Google,
oder ich mache verstärkt Kultur, und dann
haben wir so die Allrounder, die alles so ein bisschen
können, und ich glaube, das hängt so ein bisschen
am Vertriebler, dass der
ein Näschen dafür hat, in welche
Richtung man das Gespräch lenkt, weil alles,
wie du schon gesagt hast, alles geht nicht.
Mhm. Sehr
schön. So, wie sieht moderne DevOps-
Beratung aus? Das ist ja immer noch unser
Titel, und wir hatten eben über
den Punkt gesprochen, oder du hast ihn einen erwähnt,
Assessment. Also ihr bietet
Assessments an. Kannst du
dazu ein bisschen was sagen?
Großartige Sache.
Assessments
sind ein formalisierter
Ansatz, um den Reifegrad
einer Firma oder
eines Teils einer Firma
im Bereich DevOps
zu ermitteln.
Denn kommt zum Tragen, dass
der FA Code schon viele, viele
hunderte Assessments gemacht hat, das heißt, sie können
zum jeweiligen Sektor der
Industrie, können sie sagen, wie
eine Firma steht im Vergleich zu
anderen Firmen, die vorher untersucht wurden.
Und das ist natürlich
für die Kunden sehr interessant. Und
untersucht werden da alle möglichen Faktoren,
Automatisierung, QA,
bestimmte einfach
messbare Faktoren der Kultur,
Technologie.
Und wie das abläuft, ist,
dass sich zwischen einem und drei
erfahrene Berater
da
hinsetzen, in die Firma
entweder persönlich oder remote,
und mit Leuten aus dem Team reden,
dass untersucht werden soll.
Und
die machen sich da Notizen, und am Ende
gibt es zwei Auswertungen,
die in Prozenten oder in
Punkten, glaube ich,
die zufällig aussehen wie Prozente,
der Firma sagen,
in welchem Bereich bin
ich wie weit, Automatisierung,
Fehleranfälligkeit, keine Ahnung, sowas.
Und
das ist sehr interessant, weil, also
für mich war das sehr interessant, das beim ersten Mal
zu sehen, weil das quasi
das kondensierte
Wissen, was ich mir in den letzten 15 Jahren
angeeignet habe,
war formalisiert
und anwendbar
für beliebige Firmen. Das fand ich sehr
interessant. Ich fand es auch schön zu sehen, dass meine eigene
Erfahrung sich daran wiedergespiegelt
hat, also das war eine Bestätigung für
mich.
Und das andere Interessante
ist natürlich, dass da direkt
direkt aus den
Zahlen, aus den Metriken
mehr oder weniger Handlungsanweisungen
für die Firmen rausfallen.
Also wenn da zum Beispiel steht, Automatisierung
90%, Industriemittel 70%,
dann weiß die Firma, okay,
läuft. Wenn da aber
sowas steht wie
QA ist immer noch alles manuell,
der Rest der Industrie
oder deines Industriesektors
läuft automatisiert,
dann hat ja die Firma schon direkt
eine Handlungsempfehlung, an welcher
Stelle sie nachbessern muss.
Ja,
insbesondere das Thema Industriemittel,
also wo stehen
andere, finde ich immer sehr, sehr interessant.
In meinen DevOps-Trainings
referenziere ich häufig auf die Aussagen
um State of DevOps Report
und wenn dann die
IT-Experten, die IT-Manager
da sitzen, dann schlagen die ja lang hin,
was in den
erfolgreichen DevOps-Organisationen
quasi an
Zahlen generiert wird, also wie schnell
ein Deployment ist, wie gering die Fehler
Quote ist und so weiter. Das sind ja alles
Dinge, wo man sich
sicherlich streiten kann, ob das
valide ist, ob diese Zahlen
vergleichbar sind, aber es sind einfach mal
Kennzahlen und wenn ihr mit euren
Erfahrungen, mit der
Summe der
Messgrößen einfach so
ein Industriemittel gibt, dann könnt ihr ja
wirklich genau sagen, hier, ihr seid besser
oder schlechter und die einen
können sich hinlegen und die anderen müssen was tun.
Genau. Und interessanterweise wollen
dann viele Firmen gar nicht das Industriemittel
sehen, wenn man sich anschaut.
Neulich war ich beim großen
Energiekonzern und der
meinte dann, ja, also du,
Industriemittel, Energiekonzern, ist mir eigentlich
egal. Zeig mir mal,
was macht denn die Webindustrie? Wir
wissen, die sind viel, viel weiter vorne.
Wir wollen uns an denen orientieren, die
weit vorne liegen und nicht an denen, von
denen wir wissen, dass die genauso träge sind
wie wir.
Da du hast eben Assessments angesprochen,
wir sprechen ja über Assessments und wir
sprechen darüber, dass ihr das schon eine gewisse Zeit
macht bei Efficode.
Es gibt bei euch ja so einen sehr schönen
Bericht auf der Webseite. Wir haben ja gesagt,
dass wir einige tolle
Artikel haben, wo wir auch die Links in die Shownotes
reinpacken. Also in dem Bericht,
glaube ich, stellt ihr die Ergebnisse
von 19 Unternehmen dar, die ihr
da mal so ein bisschen zusammengefasst habt.
Kannst du vielleicht so ein bisschen was zu diesem
Bericht sagen, zu den
Ergebnissen, die ihr da so entsprechend zusammengefasst
habt?
Ja, sehr gerne.
Wenn man sich das anschaut,
diese 19 Firmen,
dann sieht man
eigentlich ziemlich deutlich,
dass QA am wenigsten Liebe bekommen
hat von den Firmen. Die anderen
Sachen, die anderen Punkte, die angesprochen werden,
die sind mal besser,
mal schlechter, aber durch die Bank weg ist
QA in allen Bereichen
das Problemkind,
würde ich mal sagen.
Das liegt meiner Ansicht nach an dem gleichen Grund,
warum so eine DevOps-Plattform
auch immer so ein Problemkind ist.
QA ist inhärent undankbar.
Also wenn man Probleme
findet, dann mag einen keiner so richtig.
Wenn man keine
findet, macht man seinen Job nicht gut.
Und das ist so eine von den
Kernaussagen, die wir hier zum Beispiel gefunden
haben. Und ich glaube, das deckt sich
nicht nur mit den 19 Assessments,
die wir gemacht haben, sondern auch mit
vielen, vielen anderen.
Zumindest
die Firmen, die ich selbst angeschaut habe,
da war es auch so.
Ja und ansonsten kann man hier sehr, sehr
schön mal kurz sehen, was für
Punkte
aus so einem Assessments rausfallen.
Also Build and Continuous Integration,
wie gut man da abschneidet.
Sowas wie
Environments and Release, Leadership, wie gesagt Kultur,
QA,
Architektur, Automation
und Automation ist
glaube ich in den meisten Firmen
besser, als sie denken.
Selbst der
letzte Admin, der in seinem
dunklen Keller sitzt, hat in der Regel
alles einigermaßen mit Shell
Skripten automatisiert.
Und es fällt dann ziemlich leicht, die Shell
Skripte umzuwandeln in was modernes.
Also Automatisierung ist
meistens relativ gut, nach meiner
Erfahrung.
Dann der
andere große Punkt, der hier rausfällt,
ist, dass DevOps
insgesamt, also das
Ganze, die Sammlung
von allen Praktiken und
Technologien, was da so
zusammengehört, lange nicht so weit
verbreitet ist, wie einzelne Teile.
Also es gibt öfter mal
Firmen, die dann zum Beispiel
CI machen oder die machen CD
oder machen, keine Ahnung,
Automatisierung relativ gut,
aber so das ganze
Bild abgerundet darzustellen,
das schafft fast keiner.
Interessant.
Also insofern, für alle die, die jetzt so ein bisschen
Lust
bekommen haben auf diesen Artikel,
wie gesagt, kommt in die Shownotes rein.
Jetzt haben wir ja, wir reden ja über
moderne DevOps-Beratung
und dann fallen ja aus
einer Produktpräsentation
oder Produktanfrage oder eben aus diesem
Assessment oder aus anderen Kontakten, die ihr habt,
da fallen ja wie immer Projekte raus.
Wie sehen denn bei euch
typische Projekte aus, beziehungsweise
gibt es überhaupt typische DevOps-Projekte?
Wir sind bunt.
Sehr, sehr bunt.
Sehr, sehr bunt.
Ja, ich hatte neulich
die Diskussion mit einem sehr jungen Kollegen,
der meinte, ach, die Konzerne, die sind ja alle
ganz, ganz furchtbar rückständig.
Ich finde das gar nichtmals.
Also, mein Bild
von Konzerntechnologie war
wesentlich schlechter, bevor ich
mit denen zusammengearbeitet habe.
Klar,
das ist so ein bisschen die Vorauswahl,
die Konzerne, die richtig schlimm sind,
die so richtig Leichte im Keller haben,
die kommen wahrscheinlich gar nicht erst zu uns.
Das heißt, wir haben schon die Vorauswahl
der motivierten Konzerne,
die auch
willig sind, den nächsten Schritt zu gehen
und die auch Leute haben, die mitgehen wollen.
Aber es ist immer noch sehr, sehr
bunt. Also alle Clouds,
ich glaube, alle Firmen, wo ich
bisher war, hatten nicht eine Cloud, sondern
alle, was
interessante Herausforderungen mit sich bringt.
Sehr, sehr
viele Bare-Metal oder VMs,
die man dann so
langsam in die Cloud migriert,
also aus der Private Cloud in die Public Cloud
oder von Bare-Metal überhaupt
in die Cloud.
Viele
Transformationsprozesse
von riesigen, großen, hässlichen
Monolithen
auf Umweg über SOA
dann zu Microservices
und viele Containerisierungsprojekte.
Ich glaube, das kann man so abschließend sagen.
Das ist so.
Ziemlich bunt an der Stelle
und dann braucht man ja auch wirklich,
das ist ja für die Firmen interessant, auch jemanden zu
haben, der das alles zumindest
überblicken kann. Also vielleicht,
dass nicht eine Person alles betreiben
oder betreuen oder beraten kann,
aber eben jemanden zu haben, der das
technisch entsprechend überblickt
und aber auch die kulturellen und die anderen
Dinge mit klären kann.
Wie
siehst du das Thema
Berater? Also die Firmen sind ja dann
doch immer in der
Hand eines Beraters.
Ich überlege, ob ich das so sagen kann, aber sie sind ja
eine gewisse Abhängigkeit an der Stelle.
Wenn ihr jetzt auf Situationen
trefft, dann muss ja auch ein gewisses Vertrauen
da sein, der Unternehmen in eure
ich sag mal, natürlich
in die Fachkompetenz, aber auch in die
Unabhängigkeit.
Ja, also wir sind auf der
einen Seite sind wir glaube ich tatsächlich
einer der
wenigen unabhängigen Berater für
die Cloud und auf jeden Fall der einzige
unabhängige, reine DevOps-Berater.
Und
das aus
mehrerlei Hinsicht. Auf der
einen Seite können
wir alle Clouds bedienen und alle Technologien
bedienen und
jeder hat natürlich seine Vorliebe,
aber wir als Aficode setzen natürlich
auf jemanden, der bei Azure ist,
dann keinen, der nur Google machen will.
Es kann sein, dass
wir den Leuten, unseren Mitarbeitern sagen,
so, ich weiß, du magst AWS,
aber du musst jetzt Google machen oder
andersrum, aber der Kunde kriegt natürlich
immer die Experten für seine
Umgebung.
Und wir haben eigentlich kein Interesse
daran, die
Unternehmen irgendwie zu schubsen
in eine bestimmte Richtung.
Am Ende muss es tun, am Ende muss es laufen
und wir sind pragmatisch
genug, um
zu sehen, wenn es läuft,
dann müssen wir da auch nichts mehr ändern.
Also das ist jetzt keine
Firma, die ich bei Aficode gesehen habe,
aber die bestlaufendste Firma, die ich
jemals gesehen habe, die
lief auf Bare Metal, da war
nichts automatisiert außerhalb von
Shell-Skripten und die waren absolut
fehlerlos.
Und da gibt es keinen Grund, viel
zu ändern.
Die Gründe kamen dann später in der Firma, als sich
die Belegschaft geändert hat und dann
gab es Probleme, weil das ganze
Wissen innerhalb der Köpfe weg war
und dann wäre es gut gewesen,
die hätten was geändert. Aber so an sich,
wenn man sieht, alles läuft, alles ist
stabil, dann sehen wir da auch keinen Grund,
was zu ändern. Also wir sind
nicht die Leute, die dann den
Fuß in die Türe stellen und um Himmels
Willen irgendwas machen wollen.
Das andere ist,
dadurch, dass wir so viele unterschiedliche
Assessments gemacht haben und
so viele unterschiedliche Firmen
uns angeschaut haben, können wir
tatsächlich unabhängig sagen,
wie eine Firma aussieht.
Und ich glaube, das ist sehr selten
und das ist auch der Grund, warum die Firmen
uns vertrauen, weil
wir halt nicht bezahlt werden
von Amazon oder von Microsoft,
wo am Ende klar ist, egal was
der Berater sagt, der
verkauft die Produkte von seinem
Arbeitgeber.
Und
das andere ist natürlich,
wenn wir
Body Leasing machen, okay, das Wort darf ich
gar nicht verwenden.
Wir wissen alle, was du meinst, wenn du jetzt
ein anderes Wort benutzt.
Ja genau, also wenn wir Leute
hands-on hinsetzen,
dann verkaufen wir auch nicht die
Person, sondern das Wissen.
Das heißt, wenn sich die Anforderungen
der Stelle ändern,
wenn wir jemanden hinsetzen und der macht zum Beispiel
Jenkins, der ist dafür der Experte,
und dann ändert sich das
irgendwie, keine Ahnung,
weil sich die Teamzusammenhänge
ändern, die Plattform
ändert sich und dann zeigt sich im
Verlauf des Auftrags, oh, also eigentlich
suchen wir einen, der
Ruby macht, was ganz
anderes, der mit Ruby Automatisierung
Code schreibt, dann kann es sein,
dass der das Wissen nicht hat und dann setzt
wir einen anderen Mitarbeiter hin.
Das heißt, wir garantieren schon bestmöglich,
dass wir
unabhängig immer das
beste Ergebnis liefern.
Jetzt hast du eben einen Punkt angesprochen,
der, glaube ich, auch ein sehr wichtiger ist in dem
DevOps-Umfeld, nämlich das Thema Experten,
gute Leute.
Und jetzt hast du eben natürlich auch gesagt, Mensch,
ihr habt immer die guten Leute da, immer
die Experten und könnt auch mal dann entsprechend
austauschen.
Wie kriegt ihr denn die Leute?
Wie sieht das bei euch ein Recruitment aus,
um die Leute zu bekommen, die ihr
dann dementsprechend in die Projekte bringt?
Auch sehr bunt.
Also wir haben auf der einen Seite natürlich Experten.
In meinem Team
sitzen Leute, die sind
viele, viele Jahre jünger als ich.
Das sind wirklich wahre Magier in der
Cloud. Die kennen
ein oder zwei Clouds jeweils so gut,
da werde ich niemals hinkommen.
Das sind natürlich dann Leute,
die man nicht auf Migrationsprojekte setzen
kann, wo es darum geht, erstmal
den Bare-Metal-Cluster
vom Kunden zu analysieren
und mit irgendwelchen Oldschool
Linux-Tools zu arbeiten.
Das heißt, wir versuchen möglichst
unterschiedliche Profile zu haben,
die man hinterher auf dem Projekt
möglichst gut kombinieren kann.
Mir persönlich
ist immer am wichtigsten,
dass der Kandidat, der
sich bei uns bewirbt, denken kann.
Also ein Großteil von meinen Interviews geht
nicht darum, dass ich ihn abfrage,
ach Gott, keine Ahnung, mit welchem
Befehl machst du
folgendes oder löst du folgendes Problem.
Das gibt es ja auch.
Sondern ich stelle tatsächlich Fragen,
wo der Kandidat hoffentlich die Frage
noch nie gehört hat und denken muss.
Da geht es mir ganz viel darum,
dass der Kandidat Dinge erklären
kann und die Hintergründe
versteht zu den Themen,
die er denkt, abzudecken.
Also wenn zum Beispiel jemand kommt und sagt,
ja, ich bin ja der Meister mit
Kubernetes,
dann würde ich zum Beispiel anfangen mit der Frage,
was ist Docker?
Und an der Frage scheitern schon so
viele Leute. Also man sollte glauben,
dass jemand, der sich bewirbt als
Kubernetes Cloud Experte,
dass der die Grundlagen kennt.
Aber ich kann nicht jemanden
zum Kunden schicken, der nicht erklären
kann, was er macht.
Und das heißt ja,
ist so.
Das sind Leute,
das sind Leute, die sitzen ohne Aufsicht,
also ohne, dass ich denen auf die Finger
schauen kann oder will,
sitzen die, keine Ahnung, vier Wochen
beim Kunden und ich muss wissen,
dass die mit dem Kunden gut
auskommen. Auf technischer Seite,
aus persönlicher Seite und dass sie den Kunden
gut beraten. Und wenn dann
die Antwort auf die Frage, was ist Docker?
Ja, das ist
so, puh, äh, nee.
Das geht nicht.
Also, dass jemand denken sollte, finde ich schon eine gute
Voraussetzung, eine gute Einstellungsvoraussetzung.
Ähm, vielleicht auch noch ein bisschen
fühlen, also ein bisschen Empathie mitbringen,
wenn wir über das Thema Kultur sprechen.
Ja, also Empathie kriegt man immer raus.
Ich finde so ein Interview ist so ein bisschen
wie flirten. Äh, wahrscheinlich ist das
auch so ein bisschen wie ein Podcast machen,
da hast du mehr Erfahrung. Aber am Ende
muss irgendwie vom Kandidaten
zu mir der Funke übergesprungen sein,
dann ist gut. Super.
Ja, überspringen.
Lass uns mal überspringen
in die Zukunft. Ähm,
ab und zu packe ich mit meinen
Gesprächspartnern hier
die Glaskugel aus. Ich hoffe, du hast
auch eine Glaskugel dabei. Ähm,
wie sieht denn die Zukunft von
DevOps aus und wie sieht dann
auch die Zukunft einer DevOps-Beratung
aus, aus deiner Sicht?
Die Zukunft zu sehen ist ja immer ein bisschen
schwierig. Ähm, also
ich glaube, und das macht mich auch
stolz, wir sitzen im einzigen
Teil der Industrie
weltweit, der sich selbst abschafft.
Ähm, so dass
das große Motto von DevOps ist
ja Automatisierung.
Ähm, und am Ende
von der Automatisierung dieser ganzen
Infrastrukturprozesse steht
eigentlich meiner Ansicht nach, dass
die Abstraktion, dass
die Abstraktion erlaubt, ähm,
die ganze Infrastruktur
komplett auszulagern.
An andere, zum Beispiel
an Public Cloud Provider.
Und ich glaube, das ist, wo wir hinkommen werden.
Ich glaube, die, dass das
DevOps als Begriff verschwinden wird
und das wird einfach, äh, normale
Entwicklungsarbeit sein.
Niemand wird mehr sagen, machst du Infrastruktur
oder Code, sondern jeder, der Code
schreibt, wird in, keine Ahnung,
fünf bis zehn Jahren wissen,
dass die Tools so gut geworden sind, dass der
Code automatisch deployed wird.
Und da wird’s Leute geben, die noch QA-Tests
schreiben, aber, ähm,
das, was wir als DevOps verstehen,
automatisierte Infrastruktur
und das Mindset, was man
braucht, wird, glaube ich, größtenteils
verschwinden. Und, äh,
ich bin da, ehrlich gesagt, ganz glücklich drüber.
Also, ich hab ja anfangs
auch ziemlich stark die Cloud bekämpft,
als, als modernes Scheiß
und viel zu unsicher. Aber,
wenn man mal sich ein paar Firmen
angeschaut hat, dann stellt man fest,
dass, ähm,
dass der Public Cloud mit vernünftigen
Default-Einstellungen, ähm,
es viel, viel leichter macht, sichere
Software zu deployen, als eine Firma,
die alles selbst macht.
Also, gerade in Berlin ist es wahnsinnig
schwer, gute Admins zu kriegen.
Und wenn man das Problem auslagern kann
in die Cloud, ist das für uns
als Menschheit ein Schritt nach vorne.
Dann sind wir noch nicht so sicher,
wie ich gerne wäre. Also, ich hab höhere
Ansprüche, aber es ist ein Schritt nach vorne.
Und, ja, ich glaub,
ich glaub, in fünf bis zehn Jahren spricht
niemand mehr von DevOps, ähm,
und alle machen einfach
Code.
Machen Code und liefern gute Applikationen
und, äh, steigern den, den
Nutzen für den Kunden.
Und ich denke, wir werden, also jetzt gerade durch
diesen, durch diesen Corona-Kram,
werden wir alle wesentlich verteilter arbeiten.
Ähm, man sieht jetzt ja
sehr schön, dass Firmen, die vorher sich immer
vehement geweigert haben, Remote oder
Home Office zu machen, plötzlich
gezwungen werden. Und, also, ich glaube,
das klappt für die meisten Firmen ganz gut.
Ja. Also, ich höre, ich höre
eigentlich nirgendwo, dass eine Firma sagt,
äh, sie gehen jetzt ein, weil sie
plötzlich mit Google Hangouts arbeiten
müssen. Und das
wird, glaube ich, viel interessanter werden, auch wieder
aus kultureller Sicht, ähm,
wenn der, wenn der Startschuss
erstmal gefallen ist für wirklich
verteilte Teams, dann
wird wahrscheinlich in Zukunft relevanter
sein, in welcher Zeitzone man arbeitet
und nicht in welcher Stadt.
Also, dass wir alle ausgelagert werden
nach Indien, das glaube ich nicht. Das ist ja immer
so das, das Schreckensszenario,
äh, einfach weil die Synchronisierungspunkte,
sowas wie ein Daily oder Meetings,
die sollten schon ungefähr für alle
in der gleichen Zeitzone liegen.
Aber ich glaube, gerade im Industriebereich,
äh, wo es um Entwicklung geht,
werden die Leute nicht mehr so viel
zusammensitzen. Was ich jetzt gehört
habe, ist, dass viele Führungskräfte, oder
nicht viele, also ich weiß jetzt den Prozentsatz
nicht, aber dass es Führungskräfte gibt
und es waren eben, war keine kleine Anzahl,
die einen Kontrollverlust
fürchten. Und, ähm, das ist natürlich,
äh, eigentlich
eine Bankrotterklärung
zum, zum eigenen Führungsstil wahrscheinlich. Ja.
Lass, lass sie die Kontrolle verlieren.
Das finde ich gut. Nichts ist schlimmer, als
Micromanagement.
Genau, das ist richtig. Aber gut, wir reden hier über Kultur
und, ähm, insofern sind wir beide
da wenigstens einer Meinung an der Stelle.
Sehr schön. Gut,
das waren, ähm, ich glaube 45
Minuten wieder, ähm, super interessant.
Ähm, ich bedanke
mich. Ich, ähm, bin
positiv überrascht, wie gut wir aus
meiner Sicht Technik und Kultur
zusammengebracht haben an der Stelle. Deswegen
bedanke ich mich da für deine Unterstützung.
Und, ähm, ja,
vielen Dank, wie gesagt, nochmal für deine, für deine
ähm, Unterstützung hier.
Ja, ich danke dir.