We adopted Extreme Programming as methodology

Michel Angelo once said “The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.”

Aside from the fact that code that is ever so slightly more transient than granite, this very much sums up our platform migrationproject. 

Much of the work we done was to remove unnecessary layers of complexity that were introduced by third party software and services.

This by no means invalidates the solutions we have been using which until now have served us well. The major failure of these solutions lies in their success; while they are easy to deploy, these solutions have mostly been developed as a “one size fits all” implementation that caters for many scenarios, and this will always lead to bloat and noise. 

Add this all up over years of development and the result is that while the system does its job well, we are now in a position to do take advantage of what we have learnt and the embrace new technological opportunities on offer. 

Change is of course a natural part of product development:

  • We adopted Extreme Programming as methodology to allow us to quickly add value to our partners and therefore added a lot of tiny new features to our codebase
  • Technology advances at a rapid pace and compromises must be made along the way in order to keep up
  • We only learn about solutions we implement as we go along and often only realise in hindsight that there was a better way
  • as we developed Lighthouse we used the best 3rd party solutions available to us, but as technology provided better solutions it became evident that we needed to change what we had to keep up
  • While we strive for outcomes that make it easy to use and simple to administer, the systems we build to get there is often nuanced and complex. This takes skill and ingenuity and it is an iterative practise based on scientific discovery (hence the term Computer science). This becomes challenging within teams as creative approaches to problem solving are often opinionated and heuristic and due to being human, our internal communication is always a work in progress.

These are the factors that caused technical debt, and if we want to be able to meet the demands of technology then that debt must be paid, and that is what we did since taking on this project. 

Here are some of the implementations we made to simplify our infrastructure:

VPN replaced by Teleport – VPNs are notoriously bloated and unreliable – we did not need everything provided but wanted a solution that was a better fit for what we needed. This replacement results in more reliable connections between our appliances and the central scanner platform https://guardian360.eu/a-better-solution-than-vpn/

Containerised Appliances – this means we can drastically simplify the infrastructure requirements our probes and hacker alert appliances need to run on. That means the appliances need less infrastructure to run on and they can be deployed much faster and more efficiently (Link to Article on Kubernetes when it is available)

Decentralised Probe Deployment – this meant getting rid of an industry leading 3rd party tool used for deployments in favour for a simplified solution we coded ourselves. This resulted in acceleration our deployments from over 48 hours to a few minutes. https://guardian360.eu/simpler-better-faster/

Getting rid of redundancies – this means we got rid of a lot of applications and tooling that was previously necessary to let out platform run. This involved layers and layers of complexity to even get basic tasks going. Reducing the number of required parts to build, provision and run our appliances and platform has resulted in a vastly simpler and easier to maintain stack.

Improved monitoring – this meant replacing our old fashioned monitoring tooling with more modern whitebox monitoring. This monitoring allows us to look more in-depth in to what applications and our platform are doing in a much more zoomed-in manner. Better insights means being more in control of where things can go wrong and how to prevent trouble on the horizon.

Improved scalability – this meant moving away from single instances of containers and applications to a Kubernetes container orchestration solution where we can scale up or down the various containers over many different nodes. This enables us to scale based on load demands for all the various parts of our platform and services.

While this was a massive exercise in dealing with technical debt, the completion of our platform migration will by no means mean that we have now paid all our technical debt. 

As long as we remain human it will always be a reality as we keep on pushing past our limitations. We do hope however that this will be the last big push as we focus on doing smaller iterations more often and deal with technical debt in a more flexible way. 

We believe the work we have done now sets us a good foundation going forward in our endless pursuit to reliability and flexibility and creation solutions that matter to our end users.