Episode 46

Immutable Infrastructure using FP design patterns Nick Hibberd

Transforming a large stream of data from one form into another. This seems like the ideal task for functional programming, a clear input, transform, output pipeline. However, things get very complex, very quickly. Once that stream of data is hundreds of terabytes a day, requiring co-ordination of hundreds of servers, with hundreds of software configurations, the functions transforming the data are the least of our problems. How can we use functional programming and the tools we are familiar with to get the same properties we value from our data transformation functions when writing code to manage our infrastructure and deployment?

This talk will step through the complexity of building and operating a large scale continuous deployment and co-ordination system; from server administration and change management through to wrangling Amazon Web Services. We will delve into the implementation of our production deployment system, looking specifically at its functional design: including a simple but effective purely functional DSL for describing deployment interactions; the techniques we utilize to ensure auditability and correctness; as well as the overall patterns we use in the end-to-end design of our daemon in order to keep this an easy to understand and maintain piece of software.

How do functional programmers do dependency injection?Mark Hopkins

The FP answer to "how do we do dependency injection" is to turn the question around and instead ask, what operations would you perform if you had these dependencies? Now we can reframe the question as being about defining languages of operations, and interpreters for those languages. To achieve reuse, both languages and interpreters need to be modular, i.e. support a notion of composition. So how do we do this?

We'll compare and contrast two solutions of this problem. The first, popularised in Wouter Swierstra's Functional Pearl "Datatypes à la Carte" (and familiar to some through Rúnar Bjarnason's talk "Compositional application architecture with reasonably priced free monads") builds up a data structure of abstract operations, which are then run by an interpreter.

The second approach takes advantage of Scala's support for higher-kinded types. Rather than building up and tearing down a data structure, we simply add a type class constraint to our program. "Interpretation" is now a compile-time operation: it's just specialization to a type that satisfies the constraints. This is both simpler and more efficient, and sufficient for many purposes.

TBDTBD

TBD