Reactive Summit 2016

Being reactive in distributed systems is critical, but what does that really look like at scale with Terabytes or Petabytes of data ingestion per day, or what does it mean in applications and deployment architecture? 

There is a need to simplify. How can we build resilient, self healing systems that run at massive scale which don't lose data, support rigorous requirements, in the chaos of big data, partial failures, split brain, and eventual consistency? How would you build awareness and intelligence into your systems if 'everything fails all the time' was a starting point?

This talk looks at the problems differently, with reactive strategies and technologies that collaborate and how they help achieve more stable, self-aware systems. 

 Helena has been building large-scale, reactive, distributed cloud-based systems for many years, distributed big data systems for the last four, choosing Scala, Akka and Kafka for the core of all. She will discuss simplification of big data architecture, data flows, and a collaborative set of supporting technologies.

In this hands on talk and demonstration I'll give a very short introduction to stream processing and then dive into writing code and demonstrating the features in Apache Flink that make truly robust stream processing possible.  We'll focus on correctness and robustness in stream processing.

During this live demo we'll be developing a realtime analytics application and modifying it on the fly based on the topics we're working though.  We'll exercise Flink's unique features, demonstrate fault-recovery, clearly explain and demonstrate why Event Time is such an important concept in robust stateful stream processing and talk about and demonstrate the features you need in a stream processor to do robust stateful stream processing in production.

We'll also use a realtime analytics dashboard to visualize the results we're computing in realtime.  This will allow us to easily see the effects of the code we're developing as we go along.

Some of the topics covered will be:

• Apache Flink
• Stateful Stream Processing
• Event Time vs. Processing Time
• Fault tolerance
• State management in the face of faults
• Savepoints
• Data re-processing

 

Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine.

Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file.

Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics...

Java 8 introduced the Stream API as a modern, functional, and very powerful tool for processing collections of data. One of the main benefits of the Stream API is that it hides the details of iteration over the underlying data set, allowing for parallel processing within a single JVM, using a fork/join framework.
I will talk about a Stream API implementation that enables parallel processing across many machines and many JVMs.
You will learn how you can use the same API to process massive data sets across large clusters, which you already know how to do in a single JVM.
With an explanation of internals of the implementation, I will give an introduction to the general design behind stream processing using DAG (directed acyclic graph) engines and how an actor-based implementation can provide in-memory performance while still leveraging industry-wide known frameworks as Java Streams API.

Groundhog Day, Die Hard, and The Dark Knight aren't just great movies. They're systems that withstand onslaughts of stress and surprise. Can studying great stories help architects and coders of reactive systems think about their work in new ways? What do superpowers tell us about scalability? What does the structure of subplots teach us about resilience? What do genre-busting movies like Rushmore, Fight Club, and Deadpool say about the future of elasticity? There are strange rules for how stories work. Those rules offer clues to building better systems.

The success of Apache Spark is bringing developers to Scala.

For Big Data, the JVM uses memory inefficiently, causing significant GC challenges. Spark's project "Tungsten" is fixing these problems with custom data layouts and code generation.
In this talk, we'll see what we've learned from Spark, ongoing improvements, and what we should do to improve Scala and the JVM for Big Data.

It is a hard to argue that microservices is a new hotness in the world of software. Technical teams in seemingly all new startups are planning to develop their product using microservices, while architects in Fortune 500 are managing tireless conversations about which microservices technology is best to use for their next generation platform. The overhype of microservices is here and with that comes a danger to loose the true meaning of the word, which soon might be labeled as overrated. Before it happens, let's talk about what microservices architecture is, what it can offer, what it gets us into, what its price tag and how to create a checklist for choosing right tools that would help solve the complexity instead of sugarcoating it. 

Apache Kafka is now widely adopted among modern distributed systems. In this presentation we will see how Akka Streams can add even more power to Kafka by exposing it as a reactive stream. We will see some examples of how the Reactive Kafka library can be leveraged to build a well-fitting and elegant match of partitioned, pull-based distributed log and asynchronous, backpressured streaming model.

Netflix customers stream over two billion hours of content each month, accounting for over a third of downstream Internet traffic during peak hours. At this scale, Netflix's systems generate and collect millions of events every second, such as request traces, streaming client activities, and system metrics. It is essential for engineers to process such data streams efficiently and reliably to support real-time monitoring and alerting, outlier detection, application diagnostics, trend prediction, and many other operations.

This talk will discuss Netflix's stream processing system a.k.a. Mantis that supports a reactive programming model, allows auto scaling, and is capable of processing millions of messages per second with configurable message delivery guarantees.

Mantis is a stream processing framework built on reactive principles using RxJava, Netty and ReactiveSocket. It provides users with the capabilities to write scalable stream processing jobs without having to worry about hard problems such as managing continuous data flow in a distributed environment or ensuring fault tolerance.

Kafka is core to Twitter's historical data products, offering access to every tweet since 2006. Learn how we reliably consume and process thousands of messages per second, serving Twitter's realtime and historical data APIs without skipping a beat.

To learn how we use Kafka to serve varying business needs, we'll trace the path of a tweet through our entire architecture, focusing on the reliability of that path. We'll discuss how our architecture has evolved over the years to respond to business needs and technological changes as well as lessons learned keeping this system flowing.

If we were starting greenfield development of a service or web application today we would likely employ a number of practices and design choices that are known to optimise application responsiveness, resiliency, elasticity, and/or composability. Delivering our reactive applications on top of predictable infrastructure will set our project up for success.
Some of us don't have that luxury. We must provision, deploy, and operationally maintain legacy monolithic Rails web applications and HTTP APIs that are hard to refactor without introducing new bugs, poorly performing, and struggle to meet user load/peak demand. Built during a prior era of the company where fast and loose practices were rewarded, startup cowboys delivered the first set of features promptly at the expense of subsequent velocity, long-term maintainability, and high risk deployments. When living in this reality, our infrastructure must be reliable or our application needs constant babysitting, leading to on-call fatigue and high staff turnover.
The good news is there are core principles we can apply to produce more reproducible systems, failstop deployments, and consistent environment configurations to eliminate a large class of bugs inherent in legacy applications and minimize related business risks. This will be the focus of the session and applies to both greenfield and legacy cases.
Code examples given using NixOS and Haskell, but focus remains on the underlying principles.

At Cake Solutions, we build highly distributed and scalable systems using Kafka as our core data pipeline.

Kafka has become the de facto platform for reliable and scalable distribution of high-volumes of data. However, as a developer, it can be challenging to figure out the best architecture and consumption patterns for interacting with Kafka while delivering quality of service such as high availability and delivery guarantees. It can also be difficult to understand the various streaming patterns and messaging topologies available in Kafka.

In this talk, we present the patterns we've successfully employed in production and provide the tools and guidelines for other developers to choose the most appropriate fit for given data processing problem. The key points for the presentation are: patterns for building reactive data pipelines, high availability and message delivery guarantees, clustering of application consumers, topic partition topology, offset commit patterns, performance benchmarks, and custom reactive, asynchronous, non-blocking Kafka driver.

Akka Streams and its amazing handling of stream back-pressure should be no surprise to anyone. But it takes a couple of use cases to really see it in action - especially use cases where the amount of work increases as you process make you really value the back-pressure.

This talk takes a sample web crawler use case where each processing pass expands to a larger and larger workload to process, and discusses how we use the buffering capabilities in Kafka and the back-pressure with asynchronous processing in Akka Streams to handle such bursts.

In addition, we will also provide some constructive “rants” about the architectural components, the maturity, or immaturity you’ll expect, and tidbits and open source goodies like memory-mapped stream buffers that can be helpful in other Akka Streams and/or Kafka use cases.

A code-free presentation about the core principles and philosophies of
Erlang, explaining how the whole is greater than the sum of its parts.

This presentation takes a perspective rooted in showing the reasoning
between each of the building blocks (message-passing, isolated
processes, links and monitors, and so on), and shows how they can be
assembled together to create larger systems where interactions between
subsystems take a front seat in defining the fault tolerance of these
systems.

This session describes our experience adopting a functional programming architecture approach for large-scale, complex enterprise application delivery. We describe a software architecture approach and patterns which provide: 

• More direct correspondence between business logic and code  
• Decoupling of business components from each other and from architecture plumbing  
• Testability  
• Painless support for non-blocking execution, for high-performance 

We address delivery challenges encountered with the adoption of Scala and the Lightbend stack: 

• Technology stack complexity  
• Shortage of skilled Scala architects and developers with enterprise software delivery background  
• Development, testing, and operations are much more challenging with non-blocking code than with traditional blocking code 

In this talk we present Zalando's microservices architecture, introduce Saiki – our next generation data integration and distribution platform on AWS and show how we employ stream processing for near-real time business intelligence.

Zalando is one of the largest online fashion retailers in Europe. In order to secure our future growth and remain competitive in this dynamic market, we are transitioning from a monolithic to a microservices architecture and from a hierarchical to an agile organization.

We first have a look at how business intelligence processes have been working inside Zalando for the last years and present our current approach - Saiki. It is a scalable, cloud-based data integration and distribution infrastructure that makes data from our many microservices readily available for analytical teams.

We no longer live in a world of static data sets, but are instead confronted with an endless stream of events that constantly inform us about relevant happenings from all over the enterprise. The processing of these event streams enables us to do near-real time business intelligence. In this context we have evaluated Apache Flink vs. Apache Spark in order to choose the right stream processing framework. Given our requirements, we decided to use Flink as part of our technology stack, alongside with Kafka and Elasticsearch.

With these technologies we are currently working on two use cases: a near real-time business process monitoring solution and streaming ETL.

Monitoring our business processes enables us to check if technically the Zalando platform works. It also helps us analyze data streams on the fly, e.g. order velocities, delivery velocities and to control service level agreements.

On the other hand, streaming ETL is used to relinquish resources from our relational data warehouse, as it struggles with increasingly high loads. In addition to that, it also reduces the latency and facilitates the platform scalability.

Finally, we have an outlook on our future use cases, e.g. near-real time sales and price monitoring. Another aspect to be addressed is to lower the entry barrier of stream processing for our colleagues coming from a relational database background.

In this talk, we will review an experience of rearchitecting and migrating a system that appeared reactive and microservice-based, but was in fact a monolith with RPC calls to a truly reactive architecture.

The migration work had to be done without causing disruption to the current system, and without taking time to rewrite the system. The result is a biometric computer vision system with a distributed domain in Akka / Scala with storage in Apache Cassandra, with the computer vision components in OpenCV in C++, connected with RabbitMQ and with batch analytics code in Apache Spark.

This talk will show the architectural and code smells that were the result of half-harted reactive implementation and the way to address them, but also the impact of the changes on privacy and security of the stored biometric information.

Since its stable release earlier this year, Akka Streams is quickly becoming the de facto standard integration layer between various Streaming systems and products.

This comes from the Reactive Streams initiative in part, which has been long led by Lightbend and others, allowing multiple streaming libraries to inter-operate between each other in a performant and resilient fashion, providing back-pressure all the way. But perhaps even more so thanks to the various integration drivers that have sprung up in the community and the Akka team—including drivers for Kafka, Cassandra, Streaming HTTP, Websockets and much more.

In this talk we'll explore what and why Reactive integration for streaming matters, how Akka Streams makes it trivial, and what the future holds in this landscape.

There are plenty of reactive technologies out there, but these are only the building blocks for building reactive systems, using these technologies to build a system does not necessarily make the system reactive. A reactive system will have a fundamentally different architecture to the traditional monolith found in the enterprise.

In this presentation we take a hands on look at how the architecture of a system, including the flow of data, the types of communication used, and the way the system is broken down into components, will need to change as you decompose a monolith into a reactive microservice based system.

You have a 24/7/365 environment up and running with dozens of services and dozens on instances for each. Everything is going well. Then, a new feature is required and it requires change to one of your datastores. Since you have a few dozen instances of that service running, you need to perform a rolling upgrade. In this talk, we will discuss some strategies to allow such upgrades to be possible.

“I don’t need stream processing because I don’t have streaming data.” - Anonymous
In general people relate to streams as data models which are naturally streaming (infinite asynchronous messages) or relate to realtime big data processing. In this talk Nitesh Kant, will try to break this myth by emphasizing the fact that streams exists everywhere, be it data read from sockets, protocols like HTTP or microservice composition. He will explain how extending this ubiquitous interaction model into applications can result in simpler, resilient and maintainable systems.
You will learn, how to start thinking “streaming first” through concrete examples and how adopting this mental model makes writing application easier.

In this presentation the ConductR team will demonstrate a number of real-world scenarios that can occur with distributed systems. The demonstrations will be live and include a split brain scenario along with auto scaling based on demand. Things will no doubt go wrong so come and enjoy four guys making fools of themselves!

Akka Streams provides a tremendously flexible architecture to build reactive pipelines that can be imported, exported and otherwise composed as partial DAGs. Its current, default implementation is ActorMaterializer which provides reactive streams across actors within a single JVM. 
Here we show how we implemented a GearpumpMaterializer which distributes reactive streams across a set of remote workers on the Apache Gearpump platform. We discuss how this was implemented and a number of challenges we faced with specific GraphStages and their semantics. Additional we cover how different materializer implementations can interoperate together to materialize different parts of the pipeline. We show that the changes we introduced internally within Akka Streams will enable other implementations of akka stream materializers and suggest a template based on our implementation. We will contribute the Gearpump materializer as open source to https://github.com/akka/akka-stream-contrib or make it available as part of an upcoming Apache Gearpump release.

Netty is one of the best known and most widely used (if not the most widely used) asynchronous network application frameworks for the JVM.
This talk will show you how Netty itself works and explain why some  design choices were made. Beside this it will include war stories about
the many JVM-related challenges the Netty community has faced during Netty development and explain what action were taken to workaround these.