Building and running a successful company requires an immense amount of work and talent. It also requires focus. Companies cannot try and solve problems with new and innovative techniques everywhere they operate. It is important to understand the areas your company should innovate in, and outside of that scope, use existing standards and off-the-shelf software as much as possible. There is only so much innovation that a company (or the market) is willing to bear and walking that line is a key factor in developing a successful product on time and budget. ...

In a microservices architecture, an API gateway can help address a number of challenges: providing a stable endpoint for clients to call, allowing an easy process for releasing new endpoints, or handling SSL termination on behalf of services, to name a few. So how do we decide what features of an API gateway to adopt, and which to leave behind? This article highlights the key functions that an API gateway can provide, suggests the scope of problem that API gateways are well-suited to solve, and cautions against the features that make API gateways too ambitious. ...

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. ...

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. ...

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. ...

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. For example, consider ...

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\). The \(\rightarrow\) syntax is used as a shorthand for beta reduction. We can specify beta-reduction explicitly using the notation \((\lambda x.t)s \rightarrow t[x := s]\), which means that the beta reduction of \((\lambda x.t)s)\) is \(t[x := s]\). The beta reduction removes the \(\lambda\) symbol and resolves to the function’s body with the argument \(s\) substituted into the body. ...

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. ...

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). Since both \(f\) and \(g\) take the same argument and produce the same result, we can simplify the equation to just \(f = g\). In lambda calculus, this simplification is called \(\eta\)-reduction. ...

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. An alternative to adding more tests is to add more monitoring and alerting so we know as soon as possible that a system shows signs of degradation. Unfortunately, monitoring and alerting suffers from the same faults as testing — we monitor for behaviour that is predictable in nature or that we have experienced in the past. Together, monitoring and testing try to enumerate all possible permutations of partial and total system failure. Unfortunately, they only provide a simulation of how you expect a system to actually function in production. ...