Discover the Art of Asynchrony: Building resilient systems for a dynamic world

Discover the potential of event-driven architecture (EDA) in this engaging workshop. Do you remember the 'matrix' keynote by Werner Vogels at re:Invent 2022? He highlighted the essence of our dynamic reality: "The world is asynchronous". By embracing asynchrony, we can design systems that reflect the natural order and unlock unparalleled scalability. Loosely coupled systems, rooted in EDA, enable scalable collaboration between autonomous components, making adapting to change easier. Striving for evolvable architectures leads to event-driven architectures.

In this workshop, you will start with a sketch of an existing synchronous system. You will work in small groups to figure out how you could change this architecture to be event-driven and asynchronous and what benefits and downsides that brings. You will share your solutions and be inspired by the solutions of others.

Gain practical insights, learn core concepts, and apply EDA principles to architect responsive, scalable systems. Experience the power of asynchrony, embrace loosely coupled designs, and build for the future.

Doing Multi-Cloud the Easy Way... But should you?

In today's rapidly evolving technological landscape, organizations are increasingly adopting cloud computing as a means to enhance scalability, flexibility, and efficiency. However, with the advent of multi-cloud environments, the decision-making process becomes more complex, with challenges in managing different infrastructures, APIs, and service offerings. You have to come up with a solid multi-cloud strategy.

Luckily, there are many tools that make it easier to run multi-cloud, we'll look at some of these, like Kubernetes, Terraform, Dapr and Wing lang. These tools act as a middleware layer that abstracts away cloud-specific complexities. They enable developers to build distributed applications that can run consistently across multiple cloud providers. They simplify the development and deployment of multi-cloud applications by providing a unified programming model and a set of building blocks that work seamlessly across different clouds.

That sounds great! But should you do this? What are the trade-offs that they bring? Do they truly prevent vendor lock-in? And what are you loosing by not making full use of what your cloud vendor has to offer?

Event Sourcing in code, who needs frameworks!

You've heard about Event Sourcing, it sounds like a useful technique that can potentially make some really hard problems a lot easier. But where do you start? There are many talks about the theory and application of Event Sourcing, but what does it actually look like in code? And why is the Kotlin language such an excellent match for writing event sourced applications?

As Event Sourcing is a complicated topic we'll start with a short introduction to some of the key concepts like Event Sourcing, CQRS, command pattern and projections. Event Sourcing is not for everyone. It requires a significant shift in how you think about your data. Event Sourcing is also not always easy, so we'll point out some pitfalls and guide you on when it's worth using it and when you should stay away from it.

However, Event Sourcing is also super-valuable when it fits your needs! And if you approach it in the right way, it does not have to be as hard as you may think. With some live coding, we'll build up an event sourced model using the CQRS pattern. Along the way you'll get a taste of how these techniques work in code and how typical Kotlin constructs like data classes, immutability, lazy properties and functional style will help you to keep it all readable and easy to understand. You'll see that you don't need to start with a framework to do Event Sourcing. The Kotlin language provides a lot of the fundamentals that you need and that allows you to keep everything simple and in your own control.

Playing with domain models in code

Two brains, one domain, one laptop, and a guarantee for 2 hours of fun and learning. You’ll go back to basics. Talking about the domain, designing the model and explore coding the model in Java or Kotlin with close to no libraries.

This is a hands-on coding workshop where you will work in pairs together with other participants. Your base will be the output of an EventStorming session and some context about the domain that you'll be modeling. Together, you'll play around, modeling parts of the domain in code, using tests to guide your design.

A starter project will be provided to get you up and running quickly, you can choose between Java or Kotlin. All you have to bring is a laptop with a recent version of IntelliJ installed (only one laptop per pair is needed). Throughout the workshop, pairs will share their approach so we can all learn from each other.

What you will learn:

- Why you need to start by understanding the problem before you start coding.
- How to 'sketch' in code and tease out a model bit by bit.
- Not to be afraid to throw away the model and sketch again.

How the right architecture helps you make big changes (workshop)

You want to move to a different framework, or maybe you have to upgrade that really outdated library, but where do you start? And how do you do that in small steps? This workshop lets you experience how architectures and techniques like hexagonal, vertical slice and domain driven design can help you move through big transformations, while at the same time increasing your code quality!

Like many of us, your codebase is likely not a nice small microservice and you cannot afford to spend months working on a rewrite. Instead you need to take small steps. But small steps and keeping everything working may seem like a daunting approach. During the workshop, you will will get you acquainted with several techniques and the right mindset that will allow you to make big changes in small steps.

Applied EventStorming, from knowledge to working domain model in one day

Two brains, one domain, one laptop, and a guarantee for a day of fun and learning. You’ll go back to basics. Talking about the domain, exploring it using EventStorming with a small group and then pair up to design and code the model.

The day starts with an EventStorming session to explore an interesting domain. You will work in small groups, making sure everyone in the group guards a portion of the EventStorming session by taking on specific roles. But we won't stop after we've explored the domain.

The second part of the day you will work in pairs, together with other participants. You will use the output of the EventStorming session and all the knowledge that you've gathered about the domain. Together, you'll play around, modeling parts of the domain in code, using tests to guide your design. You can choose from several starter templates, to help you code the domain using different approaches. From a typical object oriented domain model to an event sourced domain model. Throughout the workshop, pairs will share their approach so we can all learn from each other.

All you have to bring is a laptop with a recent version of IntelliJ installed (only one laptop per pair is needed). Java or Kotlin templates will be provided, or you can choose to use your own preferred stack.

What you will learn:

- Why you need to start by understanding the problem and exploring a domain before you start coding.
- How to 'sketch' in code and tease out a model bit by bit.
- Not to be afraid to throw away the model and sketch again.
- That there are many ways to implement a model and that there are tradeoffs to make when choosing an approach.

Kotlin multiplatform + Domain models = ❤️

In most of the applications we write, most of the domain model with all the crucial business logic only lives in the backend to ensure consistent behavior of a system. But with Kotlin multi-platform, that same domain model can suddenly also be used in your user-facing applications.

In this talk, we will look at what that means for the applications you build. What does your code look like when you share your domain model? How do you ensure that that domain model is re-usable? What kind of trouble can you run into and what techniques can you use to avoid that trouble? And how does the ability to use the full domain model benefit the user experience? And last but not least, how can your organizational team structure make this way of working a huge success or a road towards disaster?!

CDK: Are we on the road to infrastructure Nirvana?!

What happens when you apply a software engineering mindset to infrastructure as code? With the rise of Cloud Development Kits, a new world is opening up. How do full-featured programming languages allow us to express the needs of our solutions? And how do you code these higher level abstractions?

It feels like we have yet to unlock the potential that CDKs bring us... what will it take to reach infrastructure Nirvana... can we ever declare our high-level non-functionals and let the infra code make it happen?!

Observability from 0 to 100

We all know that our systems need to be more observable, but how do you get to valuable insights? Can you really get up and running as fast as vendors let you believe? And what are the places where it is worth spending extra time to get things right? Observability capabilities have been growing rapidly over the last years. Many vendors and tools exist in this field, with offerings varying in customizability and out-of-the-box capabilities. In this talk we'll take a look at what you need to do to get observability going for your platform and applications.

We go beyond the marketing-talk and see what it is like to build up proper observability. To make it concrete we'll do that for a Kubernetes cluster running JVM applications for which we will gather logs, metrics and traces to an Elastic stack. We'll manage all the configuration as Infrastructure-as-code with the CDK for Terraform. Along the way we will share some key ingredients that we discovered that make your observability setup more effective and downright simpler. Expect to discover what you need to do, not just on infrastructure level, but also in application code, and most important: on organizational level, so you can expose everything to the people that need it most in a secure way.