Your current filters are…
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.
18th–21st November 2014