BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Events Are Reshaping the Future of Distributed Systems: Jonas Bonér at QCon London

Events Are Reshaping the Future of Distributed Systems: Jonas Bonér at QCon London

Bookmarks

There are many reasons why you should care about events; they drive autonomy, increase stability, help you move faster and allow for "time travel", Jonas Bonér noted in his presentation at QCon London 2018, where he explored how events are reshaping modern systems.

Bonér, inventor of Akka and founder of Lightbend, has been using events for 20 years but noted that there has recently been increasing interest, which he believes depends on four things:

  • Cloud and multicore architectures
  • Microservices and distributed systems
  • Data-centric applications
  • Customer demand — "we want more, and we want it now"

Bonér started by describing the nature of events. They are immutable facts of information. You can only add events or facts, which means that knowledge only can grow. Events can be disregarded, but once accepted they can’t be retracted. Events can, however, be invalidated by later events.

Event-driven services receive and react to facts (events) that they receive. Within a service we can have mutable state, but that must be fully contained and non-observable. Instead, the service reacts by publishing new facts to the outside world.

In an event-driven world everything is eventually consistent, with all events moving asynchronously. There are no transactions or strong consistency, which Bonér believes should be the default. For him, strong consistency should be a rare thing you use when there are no other options. He emphasizes that we must rely on eventual consistency, as this is how the real world works.

As soon as we exit the boundary of a service, we enter a nondeterministic world, which we call distributed systems or the network. In the space between services spectacular things can happen, messages can be dropped or reordered, and so on. However, the network also gives us solutions; we just have to model the uncertainty, and Bonér refers to Pat Helland and his paper Life beyond Distributed Transactions:

In a system which cannot count on distributed transactions, the management of uncertainty must be implemented in the business logic.

Bonér claims that we need to fundamentally change how we think about failures — they are natural and will happen. For him, it is ironic that we in many languages name failures as "exceptions", even though there is nothing exceptional about them, as they are expected. He thinks we should manage failures instead of preventing them, and we can use events to help us with that.

In a sane failure model, failures need to be:

  • Contained to avoid cascading failures, for instance by building fully autonomous services
  • Reified as events
  • Signalled asynchronously
  • Observed, by one or many
  • Managed, but outside of the failed context

He agrees that all this looks hard. Something he thinks can help is events first domain-driven design. He notes though that you should not focus on the structure too early. You should start by focusing on behaviour, on the verbs and events. A way to do that is to work with intents and facts. Intents are mapped commands and represent an intent to do something and facts are our immutable events.

The ability to update data is a main problem for Bonér, because that means you can mutate data, which for him is just wrong. He refers to Jim Gray and his paper The Transaction Concept from 1981:

Updates-in-place strike systems designers as cardinal sin: it violates traditional accounting practices that have been observed for hundreds of years.

Bonér therefore thinks we should learn the basic principles of accounting or bookkeeping and apply them to the systems we build today. The way to do this is through event logging, which is the way many relational databases have worked for years — the transaction log is event logging.

Event sourcing is a pattern on top of event logging that helps us in applying these principles to our systems. Here we store all the events in the order they arrive, which gives us access to the full history of everything that has happened in a system. To create a view of current state, CQRS is one way where you can subscribe to events and create different views according to the needs. A disadvantage of event sourcing is that it’s an unfamiliar model for most software engineers. The versioning of events can also be a challenge.

Bonér concludes by emphasizing that events-first design helps you to:

  • Move faster towards a resilient architecture
  • Design autonomous services
  • Balance certainty and uncertainty
  • Reduce risk when modernizing applications

Event logging allows you to:

  • Avoid CRUD and the use of ORMs
  • Take control of your system’s history
  • Time-travel by going back in time via replaying events
  • Balance strong and eventual consistency

The slides from Bonér’s presentation are available for download. Most presentations at the conference were recorded and will be available on InfoQ over the coming months. The next QCon conference, QCon.ai, will focus on AI and machine learning and is scheduled for April 9 – 11, 2018, in San Francisco. QCon London 2019 is scheduled for March 4 - 8, 2019.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT