Reactive Summit 2016

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.