“Verzichtet auf Conference-Driven-Development” -- Freiberuflerin Sandra Parsick
Wer bist Du und was machst Du?
Mein Name ist Sandra Parsick. Ich bin Jahrgang 1983, also ein Vertreter der Generation Y (je nachdem welcher Studie man glaubt :o) ). Ich arbeite als freiberuflicher Softwareentwickler und Berater mit den Schwerpunkten Backend-Entwicklung im Java-Umfeld sowie Continuous Integration bzw. Delivery. Darüber rede ich gerne auf Meetups und Konferenzen und manchmal schreibe ich Artikel oder Blogbeiträge dazu. Ich helfe auch die Softwerkskammer Ruhrgebiet zu organisieren. Meine Ausbildung verlief ganz klassisch: Nach dem Abitur studierte ich allgemeine Informatik an der Uni Bonn und hab das Studium noch mit einem Diplom abgeschlossen. Ich lebe mit meinem Mann in Neuss bei Düsseldorf.
Wie bist Du zu Deiner Qualifikation gekommen und hast Du schon immer diese Tätigkeit (z.B. Softwareentwicklung) ausgeübt?
Nach dem Studium habe ich erstmal ein Jahr als QA gearbeitet, bevor ich dann in die Entwicklung gewechselt bin. Dort hatte ich das Glück in einem Team zu arbeiten, das auf Clean Code und TDD geachtet hat. Danach bin ich in eine Firma gewechselt, die gerade eine neue Entwicklungsabteilung aufbaute und ich konnte die Continuous Integration Einführung mitgestalten. Irgendwann bin ich auf die Software-Craftsmanship-Community aufmerksam geworden und fing an mich dort zu engagieren, das half mir über meinem Java-Tellerrand zu schauen. Dann kam der Punkt, wo ich mit dem Modus Festanstellung unzufrieden war und paar Kollegen machten mir Mut es doch mal als Freiberufler zu versuchen. Da wurde ich neugierig, dachte warum nicht, hab es dann einfach ausprobiert und bin zufrieden mit dieser Entscheidung.
Was liebst Du an Deinem jetzigen Job und auf was könntest Du verzichten?
Ich finde es spannend mit Anderen Probleme zu lösen. Man hat eine Idee, der andere greift sie auf, denkt sie weiter und dann entstehen Lösungen auf die man alleine niemals gekommen wäre. Was nervig ist, wenn Lösung durch neue Lösung ersetzt werden ohne einen Mehrwert zu generieren, nur um das “new shiny tool” einsetzen zu können. Ähnlich problematisch finde ich auch Entscheidungen für eine Lösung, die Buzzword getrieben sind, oder wie ich es am liebsten nenne “conference-driven-development”.
Wie sieht Dein typischer Arbeitsalltag aus?
Ich stehe meist zwischen 6-8 Uhr auf. Manchmal gehe ich vor der Arbeit eine Runde Laufen oder Schwimmen. Dann geht es entweder zum Kunden (wenn er gerade heimatnah ist) oder ich arbeite im Home Office. Ich nehme mir aber manchmal auch die Freiheit antizyklisch zu arbeiten, wenn es effizienter ist private Aufgaben vormittags zu erledigen. Wenn ich auf Konferenzen unterwegs bin oder Auswärtstermine habe, sieht der Tag dann ein wenig anders aus. Komm dann stark darauf, wo ich gerade bin.
Gönnst Du uns einen Einblick in Deinen aktuellen Arbeitsplatz?
Im Home Office arbeite ich auf einem ThinkPad T460s. Als Betriebssystem läuft ein Kubuntu 18.04. Monitore sind zwei Dell UltraSharp U2414H. Als Schreibtisch dient ein höhenverstellbarer Tisch von Ikea.
In Deinen Vorträgen und Interviews kritisierst Du den teils übertriebenen Einsatz von Containertechnologien, wie Docker und Kubernetes. Kannst Du kurz erläutern, was Tools wie Docker und Kubernetes leisten und warum Sie zum “Hype” im Bereich IT-Infrastruktur geworden sind?
Ein Container löst das Problem, dass ich meine Anwendung mit ihren Abhängigkeiten zu einer Einheit verpacken kann und diese von anderen Anwendungen isoliert laufen lasse. Zusätzlich bieten sie eine standardisierte Art und Weise der Auslieferung der Anwendungen an. Zu dieser Definition passt nicht nur Docker, sondern auch andere Tools wie Tomcat für Java-Anwendungen. Kubernetes kommt ins Spiel, wenn ich anfange meine Anwendung auf mehrere Container zu verteilen und diese Container dann auch noch skalieren möchte. Kubernetes hilft mir dabei, die Container auf mehreren Maschinen zu verteilen und sie automatisiert zu skalieren. Aber eine berechtigte Frage ist dennoch, müssen alle Anwendungen auf mehrere Container verteilt werden und brauche ich die Möglichkeit der automatisierten Skalierung? Technologiestack-unabhängige Container-Technologien gab es auch schon vor Docker (Bsp. LXC). Dockers Verdienst ist, dass sie eine Container-Technologie geschaffen haben, die einfacher zu benutzen ist als die bisherigen. Zusätzlich hatte Docker das “Glück”, dass im selben Zeitraum Microservices “gehypt” wurden und somit der Bedarf für Werkzeuge wie Kubernetes da war.
In welchen Szenarien macht der Einsatz dieser Containertechnologien keinen Sinn? Welche Nachteile ergeben sich in solchen Fällen?
In meinen Augen macht es für viele Java-Anwendungen keinen Sinn diese nochmal in einen Container zu stecken, da Java sein eigene Container-Mechanismen mitbringt (Fat-JARs, WAR etc). Ich ziehe mir nur eine zusätzliche Abstraktionsschicht rein und somit mehr Fehlerquellen ohne nennenswerten Mehrwert (außer das man vielleicht jetzt “hip” ist). Bei einem anderen Technologie-Stack, der keine eigene Container-Mechanismen mitbringt, kann der Container-Ansatz schon hilfreich sein. Aber da muss man den gleichzeitigen Einsatz von Kubernetes von Anfang an hinterfragen. Habe ich erstmal einen kleinen Verbund, dann empfehle ich erstmal mit Docker Compose anzufangen, um die Komplexität gering zu halten. Wenn Docker Compose dann an seine Grenzen stößt, dann vielleicht erst mit Docker Swarm weiter machen und wenn das dann auch nicht hilft, dann kann man sich die Komplexität von Kubernetes reinzuholen. Ein weiterer Vorteil von diesem Vorgehen, die Technologien werden Schritt-für-Schritt reingeholt und die Komplexität steigt langsam an.
Welche klassischen bzw. leichtgewichtige Alternativen kannst Du gegenüber Kubernetes und Docker empfehlen? Eine Automatisierung und Kapselung zur Verwaltung und Betrieb von Softwareprodukten strebt ja wahrscheinlich jedes Projekt an ….
Wenn keine Container benötigt werden oder der Technologiestack seine eigene Container-Mechanismen mitbringt, dann empfehle ich klassische Provisionierungswerkzeuge zu benutzen wie Chef, Puppet oder Ansible. Werden Features wie Cluster-Management oder Service Discover gebraucht, dann lohnt sich auch ein Blick auf den Hashicorp-Stack zu werfen. Dieser Stack ist nach der UNIX-Philosophie entwickelt worden - jedes Werkzeug löst genau ein Problem - und ist daher meiner Meinung nach leichtgewichtiger als Kubernetes.
Moderne Softwarearchitekturen setzen auf Microservices. Hier bieten sich Container- und zugehörige Orchestrierungs-Tools wie Kubernetes für die Kapselung und Steuerung an. Siehst Du das auch so oder hast Du noch andere Empfehlung für den Betrieb von großen Microservice-Architekturen?
Ja, wer was von sich hält macht Microservice ;). Aber nein mal im Ernst, ob Microservice Sinn macht oder nicht kommt ganz stark auf die Anforderungen an. Vielleicht kommt man auch zu dem Entschluss, dass ein modularisierter Monolith die bessere Lösung ist. Dann sollte auch ein Monolith gebaut werden. Aber zurück zur Frage: Klar helfen da Docker und Kubernetes. Aber auch da gibt es Alternativen: Je nachdem wie groß die Microservice-Architektur ist, wäre für die Container-Orchestrierung Docker Swarm eine Alternative. Oder wenn nicht alle Kubernetes-Features benötigt werden, dann können Werkzeuge aus dem Hashicorp-Stack eine Alternative sein. Wird z.B. nur ein Cluster-Management-Werkzeug gebraucht, dann benutzt man nur Nomad. Nomad hat auch den Vorteil, dass es neben Docker-Container auch noch andere Deployment-Formate wie JARs unterstützt.
Was machst Du in Deinem anderen Leben? Was tust Du für Deine Work-Life-Balance?
Eigentlich habe ich ja eines meiner Hobbys zum Beruf gemacht. Wenn ich mal nicht vorm Rechner sitzen möchte, dann spiele ich Schlagzeug oder treffe mich mit Freunden. Wenn es mal ruhiger sein soll, lese ich gerne Bücher, querbeet durch alle Kategorien. Im Sommer gehen mein Mann und ich gerne Segeln und im Winter Snowboarden.
Wo kann man dir im Netz folgen? Wie kann man dich am besten kontaktieren?
Mich kann man auf vielen Kanälen erreichen:
- Twitter: @SandraParsick
- Xing: xing.to/sparsick
- E-Mail: mail@sandra-parsick.de
- Website: www.sandra-parsick.de