Change is inevitable: versioning event-driven systems

Building an event-driven system is anything but trivial. However, once you make it past the sea of pub-sub vs. command-response debates and the service boundaries conundrum, you'll soon face the inevitable: change. The conversations that follow sound all too familiar... "Who's subscribed to this message?" "Do other services depend on this field in the payload?" "Why on earth is that thing in the payload?" "That service should never rely on this data!" And, of course, the obvious "Can't we -just- remove this?"

But are those the right questions to ask? As software developers, we aim to be agents of change, not chaos. To achieve this, we need to understand the impact of tweaking a message contract without breaking half of the system or forcing other teams beyond their deadlines. We should prioritize techniques that ensure compatibility while also considering how long that compatibility needs to be sustained. Oh, and let’s not forget that we’re supposed to solve this problem with zero downtime, as our users are spread across every time zone. In this session, we’ll discuss practical techniques and tooling that can enable the evolution of your event-driven system so that, next time a stakeholder approaches with a change request, your heart doesn't sink to the floor.

Orchestration vs. Choreography: The good, the bad, and the trade-offs

One of the goals of building microservice-based architectures is to reduce the complexity of individual components. In doing so, much of that complexity shifts from individual services towards interservice communication, making how we design those service interactions essential in our system design. That's where orchestration and choreography come in, two coordination techniques that can help us design complex workflows in our system. While the web offers numerous articles that carefully outline the pros and cons of each pattern, the real challenge is left to the reader: deciphering which pattern best fits your specific use case by understanding which arguments apply to your use case and weighing only the relevant ones in your decision.

In this session, we’ll thoroughly examine each pattern with practical examples from the banking business, based on almost five years of experience in this domain. By thoroughly understanding the tradeoffs of each approach and understanding the right questions to ask, we can build a mental framework that helps us make well-balanced decisions about which pattern to use. Join me in this session, where we’ll transform the abstract concepts of orchestration and choreography into a tangible decision-making framework that steers you in the right direction!

Debug your thinking

There’s a myriad of complexity involved in building systems. However, two decades in software engineering taught me what truly makes or breaks a system: decisions. It’s not the programming language, the data store, the deployment model, or [insert your favorite tech here]. It’s about the decisions made and the ripple effects they cause. We spend endless hours trying to keep up with the latest and greatest in an industry that sprints faster than a caffeinated cheetah... But how much time was invested in questioning, improving, or, essentially, debugging our thinking process?

How do you structure your decisions, and how do they affect the software you build? When suboptimal decisions occur, do you reflect on the decision-making process itself? I've spent the last few years debugging my decision-making thought process, placing breakpoints to inspect which assumptions got me here and what alternatives I may have missed. As a result, my thought process became much more structured and streamlined, leading to better-balanced decisions. Join me in this session to explore how critical thinking can transform our decision-making process and elevate the quality of the solutions we build for our users.

Keynote session

Messaging: The fine line between awesome and awful (and how to stay on the right side of it)

Distributed systems are becoming increasingly common in today's systems landscape, and messaging is often used to coordinate between components in these systems safely. With benefits like increased reliability, better performance, easy scalability, and easier decoupling of components, you might quickly think, "Shut up and take my money!". However, as with any architectural choice, the other side of the coin surfaces challenges and pitfalls that we must consider: structuring code to fully leverage messaging, dealing with duplicate messages, ordering issues, and diagnosing problems.

To tackle these challenges, we'll explore different messaging communication patterns and when to use them, learn how to effectively decouple code and consider techniques for system consitency. We'll also prepare for any unexpected issues, because, Murphy. By the end of this session, you will have a comprehensive understanding of the messaging problem space and will be better equipped to make informed decisions about whether and how to incorporate messaging into your distributed systems.

How to effectively spy on your systems

OpenTelemetry has quickly become the go-to industry standard for distributed tracing, logging, and metrics. Its widespread adoption across the industry, including the .NET ecosystem, has made it a breeze to use in your applications. But larger, more complex systems introduce challenges that require us to strengthen our understanding of observability, align on our observability goals, and better understand the full capabilities of the OpenTelemetry project.

We need to understand how to choose the right observability signal for each use case, apply a set of best practices to the telemetry we collect, manage costs through different sampling strategies, and select the optimal architecture by leveraging the OpenTelemetry Collector. In this session, you'll learn the right questions to ask and gain a deeper understanding of the available options in the observability space to become more effective in spying on your systems!

Message processing failed! But what's the root cause?

How do you investigate failures in a distributed system? If your first thought is to look at the call stack, then good luck... In a distributed system, there is no such thing as a single call stack! Instead, it is scattered across multiple services that tackle a specific concern and communicate through a continuous stream of messages that flow through the system. That call stack becomes a haystack, so how do you find the proverbial needle?

Luckily, there are techniques and tools to regain the overview we lost. In this session, we'll look at modeling techniques, integration testing, and a deep dive into instrumentation with OpenTelemetry to help create visibility into your entire distributed system. And even if you're not (yet) using messaging in your architecture, you'll walk away with concrete takeaways around system observability that you can use in other architectures as well.

An exception occurred... Please try again.

If there is one certainty in software, it's that things fail. It's not a matter of if but when. All too often, we throw the error at our users, who have no means of solving the problem except for trying again. Alternatively, we build custom code to address edge cases that can't easily be fixed, and we do so with a dangerous lack of insight into the problem at hand.

In this session, we'll discuss the importance of system resilience and how you can equip your software with the ability to recover from failures scenarios. After exploring different types of failures and considering different resilience strategies, we'll dig deeper into the retry pattern by rolling our own. We'll also see existing options such as Polly and NServiceBus, that can handle this complexity for you.

Join me and embrace your system's failures.

Why You Should Consider a Career in Software Engineering

Many misconceptions exist regarding the software engineering profession that perpetuates many myths: Only geniuses can code. We're socially awkward and don't talk much. Code is cryptic, complex, and so dull. We spend entire days sitting at our desks, coding requirements handed to us by other teams. But here's a secret: these myths couldn't be further from the truth!

My name is Laila Bougria, I'm a software engineer with over 15 years of experience in the field. In this session, I will provide insights into what it truly means to be a software engineer, debunking common misconceptions and sharing my experiences. Get ready to challenge your preconceptions and gain a new appreciation for the dynamic and exciting world of software engineering!

30-minute talk presented at universities targeting students that are considering careers in software engineering.

Mirror, mirror on the wall... Am I a critical thinker after all?

How many times have you looked back at a project only to find a mix of technologies, architectural styles, patterns, and practices that somehow just don’t fit together, only to conclude: This is unmaintainable... Let's rewrite the whole thing! As tech professionals, we usually pride ourselves in our ability to think critically because, as part of our work, we continuously tackle complex problems. But are we really critical thinkers? If so, which decisions led to this point? Were they made consciously? What decision framework was used to structure our thoughts and avoid biases?

Over the last years of my career, I have applied practices to decision-making that have significantly improved my decision-making and how I evaluate and challenge decisions made by others. In this session, I'll share the essential building blocks that improve critical thinking, help break through biases, and improve our intent and communication when making impactful decisions. You'll learn to apply tactics to help identify assumptions, evaluate options objectively, and assess risk. You'll walk out of this session with actionable takeaways that will help strengthen your decisions in our complex and ever-changing technology landscape.