Putting the R in D

The economic limits of software development

The Research and Development department would appear to give equal weight to both research and development by virtue of naming, yet there are few engineers who would claim that research is a primary responsibility of their job. Between working on product features, planning sprints, fixing bugs, and attending meetings there is little time left for research. But what is the cost of foregoing research in favour of development? In this article, I consider the economic cost of ignoring research and argue that focusing solely on development is harmful to both product and engineering. [Read More]

Fault-Tolerance and Data Consistency Using Distributed Sagas

While microservices have become the defacto architectural pattern for building modern systems, they come with their own set of challenges. Key among them is ensuring application data consistency when data is spread over multiple databases. This article discusses one solution to this problem, distributed sagas. Distributed sagas provide consistency guarantees for systems spanning multiple databases in the face of failure using a clear and manageable implementation pattern. A saga is highly related to a finite state machines that moves consistently through a set of states, ensuring at each step that some conditions hold. [Read More]

IaaS, PaaS, SaaS and Infrastructure

Infrastructure is undergoing a significant paradigm shift. At my first job as a software developer, scaling our infrastructure meant buying a physical machine and installing it in a rack, setting up the system images and base software by hand, configuring the network using some shell scripts, and finally, making it available for developers to install software. Now, with the advent of cloud computing, the same capabilities — installing and running software — are available on-demand. [Read More]

Alpha Conversion

Alpha conversion (also written \(\alpha\)-conversion) is a way of removing name clashes in expressions. A name clash arises when a \(\beta\)-reduction places an expression with a free variable in the scope of a bound variable with the same name as the free variable. — Greg Michaelson, An Introduction to Functional Programming Through Lambda Calculus When we are performing a \(beta\)-reduction it is possible that the variable name in an inner expression is the same as a variable name in an outer expression. [Read More]

Beta Reduction

Formally, beta reduction (also written \(\beta\)-reduction) is the replacement of a bound variable in a function body with a function argument. The purpose of \(\beta\)-reduction is to compute the result of a function by function application using specific rules. More formally, the beta reduction rule states that a function application of the form \((\lambda x.t)s\) reduces to the term \(t[x := s]\). The term \(t[x := s]\) means that all instances of \(x\) in \(t\) are replaced with \(s\). [Read More]

Building Stateful Services with Kubernetes

The Kubernetes sweet-spot is running stateless microservices that can scale horizontally. By keeping state out of your application, Kubernetes can seamlessly add, remove, or restart pods to keep your service healthy and scalable. Developing a stateless application is, without question, the easiest way to ensure that your app can scale with Kubernetes. However, there are some workloads that do not run effectively in a stateless way, and for that, Kubernetes offers a few tools for developing stateful applications: leader election, StatefulSets and session affinity. [Read More]

Eta Reduction

The purpose of eta reduction (also written \(\eta\)-reduction) is to drop an abstraction over a function to simplify it. This is possible when there is nothing more that a function can do to its argument. For example, imagine that we have a simple function \( f\ x = g\ x \). Both \(g\) and \(f\) take the same argument, \(x\), and the function application function results in the same value (specified by the equality symbol). [Read More]

Testing in Production — Building Observable Distributed Systems

Complex systems exhibit unexpected behavior. — John Gall, The Systems Bible One reaction to the myriad failure cases we encounter with distributed systems is to add more testing. Unfortunately, testing is a best-effort verification of system correctness — we simply cannot predict the failure cases that will happen in production. What’s more, any environment that we use to verify system behaviour is — at best — a pale imitation of our production environment. [Read More]

Normal, Applicative and Lazy Evaluation

A lambda expression is said to be in normal form if it cannot be reduced any further, meaning that the expression no longer contains any function applications. More formally, a reducible expression is called a redex, and a lambda expression is in normal form when it contains no more redexes. Redex A reducible function expression. Normal Form A lambda expression that contains no redexes. Given a lambda expression, there are two primary strategies for reducing it to normal form: normal-order evaluation, or applicative-order evaluation. [Read More]

Representing Pairs and Lists in Lambda Calculus

Having covered types, let’s now turn our attention to lists. Lists are general purpose data structures for storing sequences of items. In lambda calculus, lists are represented using pairs, with the first item of the pair representing the head of the list, and the second item representing the rest of the list. A special value, nil, at as the second item of the pair terminates the list. Pairs Let’s start by focusing on pairs (or tuples). [Read More]