interaction a first-class entity. Suddenly your users weren’t just customers or
businesspeople; they were other applications, and they really cared that your ser‐
vice was reliable. So applications became platforms, and building platforms is
hard.
LinkedIn felt this pain as it evolved away from its original, monolithic Java appli‐
cation into 800–1,100 services. Complex dependencies led to instability, version‐
ing issues caused painful lockstep releases, and early on, it wasn’t clear that the
new architecture was actually an improvement.
One difference in the way LinkedIn evolved its approach was its use of a messag‐
ing system built in-house: Kafka. Kafka added an asynchronous publish-
subscribe model to the architecture that enabled trillions of messages a day to be
transported around the organization. This was important for a company in
hypergrowth, as it allowed new applications to be plugged in without disturbing
the fragile web of synchronous interactions that drove the frontend.
But this idea of rearchitecting a system around events isn’t new—event-driven
architectures have been around for decades, and technologies like enterprise
messaging are big business, particularly with (unsurprisingly) enterprise compa‐
nies. Most enterprises have been around for a long time, and their systems have
grown organically, over many iterations or through acquisition. Messaging sys‐
tems naturally fit these complex and disconnected worlds for the same reasons
observed at LinkedIn: events decouple, and this means different parts of the
company can operate independently of one another. It also means it’s easier to
plug new systems into the real time stream of events.
A good example is the regulation that hit the finance industry in January 2018,
which states that trading activity has to be reported to a regulator within one
minute of it happening. A minute may seem like a long time in computing terms,
but it takes only one batch-driven system, on the critical path in one business
silo, for that to be unattainable. So the banks that had gone to the effort of instal‐
ling real-time trade eventing, and plumbed it across all their product-aligned
silos, made short work of these regulations. For the majority that hadn’t it was a
significant effort, typically resulting in half-hearted, hacky solutions.
So enterprise companies start out complex and disconnected: many separate,
asynchronous islands—often with users of their own—operating independently
of one another for the most part. Internet companies are different, starting life as
simple, front-facing web applications where users click buttons and expect things
to happen. Most start as monoliths and stay that way for some time (arguably for
longer than they should). But as internet companies grow and their business gets
more complex, they see a similar shift to asynchronicity. New teams and depart‐
ments are introduced and they need to operate independently, freed from the
synchronous bonds that tie the frontend. So ubiquitous desires for online utilit‐
ies, like making a payment or updating a shopping basket, are slowly replaced by
4 | Chapter 1: Introduction
我的内容管理
展开
