Come and enjoy an early wake up call of great tea, coffee and light breakfast
Martin and Jonas introduce and welcome you to React
by Pat Helland
Gray and Reuter define consistency as: “A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.”
Loosely translated, you should be happy with yourself. In your own opinion, you should be sane.
Through the years, this most ill defined property of the ACID transaction has been conflated with isolation and interpreted through the prism of read/write updates to an apparently centralized record oriented database. This suits systems developers that need a narrow definition to feel they can accomplish something. Unfortunately, it leaves many real world problems in the dust.
In this talk, we will explore the models of consistency and the facades of reality used in practical systems.
Timing is everything. If a system does not respond in a timely manner then: at best, its value is greatly diminished; and at worst, it is effectively unavailable. Reactive systems need to meet predictable response time guarantees regardless of load or datasets size, even in the presence of burst traffic and partial failure conditions.
In this talk we will explore what is means to be responsive and the fundamental design patterns required to meet predictable response time guarantees. Queueing theory, Little’s Law, Amdahl’s Law, Universal Scalability theory – we’ll cover the good bits. Then we’ll explore algorithms that work with these laws to deliver timely responses from our applications no matter what gets thrown at them.
Microseconds in high-frequency trading or milliseconds in web apps, its all the same design principles.
In order to operate 24/7 an application must embrace constant change and failure. This kind of resiliency is achievable through the application of reactive design principles. Learn the theory via real-world examples at Netflix along with some lessons learned the hard way in production. Topics of interest will include service-oriented architectures (microservices), cloud computing, where to put application state, hot deployments, bulk heading, circuit breakers, degrading gracefully, operational tooling and how application architecture affects resilience.
Building highly-available and fault-tolerant distributed systems is hard enough, but making them elastic is even harder. Elastic distributed systems enable operators to reduce costs (by deallocating resources when they are unnecessary) and increase overall throughput (by reallocating resources where they can be used more effectively).
In this talk I’ll introduce elasticity with concrete examples from parallel computing before exploring some of the fundamentals of building elastic distributed systems, specifically addressing software architectural patterns that promote versus deter elasticity. In addition to what it takes to build elastic distributed systems I’ll discuss the compute infrastructure necessary for supporting them, drawing on some of the primitives provided by Apache Mesos for illustration.
Modern CPU architectures are designed as message passing systems with fast and fat on-chip networks. Many of the common abstractions held up as models of great interactions break down horribly in message passing systems when used at scale because they are, in reality, too tightly coupled when communication delay can’t be ignored.
But here is a secret, it’s all about the protocols. What can we learn from protocol design that could make being message-driven easier? What are some of the common pitfalls and best practices to creating resilient protocols? And what does it really mean to be message driven?
by Gil Tene
Studying latency behavior can tell us a lot about a system. It can help us focus our efforts on the parts that matter most for keeping systems reactive and responsive. It can save us time and lead to better systems. But it is an often overlooked part of system modeling, development, testing, and monitoring efforts.
In this talk, Gil Tene will discuss various characteristic behavior patterns of latency behavior, and show what we can learn about systems by simply observing their latency behavior in detail, and in the context that matters to the system at hand. The latency involved in "from stand-still" reaction to a single event is different from the latency involved in processing a message coming off of a hot stream. The latency behavior experienced when waiting in line in a queue is different from the one seen when traversing a constant length operation or physical distance. We'll discuss the implications of these and other characteristics on the way system behave in the real world, and on the information we need to gather when testing systems in order to understand their reaction and responsiveness.
The final session of day 1 will be a Q&A clinic with the speakers. This is your chance to ask the speakers those all important questions, in a relaxed informal setting.
If you have any questions that you would like us to put to the speakers, email us at email@example.com
Chill out, wind down and enjoy some drinks on the house. Followed by some great lightning talks.
Where great food, beer and technical conversations collide...
This is where you get the chance to mingle with the speakers and like-minded technology folks, and to ask all those silly questions you were too embarrassed to ask during the day. Remember that React is a deliberately small, informal conference, allowing you to chat, mingle with the speakers.
Early morning coffee and a light, hangover-curing, breakfast.
by Jonas Bonér
The idea of the present is an illusion. Everything we see, hear and feel is just an echo from the past. But this illusion has influenced us and the way we view the world in so many ways; from Newton’s physics with a linearly progressing timeline accruing absolute knowledge along the way to the von Neumann machine with its total ordering of instructions updating mutable state with full control of the “present”. But unfortunately this is not how the world works. There is no present, all we have is facts derived from the merging of multiple pasts. The truth is closer to Einstein’s physics where everything is relative to one’s perspective.
As developers we need to wake up and break free from the perceived reality of living in a single globally consistent present. The advent of multicore and cloud computing architectures meant that most applications today are distributed systems—multiple cores separated by the memory bus or multiple nodes separated by the network—which puts a harsh end to this illusion. Facts travel at the speed of light (at best), which makes the distinction between past and perceived present even more apparent in a distributed system where latency is higher and where facts (messages) can get lost.
The only way to design truly scalable and performant systems that can construct a sufficiently consistent view of history—and thereby our local “present”—is by treating time as a first class construct in our programming model and to model the present as facts derived from the merging of multiple concurrent pasts.
In this talk we will explore what all this means to the design of our systems, how we need to view and model consistency, consensus, communication, history and behavior, and look at some practical tools and techniques to bring it all together.
by Andy Piper
Data is moving. Data has always been on the move, the fact that when using computers we often need data to stand still in order to do something with it is usually a reflection of our lack of skill rather than of the data itself. So how do we query fast moving data? The normal rules do not apply - or do they?
In this talk I will discuss event stream processing, particularly the challenges in processing high-velocity, high-throughput streams of data and some of the solutions that people have tried. We will also look at some of the theoretical underpinnings of stream processing, the challenges around high availability, transactionality and integration with semi-static data sources. We’ll also touch on the current buzz around “Fast Data”, Big Data’s amped cousin, and what all this means for Hadoop and other batch-oriented systems.
Reactive user interfaces need to scale from handling dozens to sometimes hundreds of updates per second, to changes in data on a daily or weekly basis, as well as handling input from users. This means that literally everything is a stream of data.
We will discuss and demonstrate how the trading applications we've built make reactivity a first-class concept to compose these streams to provide real-time information about the state of the market and the platform. We'll talk about building reactive applications that handle requests that time out, data that gets out of sync, and servers that fail - all elegantly and without refreshing the page.
by Dean Wampler
The Reactive Manifesto's *Resilient* trait says that a system must stay responsive in the face of failure. I'll discuss how various systems approach failure handling. I'll start with the theoretical foundation of *Communicating Sequential Processes* (CSP) and two modern systems inspired by it, the Go language and Clojure's core.async library. Then I'll examine failure handling in modern implementations of the Actor Model, which is dual to CSP (I'll explain what that means), as well as examine failure handling in implementations of Functional Reactive Programming (FRP) and Reactive Extensions (Rx).
by Andrew Stewart
So, you're building responsive and resilient applications, scaling to deal with an ever expanding firehose of events arriving at your front door. You're filling storage by the terabyte without even trying, and that needs to be resilient, and responsive, and scalable too. So obviously you're storing your data using... well... what? Is there really a single technology that meets all your needs for persistence? And are the 'conventional' technologies really a lost cause?
In this talk we'll look at some of the successful - and less successful - strategies for managing high-frequency, high-volume data. We will explore what is technically possible when you need to record millions of messages per second durably without a bottomless budget, review the common storage options and what they are capable of, and also look at what is possible when you're willing to roll up your sleeves and write your own storage engine.
Before the closing keynote there will be another Q&A clinic with the speakers. As with day 1, this is your chance to ask the speakers those all important questions, in a relaxed informal setting.
If you have any questions that you would like us to put to the speakers, email us at firstname.lastname@example.org
by Leslie Lamport
Architects draw detailed plans before construction begins. Software engineers don't. Can this be why buildings seldom collapse and programs often crash?
A blueprint for software is called a specification. TLA+ specifications have been described as exhaustively testable pseudo-code. High-level TLA+ specifications can catch design errors that are now found only by examining the rubble after a system has collapsed.
Using Netflix as a case-study and NetflixOSS components for hands-on practice, learn how to apply reactive principles to application architecture both in the "big" and the "small". Starting at the distributed systems level learn how to handle failure, adapt to changing environments and usage patterns, and iterate quickly in an always-on globally distributed system. Then we'll dive into the code level building blocks of how reactive programming patterns enable fault tolerance and scalability within an application.
Everything is a stream - so learn to think reactively! You need the skills to reason, visualise and communicate about concurrent and asynchronous problems. Join Lee Campbell and Matt Barrett to gain a deeper understanding of the challenges and rewards of asynchronous and concurrent coding.
This course is a practitioner’s guide to Reactive Extensions, teaching you to create elegant solutions through educated design decisions. Through a combination of programming exercises and discussion, you will learn how to think in Rx. This session will cover application development for both client and server, with different programming challenges aimed at thick client, web, and server technologies.
Participants should provide their own laptop, have a working understanding of at least one of the targeted languages and an IDE and test runner that they are familiar with.
Reactive Applications are the next major evolution of the Internet. They allow for applications to be responsive, scalable and resilient by building on a fully event-driven foundation. Typesafe:s Reactive Platform consisting of the Play Framework, the Akka middleware and the Scala programming language embraces this new programming paradigm which allows developers to write interactive applications that are always available and which adapt to changing load by being distributed by design.
In this 2-day tutorial session we will be building a reactive application using Play and Akka. The application will consist of a clustered back-end service and a web front-end querying it using a RESTful API. We will walk through the process of designing such an application and learn how the implementation is structured, including a tour of the tools used for Going Reactive.
Candidates in this 1-day workshop will be introduced to a completely new way of thinking about concurrent programming. By taking a hardware up, rather than theory down, approach you'll learn how modern x86 hardware operates and how when you show sympathy for this hardware your algorithms will absolutely scream. In addition to learning the basic techniques of building high-performance data structures, a performance testing and profiling discipline will be introduced that is fundamental to working at the extremes of systems performance.
Understanding Mechanical Sympathy
Concurrent and High-performance
by Gil Tene
Managing, monitoring, and improving application responsiveness is a common need for many software professionals. Whether you develop Java applications or manage them, understanding application responsiveness and the major mechanisms that affect it is key to achieving successful applications and happy users. In this workshop, Gil Tene (CTO, Azul Systems) will provide an in-depth overview of Latency and Response Time Characterization, including proven methodologies for measuring, reporting, and investigating latencies, and and overview of some common pitfalls encountered (far too often) in the field. While most of this discussion will apply to all application environments, some specific considerations in JVM based environments will be covered as part of this workshop.
Our discussion will include an exploration of of the common needs and motivations for understanding the behavior of application response time and latency, and ways to successfully capture these descriptions and relate them to business needs. However, even good characterization of bad data is useless. If measurements of response time present false or misleading latency information, even the best analysis can lead to wrong operational decisions and poor application experience. Gil will demonstrate and discusses some common pitfalls, false assumptions and problematic measurement techniques that lead to dramatically incorrect reporting results, and will explain how these false measurements naturally occur using the most common measurement methods and tools in use today. We will discuss the coordinated data omission problem, and ways to work around it, and will introduce and demonstrate how simple and recently open sourced tools can be used to improve and gain higher confidence in both latency measurement and reporting.
Garbage Collection, in platforms that use it, is often dominantly responsible for application responsiveness and latency behavior. Gil will review and classify the various garbage collectors and collection techniques available in managed runtimes today. We will define terms and metrics common to all collectors, classify some commonly available collector mechanisms, and discuss the tradeoffs involved in balancing responsiveness requirements against other concerns (like throughput, space, etc.). We will include an interactive discussion of how these tradeoffs play off in the real world.
WHO SHOULD ATTEND
Software developers, architects, technical leaders and anyone with an interest in designing or measuring for latency in software environments.
latency, response time, jitter, stalls, hiccups, coordinated omission, garbage collection
18th–21st November 2014