"Mit der anderen Technologie wird alles viel einfacher. Das neue Framework lässt uns schneller entwickeln. Wenn wir das Modul nochmal neu bauen, machen wir gleich alles richtig."

Und dann stehen wir später da und fragen uns, warum der Wartungsaufwand schon so hoch ist, warum alles wieder so kompliziert ist und wo die ganze Effizienz durch tolle Tools oder neue Hardware geblieben ist. Kennt Ihr das auch?

Der Talk beleuchtet wie wir in der Softwareentwicklung in die Effizienz- und Innovationsfalle tappen, versucht aufzuzeigen, was wir dagegen unternehmen können, indem wir nach Einfachheit streben, und wie uns die Suffizienz als "große Schwester" der Effizienz helfen kann.

Achtung: Enthält keine "Best Practices" oder "Silver Bullets", aber Anregungen zum Selber-Weiterdenken!

Hört die Geschichte eines Unternehmens, das sich auf dem Weg von der alten monolithischen On-Premise-Wasserfall-Welt zur neuen modularen, agilen, domain-driven, mandantenfähigen, cloudbasierten Microservices-Welt befindet. Die Herausforderungen kommen aus verschiedenen Richtungen: Sowohl technische als auch organisatorische Aspekte müssen gemeistert werden. Die Domäne muss verstanden werden, damit das System richtig strukturiert werden kann. Der große Knall muss vermieden werden.

In diesem Vortrag werden wir uns ansehen, wie unser »fiktives« Unternehmen mit diesen Herausforderungen kämpft und sie schließlich überwindet.

Event Storming ist eine Methode des Domain Driven Design, die es ermöglicht, sich gemeinsam die Fachlichkeit einer Anwendung zu erarbeiten. Richtig angewendet und bis zum Ende durchgeführt, bietet Event Storming aber noch mehr. Das Ergebnis kann nämlich sehr gut verwendet werden, um darauf basierend Bounded Contexts zu identifizieren.

Diese zeichnet dabei aus, dass wenig Kommunikation über Kontext-Grenzen hinweg passiert und das diese Kommunikation insbesondere robust ist.

In der Session stellen wir die Methode Event Storming vor und zeigen, wie man über die Methode Bounded Contexts ermitteln kann und diese so gestalten kann, dass sie lose gekoppelt sind, so dass es auch nicht problematisch ist, wenn ein Service temporär ausfällt.

Die falsche Architekturentscheidung heute kann morgen zu Kosten, Verzögerung und Leid führen. Wir können versuchen, das Problem durch sorgfältige Planung zu lösen - Qualitätsbäume malen, Referenzarchitekturen zücken - und trotzdem können die sich daraus ergebenden Entscheidungen falsch sein. (Oder falsch werden, wenn sich Anforderungen oder Kontext ändern.) Eine bessere Strategie ist, die großen Entscheidungen möglichst spät zu treffen, weil wir dann mehr wissen und sie auch leichter ändern können. Dieser Talk zeigt wie das geht mit:

• konsequente Entkopplung durch Abstraktion
• funktionale Domänenmodelle mit kleinen flexiblen Kombinatoren anstatt starrer Attributstrukturen
• unverändlichen Daten, um versteckte Abhängigkeiten zu vermeiden

The IT sector, being an important driver of digitization, must make its own contribution to achieve the ambitious climate targets.

The cloud, as a utility, is a growing factor for running more and more services.

Knowing your workloads and resource consumption is key for optimization.

To not fail into a new trap, I'll present some practical aspects on how you can improve your carbon foot print by switching to a "green cloud".

With an AWS demo project, I'll demonstrate tools and methods, to estimate your carbon footprint and gain recommendations to reduce it as well.

Thereby, the competing interests of economy and ecology can be combined for a better future for us all.

Software Architecture is about the important things, where "important" means high-risk and hard-to-change decisions.

DevOps tries to develop a culture where constant experimentation and learning takes place while the environment changes rapidly.

In this talk we will explore general strategies agile teams can use to build and foster a DevOps culture while at the same time ensuring high-quality and sustainable software delivery.

These strategies will be illustrated with real-world examples from different domains and environments.

While discussing these examples we will make the general ideas and principles tangible and connect them with proven and executable practices that can directly be applied.

Architekturen, die Unfälle waren und warum es zu diesen Unfällen kam.

1. Unfallszenario
   Von der Brücke direkt in den Maschinenraum oder warum Datenbankdirektzugriffe nicht immer der bessere Weg sind
2. Unfallszenario
   Es kommt nicht nur auf die inneren Werte an
   Gute Serviceschnitte sind toll, aber wenn sie den Benutzer nerven wird es schwierig.
3. Unfallszenario
   Ali Baba und die 40 Microservices
   Wenn ein Team zu viele Microservices hat, ist irgendwas verkehrt.

Der Vortrag erläutert die Szenarien und warum die vorgestellten Architekturen Unfälle sind und wie es dazu kam. Als Take Aways werden Hinweise gegeben, wie man Unfälle vermeiden kann.