Sign up to save your podcasts
Or
Share Designing Event-Driven Systems Concepts and Patterns for Streaming Services with Apache Kafka Ben Stopford Foreword by Sam Newman
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Designing Event-Driven Systems Concepts and Patterns for Streaming Services with Apache Kafka Ben Stopford Foreword by Sam Newman
Designing Event-Driven Systems Concepts and Patterns for Streaming Services with Apache Kafka Ben Stopford Foreword by Sam Newman
https://assets.confluent.io/m/7a91acf41502a75e/original/20180328-EB-Confluent_Designing_Event_Driven_Systems.pdf
While the main focus of this book is the building of event-driven systems of dif‐ ferent sizes, there is a deeper focus on software that spans many teams.
This is the realm of service-oriented architectures: an idea that arose around the start of the century, where a company reconfigures itself around shared services that do commonly useful things.
This idea became quite popular.
Amazon famously banned all intersystem com‐ munications by anything that wasn’t a service interface.
Later, upstart Netflix went all in on microservices, and many other web-based startups followed suit.
Enterprise companies did similar things, but often using messaging systems, which have a subtly different dynamic.
Much was learned during this time, and there was significant progress made, but it wasn’t straightforward.
One lesson learned, which was pretty ubiquitous at the time, was that service- based approaches significantly increased the probability of you getting paged at 3 a.m., when one or more services go down.
In hindsight, this shouldn’t have been surprising.
If you take a set of largely independent applications and turn them into a web of highly connected ones, it doesn’t take too much effort to imagine that one important but flaky service can have far-reaching implications, and in the worst case bring the whole system to a halt.
As Steve Yegge put it in his famous Amazon/Google post, “Organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external devel‐ opers.” What did work well for Amazon, though, was the element of organizational change that came from being wholeheartedly service based.
Service teams think of their software as being a cog in a far larger machine.
As Ian Robinson put it, “Be of the web, not behind the web.” This was a huge shift from the way people built applications previously, where intersystem communication was something teams reluctantly bolted on as an afterthought.
But the services model made
View all episodes
By AGPIAL Phillip J. MurphyDesigning Event-Driven Systems Concepts and Patterns for Streaming Services with Apache Kafka Ben Stopford Foreword by Sam Newman
https://assets.confluent.io/m/7a91acf41502a75e/original/20180328-EB-Confluent_Designing_Event_Driven_Systems.pdf
While the main focus of this book is the building of event-driven systems of dif‐ ferent sizes, there is a deeper focus on software that spans many teams.
This is the realm of service-oriented architectures: an idea that arose around the start of the century, where a company reconfigures itself around shared services that do commonly useful things.
This idea became quite popular.
Amazon famously banned all intersystem com‐ munications by anything that wasn’t a service interface.
Later, upstart Netflix went all in on microservices, and many other web-based startups followed suit.
Enterprise companies did similar things, but often using messaging systems, which have a subtly different dynamic.
Much was learned during this time, and there was significant progress made, but it wasn’t straightforward.
One lesson learned, which was pretty ubiquitous at the time, was that service- based approaches significantly increased the probability of you getting paged at 3 a.m., when one or more services go down.
In hindsight, this shouldn’t have been surprising.
If you take a set of largely independent applications and turn them into a web of highly connected ones, it doesn’t take too much effort to imagine that one important but flaky service can have far-reaching implications, and in the worst case bring the whole system to a halt.
As Steve Yegge put it in his famous Amazon/Google post, “Organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external devel‐ opers.” What did work well for Amazon, though, was the element of organizational change that came from being wholeheartedly service based.
Service teams think of their software as being a cog in a far larger machine.
As Ian Robinson put it, “Be of the web, not behind the web.” This was a huge shift from the way people built applications previously, where intersystem communication was something teams reluctantly bolted on as an afterthought.
But the services model made
More shows like AGPIAL A Good Person Is Always Learning.
View all
Bannon`s War Room
16,894 Listeners