Event-driven through cloudy skies

With microservices and cloud technologies being all the rage these days, event-driven systems are also getting their fair share of spotlight.

While the reinvigorated interest in these concepts and technologies is great, just using the simplest available library to push events through your chosen messaging infrastructure won't cut it!

In this session, we’ll discuss why there’s more to it than calling a couple of methods, common pitfalls that can get your system into an inconsistent state, be it event-driven or not, as well as some ideas and patterns to address them.

OOPs, I did it again

Object oriented is one of the most broadly used programming paradigms. Problem is, most of the times, even if we use a primarily OO programming language, we're not really taking advantage of it or other useful paradigms and language features, ending up in a mostly procedural scenario.

In this session, I’d like to share some ideas to improve our code, making it easier to understand and maintain, taking better advantage of our languages’ capabilities, mixing paradigms as appropriate.

None of these ideas are new, but it seems we keep forgetting them and get back to the same old mess.

Presentation consisting on some slides and a lot of sample code.
Samples in C# but contents should be applicable across language/tech stack.
Ideal session duration 45-60m, but may be adapted to fit a smaller slot.

Next level console apps with Spectre.Console

Even if they're not our main focus, many of us regularly create console applications in .NET, be it to test some feature, run some benchmarks or automate some tasks.

In all these use cases, we get the job done, but not being the main focus of our day-to-day job, things end up a bit hacky and not as easy to use as they could.

What if I told you we can have our cake and eat it too? Or, in better words, we can create these console applications to help us, but make them more user friendly without too much hassle.

That's exactly where Spectre.Console comes in, an open source library that helps us create beautiful console applications, from parsing command line arguments, prompting the user for information, providing progress reports and much more!

It’s going down, I’m yelling timber!

Applications break, distributed applications even more so. Since failure is inevitable, you have a couple of options: you look the other way, then face the consequences, or you plan and put things in place to help you withstand the chaos?

In this session, we're going to think about all the ways systems can get messed up, from network issues, to server crashes or insistent API clients. We'll then move on to discuss how we can prepare, building systems that auto-heal or, at the very least, don't leave you in the dark when things go sideways.

By the end, you'll probably be a less optimistic person, but at least your applications will work more reliably.

Poking the bear; or how to design for failure, guided by chaos

Distributed applications excel at blowing up spectacularly at 3:00 AM. Since we’re people of action, it’s up to us to build systems that don't keel over.

In this hands-on workshop, we'll apply principles of chaos engineering to stress a sample .NET distributed application running in a containerized environment, examining how it behaves.

We will:
- Analyze system workflows and identify potential failure points
- Make use of observability tooling, like OpenTelemetry and the Grafana LGTM stack, to further inspect system flows
- Experiment and observe how specific faults, like latency or crashes, impact the system
- Evaluate and apply typical patterns to improve the system's resiliency

In summary, we'll poke the bear in a controlled environment, so you have the skills to survive when you meet it in the wild.

This is a workshop session.

Currently designed to require Git, .NET 10 SDK, Docker & Docker Compose.

The target audience is any software engineer or architect that wants to improve knowledge around distributed systems, resiliency and troubleshooting.