Over the last couple of years we’ve been running a number of projects creating new services, and migrating existing services to a new platform. We’ve been working very heavily with containers as our packaging and deployment mechanism, and using Kubernetes as our orchestrator. During this time we’ve been beefing up our Continuous Integration processes, and looking at how automation can help with deployment.

Historically we’ve had a lot of software that’s been deployed manually, and this has lead to many common issues — it takes time and resource we’d rather be using for other things; it can be error prone and require a lot of trouble shooting; and it often requires detailed knowledge of what’s where and how to safely upgrade. We very quickly realised that with the technologies we were using, this problem could easily grow if we didn’t change our way of working, but that equally these same technologies opened the door and reduced the friction of embracing newer techniques and processes to help us embrace Continuous Delivery. …

Blast Radius

We all want to work with and create resilient systems. When things go wrong, our users tend to notice pretty quickly, and things get… exciting. No one wants that 3AM adrenaline rush from a phone call to say production is down, but almost everyone has been there at some point in their career.

Reliability is often seen as one of the facets of judging the quality of a software system, the ultimate goal to strive for. Interestingly it’s also one of the easiest to measure, track, and report on. Well managed systems should have records of down time, and KPI’s for mean time between failures, mean time to recovery, etc. We’ve used these metrics for many years, in fact I became aware of them first at university, not while studying software systems, but when studying electronics. So these are not new and are well understood and documented. …

All of the patterns and ideas presented in this article are shown in the demo code at https://github.com/TheMagoo73/Apollo-Example.

Resolvers are a key element to creating your GraphQL based services; it’s within the resolvers that you’ll fetch and shape your data, whether directly from databases in simple cases, or more likely from other backend services and API’s in your micro-service based systems. …

Recently I’ve been working a lot with the Google Cloud Platform, which I love. I’ve been building (and destroying!) large amounts of cloud infrastructure working on both fun and serious projects, and I’ve been using Hashicorp’s Terraform to help me do this. I’m a big fan of Terraform, and I’ve written about how I’ve used it before with CircleCI to automate my infrastructure management using GitOps — you can read that piece here.

In this article I’m going to look at a few common tasks that you’re likely to come across, and provide some example code and ideas for my solutions. …

Working effectively with Docker

Once you start working with Docker and creating images for internal and public consumption, deciding how to tag those images becomes incredibly important. Tags are how we, and consumers of our images, identify different versions of a container image. As with most things in software, accurately applying versions is incredibly important.

Below are a list of practices that I’ve been using for tagging images over the last several years, and what I’ve found has worked well for me. …

Develop with Node, GitHub, CircleCI and NPM

If you’re working on a Node module, chances are that you’re going to want to publish it to NPM, so that other developers have easy access to it. Of course, you can manually run your build process and publish directly from your development box, the simplest option. Unfortunately this process is fraught with pitfalls such as the code is your VCS falling out of sync with what’s published, NPM versions differing from VCS releases etc. Plus, it’s all very manual and tedious… and no one enjoys that!

In this article we’ll look at how we can use a CircleCI, a great CI tool, to automate the process from build, to publishing to NPM based on releases tagged in GitHub. …

Fast, modern, static sites

I recently needed to put a couple of websites together for internal projects where I wanted to pull data from a variety of sources, blend it, and then republish it. In the past I probably would have built some form of React app, and then pulled in the data client side using API’s; however in this case some of my data resided in places (and formats) that didn’t suit this pattern, and I wanted to see if there was a better option available.

This lead me to start looking at Gatsby, which it turns out suited what I was looking for perfectly. …

As developers, it highly likely that we’ve had to work on code that we’ve inherited; no comments, no unit tests, and with thousands of lines in each source file. This is the obvious face of technical debt, a term that gets used more and more regularly these days.

But there’s a less obvious side to technical debt, a subtler and more insidious side that means that even green field projects, being created by great teams with high quality ideals, are quietly racking up technical debt.

Both are equally dangerous challenges to our systems, unless we recognize why this is happening, and how we best deal with it. …