Reactive Summit 2022

If you've ever tried to interpret data from an event stream, you've probably had to join multiple events into larger combinations that explain more. So where do you store the parts while assembling the whole? In RAM forces time-windowing that drops results, relational stores need expensive joins, key-value stores are hard for complex patterns, and graph databases are expressive but way too slow. Quine (https://quine.io) is a new open source "streaming graph" which feels like using a graph database but scales to millions of events per second. It works by putting the query execution inline with the event stream. High-volume events stream in, real-time answers to graph queries stream out. Built on top of Akka with an event-sourced persistence model, Quine is a new reactive architectural component for next generation streaming data pipelines.

The next generation of connected, electric, and autonomous vehicles are driving the automotive industry to adopt digital twin technology and reactive architectures at significant speed and scale. This is happening in broad and challenging contexts such as automotive assembly, the software-defined vehicle, active safety and autonomous driving systems, and even motorsports racing and spans embedded, edge, cloud, and enterprise environments. Actor systems and reactive streams now enable device-level diagnostics and prognostics, machine learning, simulation and training, activity-based and crowd-sourced intelligence, and so much more. Doug's talk will discuss the domain-driven design of digital twins in several of these scenarios, investigate some of the reactive streams integrations that inform their behavior and state, and then conclude by providing some perspective on the opportunities, obstacles, and possible outcomes of this exciting journey.

Building out Reactive systems can be a lot of work. There’s a lot of infrastructure to set up and designing a system to be resilient, responsive, and elastic requires experience and time that not every team has. We built Inngest to be an open source, cloud-native system that enables anyone to build Reactive architectures. Designed to be pluggable with your favorite messaging service like Kafka, NATS or PubSub and your favorite container orchestration like Kubernetes, Nomad, or ECS. We’ll walk through how the system was designed, how you can deploy it yourself, and the plans to make it runnable on any cloud (and even your laptop!).

We will be discussing a pattern to integrate a COTS (Commercial Off The Shelf) solution within an enterprise in a reactive way. In many cases it makes sense for a business to acquire a COTS solution to solve a particular business need. However, rarely are these systems implemented in a reactive way, making it challenging to work with when you are trying to make your enterprise more reactive. This pattern identifies a system within an enterprise landscape that the business finds value in and elevates it without rewriting it. The issue we are trying to solve is to make it fit safely within the rest of the enterprise, not strangle it out. We are trying to clarify its place and magnify its value for the enterprise. In other words, we want to bring appropriate focus to the system by defining its purpose, detangling it from the rest of the enterprise, and elevating it to a position where it can provide the value it was acquired for.

All aspects of event-driven design, streaming technology, and real-time systems essentially revolve around how we see data as events, how we model events and essentially the transition and transformations over the data. The pitfalls often come from thinking a domain itself like a legacy. I would present ten such practices which a team can keep in mind to ensure their event streaming work stays successful and impactful

1. Setting Expectations
2. You Are Not Trying To Build Legacy 2.0
3. Be Aware Of Business Gerunds
4. Don't Overinvest In A Single Platform
5. Upskilling With New Development Paradigms
6. Processing Topology Debugging Can Be Extremely Challenging
7. An Inefficient Topology/Data Pipeline Can Have Lasting Consequences
8. Handling Stateful Workloads
9. Frequently Changing Needs Can Pose Challenges
10. Centralized Ownership Can Be An Existential Threat

The above ten practices would be presented while showing actual examples of what happened while developing and what could have been understood and done better, in a lucid way

(Also based on my recently published article https://www.forbes.com/sites/forbestechcouncil/2022/05/19/10-best-practices-for-event-streaming-success/)

For many years Reactive systems were a niche solution that helped a handful of companies that had harder problems than everyone else to solve. For everyone else, Reactive was a solution looking for a problem. Well that problem has now arrived in the mainstream. Serverless platforms may well abstract away the responsibility of developers and administrators to run and maintain servers, but for a system to work in that environment, it has to be architected to handle that. It has to stay responsive when platform automation underneath it is scaling up, scaling down, rebalancing, applying updates, and failing as all systems fail. Serverless is the perfect problem that Reactive architectural patterns were designed to solve. In this talk we'll run through how Lightbend's new Reactive serverless offering, Kalix, makes building reactive systems on a serverless platform simple, by abstracting away state as a platform managed resource, and allowing developers to write Reactive systems that need only focus on the business logic of their application.

Despite their many benefits, distributed reactive systems pose new challenges when it comes to operability. In their presentation "Observing failure in Reactive Systems", Jonathan and Clemens will walk through some examples from a holistic systems perspective. These will include key metrics to visualize, how to identify lack of isolation, cascading failures, data visibility, infrastructure metrics, business metrics, and critical log messages. These lessons are based on supporting live reactive systems processing data in a production environment.

Leading internet players like Amazon, Google, Netflix and others are raising expectations for the user experience of their applications. On the other hand, paying taxes is not inherently a pleasant experience for taxpayers. Therefore, designing a tax information system that is responsive, resilient and scalable is a duty rather than an option. Sergio Maurenzi will present his experience in modernizing a Tax information system through statefull services using technologies and architecture patterns such as Event-driven, Akka Actor Model, Akka Streams, Event Sourcing, CQRS, and others to improve the taxpayer experience.

How do you best introduce the concepts of reactive architectures to your executive team and technical leadership? How do you inspire technical teams to change the way they have been doing things for their entire career? How do you take all these ideas and condense them down in a way that is both consumable and exciting? How can you effectively convert fear, uncertainty, and doubt (FUD) into Fear of Missing Out (FOMO)? In this session we will have a conversation about things that have worked, and things that have not worked when proposing reactive architectures to an audience that isn't familiar with reactive fundamentals. We will explore new ideas to help communicate these big ideas in a way that inspires forward momentum. We will talk about the particular concepts that seem to cause concern when people are learning about reactive architectures and how to overcome these hurdles. We hope you all will join and add your voice to the conversation!