The great MVP Swindle (45 min)

Kaum ein Begriff ist in den letzten Jahren in der Softwareentwicklung so überstrapaziert worden wie der des MVP. Das Minimum Viable Product ist mal Heilsbringer, mal Fluch und wird allzu gerne instrumentalisiert, um für und wider alles Mögliche zu argumentieren. Da wird ebenso leichtfertig technische Schuld auf sich genommen wie nur halbherzig getestet: „Ist ja erst mal nur ein MVP.“ Im Kern geht die Schwammigkeit und daraus resultierende Interpretationsfreude auf zwei unterschiedliche Definition des Begriffs zurück, die gegensätzlicher nicht sein könnten. Zeit aufzuräumen, kritisch auf Kontext und Anwendungsfall zu blicken und für mehr Klarheit zu sorgen, wann welcher MVP welchem Zweck dient, um ihn aus seinem zwangsverordneten Selbstzweck zu befreien.

Hias Wrba

Mathias „Hias“ Wrba ist Managing Director des Münchner Standorts der UX&I GmbH und arbeitet seit über 15 Jahren als User-Experience-Stratege im Bereich digitale Produkte. Außerdem ist er Dozent bei artop – Institut an der Humboldt Universität Berlin – und schult dort den von ihm mitentwickelten Ansatz UX Thinking.

Svelte – the framework without a framework (15 min)

Bei modernen Webseiten wird heutzutage oft schon beim ersten Aufruf sehr viel Code an den User geschickt. Das beeinträchtigt sowohl die Ladezeit als auch die Performance. Eine vielversprechende Verbesserung könnte der Ansatz von Svelte sein.

Svelte ist ein radikal neuer Weg, um Boilerplate-freie Webanwendungen zu entwickeln. Es ist ein komponentenbasiertes Framework, bei dem der Code während des Build-Prozesses in kleine, hoch effiziente Standalone-JavaScript-Module kompiliert wird. Svelte definiert zudem State Management neu, hilft dabei, weniger Code zu schreiben und ermöglicht eine einzigartige Developer Experience.

In diesem Talk lernst du Svelte grundlegend kennen und erfährst, wie es sich zu traditionellen Frameworks wie React unterscheidet. Des Weiteren schauen wir uns kurz Sapper an, ein Next.js-style Framework, das auf Svelte basiert.

Manuel Berger

Mein Name ist Manuel, ich bin ein begeisterter Full-Stack Entwickler mit einem starken Fokus auf Front-End, da man so näher beim User ist. Meine Karriere begann in einem Softwarekonzern, dann in einer Digitalagentur, bis ich 2020 als Softwareentwickler zu codecentric gestoßen bin. Neben JavaScript liebe ich die Berge und interessiere mich für Themen rund um die bemannte Raumfahrt.

How not to JavaScript – Anleitung zum Unglücklichsein (30 min)

Du hast ein Problem oder eine Idee und denkst darüber nach, das mit JavaScript zu lösen? Wir können dir zeigen, wie du das Projekt zu einer möglichst schmerzhaften und umständlichen Erfahrung machst! Wir haben alle unsere Fehler und Schwachstellen aus allen möglichen JavaScript-Projekten gesammelt und zu einem tollen Projekt zusammengeführt. Aber keine Sorge, wir haben überlebt und wollen nun mit dir teilen, was du besser nicht tun solltest...

Christina Zenzes

Christina Zenzes ist als Consultant und Software Developer bei der codecentric AG tätig. Ihre Leidenschaft gilt React, CSS, Clean Code und Testen (ja, wirklich!). Neben dem Schreiben von funktionellem JavaScript-Code liebt sie es, Pflanzen auf ihrem Balkon zu züchten, Katzen zu streicheln und gutes Essen.

Anna Backs

Anna Backs arbeitet als APM Consultant für die codecentric AG. Wenn sie nicht gerade mit ihrem Hund draußen unterwegs oder in der Welt von Shadowrun vertieft ist, dann ist sie wahrscheinlich damit beschäftigt, etwas in Java oder JavaScript zu bauen. Kaffee, gute Geschichten und neue Dinge zu lernen gehören zu ihren Vorlieben.

Wie Primaten und Warzenschweine uns halfen, resilienter zu werden (45 min)

Manchmal kann man sich als Software Engineer schon vorkommen wie ein Zirkusdompteur: Auf der einen Seite ein stetig wachsender Technologie-Zoo, der gebändigt werden muss, auf der anderen Seite verlangt das Publikum immer mehr und beeindruckendere Features in schnellerer Abfolge. Und am besten werden die neuen Features nicht wie früher von Menschen einzeln in die Produktions-Manege hereingeführt, sondern mit der großen CI/CD-Kanone mitten hinein geschossen!

Dass dabei schon einmal was schief gehen kann, leuchtet ein, denn in diesem Chaos verstecken sich dunkle technische Schulden, die meist erst in Produktion erwachen, mitten in der Vorstellung!

Doch es stellt sich heraus, dass gerade die vermeintlichen Unruhestifter in unserer Tiergemeinschaft unsere besten Freunde sind, wenn es darum geht, für Stabilität zu sorgen. Tools wie der Chaos Monkey (for Spring Boot) oder Pumba das Warzenschwein in­ji­zie­ren gezielt überschaubare Störungen, so dass wir, und unsere Softwarelandschaft, lernen, damit umzugehen. Denn eins ist klar: Das Chaos beherrschen ist unmöglich, vielmehr sollten wir es umarmen und uns gut mit ihm stellen, damit wir besser auf seinen unvermeidbaren Ausbruch vorbereitet sind.

Ob Product Owner oder Entwickler, für zukünftige Meister der Manege berichten wir über unsere Erfahrungen zur Etablierung einer Chaos-Engineering-Kultur. Viele Tipps & Tricks für einen erfolgreichen Start und wie man in das Thema Chaos Engineering in den Entwickleralltag integrieren kann. Neben Beispielen aus der Praxis für eine gelungene Zähmung der Akteure verraten wir auch die Top 5 der Ausreden, kein Chaos Engineering zu machen.

Oliver Kracht

Oliver Kracht arbeitet bei der DB Vertrieb GmbH als Implementation Lead. Seine Steckenpferde finden sich in den Bereichen der Softwareentwicklung sowie DevOps und Cloud-Technologien.

Jonas vor dem Berge

Jonas vor dem Berge arbeitet als Implementation Lead bei der DB Vertrieb GmbH.

Seit über 10 Jahren wirkt er in allen Phasen der Softwareentwicklung mit Schwerpunkt auf Webapplikationen.

Maik Figura

Maik ist introvertiert, stottert und liebt es, Talks zu halten. Was kann da schon schiefgehen?

Bei der codecentric AG kümmert sich Maik um Chaos Engineering. Dabei hat Maik schon so einiges gesehen. Vom kleinen Single-Service-Monolithen bis hin zu Service-Landschaften mit mehr als 400 Microservices. In seiner 20-Prozent-Zeit programmiert er am Chaos Monkey For Spring Boot.

Tatort: Cloudrechnung (45 min)

Wenn am Monatsende die Rechnung von AWS oder Google kommt, ist es im Projekt oft wie bei einem Kriminalfall. Viele haben ein Motiv, keiner will es gewesen sein, aber nicht alle haben ein stichhaltiges Alibi!

Bei jedem Projekt lässt sich jedoch eine heiße Spur von der Rechnung bis zu den Verursachern zurückverfolgen. Unsere zwei Inspektoren Sebastian und Nico nehmen euch daher mit auf ihre Ermittlungen, wie auch diesen Monat die Kosten wieder so hoch werden konnten.

Bei einer Live-Ermittlung überführen sie nach und nach große Haie und kleine Fische in einem typischen AWS-Account. Zudem gibt es für die Zuschauer noch praktische Tipps, mit denen man sich davor schützen kann, selber Opfer eines solchen Verbrechens zu werden.

Nicolas Byl

Nicolas Byl sammelte bereits während des Studiums der Medizinischen Informatik erste Erfahrungen im Umfeld Java-basierter Webportale und entdeckte seine Leidenschaft für verteilte Systeme. Bei der codecentric AG beschäftigt er sich mit skalierbaren cloud-nativen Infrastrukturen für die Applikationsentwicklung und ist als DevSecOps und Kubernetes-Trainer unterwegs.

Sebastian Jackel

Sebastian Jackel ist IT-Consultant mit den Schwerpunkten Cloud und DevOps. Wenn er nicht an Continuous-Delivery-Pipelines, Infrastructure as Code oder Monitoring von Services arbeitet, beschäftigt er sich gerne mit kosteneffizienten Cloudarchitekturen.

gotf – Umgebungen mit Terraform einfacher managen (15 min)

Wenn man mit Terraform mehrere Umgebungen (z. B. dev, staging, prod) hochziehen will, möchte man i. d. R. denselben Code dafür verwenden, allerdings mit unterschiedlichen Konfigurationen. Zudem muss man unterschiedliche Backends für den Terraform-State konfigurieren. Für Letzteres kann man jedoch nicht auf Variablen zugreifen. Man baut sich also meist ein Wrapper-Skript, das es erlaubt, Werte, die sowohl in den Terraform-Modulen als auch für das Backend gebraucht werden, an einer Stelle zu setzen, um Redundanzen zu vermeiden. Die Parameter für das Backend werden dann per Kommandozeile übergeben. Mit „gotf“ steht nun ein Tool zur Verfügung, das diese Aufgabenstellung elegant zu lösen versucht. Reinhard hat es entwickelt und setzt es auch in seinem aktuellen Projekt erfolgreich ein. Diese Session stellt das Tool vor und demonstriert dessen Verwendung (GitHub-Repository: https://github.com/craftypath/gotf).

Reinhard Nägele

Reinhard ist Senior IT Consultant am Münchner Standort der codecentric. Er blickt auf rund 20 Jahre Erfahrung in der Java-Entwicklung zurück, ist auch in Go, Python oder Kotlin unterwegs und terraformt sich durch AWS, Azure und GCP. In seinen Projekten setzt er sich sehr dafür ein, die Automatisierung voranzutreiben und hat in den letzten Jahren umfangreiches Wissen in Infrastrukturfragen rund um Docker und Kubernetes aufgebaut und dieses auch in Schulungen weitergegeben. Reinhard trägt gerne zu Open-Source-Projekten bei. Er engagiert sich in der Community rund um Kubernetes und ist Helm Maintainer.

AWS Best Practices as Code mit CDK (45 min)

Das Konzept von Infrastructure as Code ist in vielen Unternehmen mittlerweile ein integraler Bestandteil der IT-Systeme. Doch die wachsende Komplexität der IT-Landschaft und damit auch eine höhere Zahl der verwendeten Dienste lässt die Größe und die Struktur der Templates explodieren. Es ist zunehmend aufwendiger, tausende Zeilen einer YAML-Datei zu überblicken. AWS Cloud Development Kit (CDK) ist die nächste Evolutionsstufe im Infrastructure-as-Code-Prinzip. In diesem Talk schauen wir uns an, wie wir mit AWS CDK eigene Cloud-Infrastruktur-Bibliotheken für AWS erstellen, in einem Code-Repository publizieren und letztendlich in anderen Projekten nutzen können. Damit können wir die Best Practices in Cloud-Architektur, Security und Performance innerhalb des Unternehmen in gekapselte Bibliotheken auslagern und anderen Teams zur Verfügung stellen. Da wir mit CDK nun Code statt YAML schreiben, werden wir auch die Tools und die Prozesse der Softwareentwicklung wie Paket-Versionierung, automatisierte Tests, Code-Repository und Integration in CI/CD Pipelines nutzen.

Alexander Melnyk

Als Specialist Solutions Architect bei Amazon Web Services unterstützt Alexander viele Unternehmen in ganz Europa bei der Entwicklung moderner Anwendungen in der Cloud. Der Fokus liegt dabei immer auf robusten, skalierbaren, und performanten Systemen unter Einsatz von Open-Source-Technologien und modernen Entwicklungsmethoden.

SecDevOps im Serverless Computing (45 min)

Der Vortrag stellt anhand eines Beispiels dar, wie Serverless Computing genutzt werden kann, um zwischen API-Calls zu vermitteln. Dies ermöglicht die Verknüpfung heterogener IoT-Endgeräte und Backend-Systeme bei geringen Aufwand und Kosten. Gleichzeitig wird am Praxisbeispiel vorgestellt, welche einfachen Schritte beachtet werden können, um Sicherheitsmaßnahmen umzusetzen. Während des Vortrags werden hierbei folgende Services und Tools vorgestellt: AWS Lambda, Alexa Skill Kit (+ SDK) zzgl. Einblicke in Cloud9, AWS IAM, X-Ray, CloudWatch, AWS Config.

Aljona Wehrhahn-Aklender

IT Security Engineer, die sich leidenschaftlich im Cloud-Kosmos austobt und Erfahrung bei IT-Sicherheitsbehörden und marktführenden Herstellern von IT-Sicherheitslösungen sammeln durfte. Passend dazu habe ich die Studiengänge Medieninformatik wie auch IT-Sicherheit absolviert.

Ein Herz für Produktion (15 min)

„You build it, you run it“ ist einfach gesagt, aber deswegen kann man es ja noch lange nicht. Welche „Methoden“ gibt es, um ein Entwicklungsteam von „Runs on my Machine“ zu „Owns the Service“ zu bringen? Bei Matmatch sind wir mit so einem Problem gestartet (es gibt keine Operators) und haben es die letzten drei Jahre ohne Downtime, Dataleaks und Datenverlust geschafft. Lasst uns über Monitoring und Observability reden und wie man diese Infrastruktur in den Griff bekommt.

Christian Uhl

Christian war einige Jahre lang als Senior Software Consultant bei der codecentric AG tätig, bevor er als Head of Engineering zu Matmatch kam. Mittlerweile hat er eine große Vielfalt an verteilten Systemen gesehen und eine Vielzahl von Fehlern gemacht, die er jetzt teilen kann. Er interessiert sich besonders für verteilte Systeme und Microservices-Architekturen und ist immer neugierig, wie all diese Teile zusammenpassen. 

The road to SRE (45 min)

Site Reliability Engineering (SRE) in einer Organisation zu etablieren ist eine vielschichtige Herausforderung und beinhaltet weitaus mehr als nur das Überwinden technischer Hürden. Speziell im Kontext eines schnell wachsenden Startups gibt es, eine Reihe an Lektionen zu lernen.

Dieser Vortrag führt durch die Entwicklung des Operations-/SRE-Teams bei Instana. Von den frühen Anfängen, als für eine Handvoll wohl gesonnener Kunden viele Dinge einfach ad hoc erledigt wurden, über größere Plattform-Redesigns bis zum heutigen Tag mit Kunden aus aller Welt, denen wir 24/7-Verfügbarkeit und eine gute Produkterfahrung bieten wollen.

Im Laufe dieser Entwicklung gab es eine Reihe an Lektionen und Überraschungen – manche mehr, manche weniger offensichtlich – in Bezug auf die Auswahl von Technologien, Architekturentscheidungen und organisatorisch-prozessuale Fragen.

Bastian Spanneberg

Bastian Spanneberg  ist Teil des SRE-Teams bei Instana und hat die Entwicklung des Unternehmens seit seinen frühen Tagen erlebt.