DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.’ Ken Mugrage


It’s worth taking Spinakker for a spin

Elsevier’s Alex Leonhardt gave us a whistle-stop tour of Spinakker or ‘The Gooflix Stack’ – an open-source, multi-cloud continuous delivery platform from Netflix. One event attendee observed that ‘everyone is talking about Spinakker, but no-one seems to be using it’ – so helpfully, Alex was on hand to talk through a hack-day’s-worth of experience running Spinnaker on a local Kubernetes ‘cluster’.

Although Alex experienced a few teething problems with the CORS not working as expected, Spinakker prevailed in the end, with Alex conceding that these may have been a case of ‘RTFM’ (Read the Flipping Manual). The conclusion was that Spinakker’s strengths may lie more as a deployment tool than an automation tool.

‘Netflix: It’s the future, and we’re not ready for it.’

Spinakker is just one of 106 open-source repositories, ranging from big data to service discovery. It is produced by Netflix, but most developers seem reticent to dive in. So, when the vanguard of open source itself is putting out this much material, why isn’t the community scrambling over it? London DevOps threw the discussion open to the floor.

Out of our league

There are several explanations for this phenomenon; the most common being, given the scale at which Netflix is operating, they simply have problems which no-one else has – it’s a case of the product evolving faster than the user can accommodate it.

The user isn’t engaged…so the user isn’t engaged with

Furthermore, because there isn’t a two-way relationship between user and software, Netflix simply don’t have the community engagement to fix issues, which can lead to problems from a utilisation perspective – the documentation on certain programmes, for example is poor.

Managing the managers

Another obstacle is convincing management to deploy new systems; open-source tools may be free from a monetary perspective, but their cost lies in the time it takes to implement them. It is also difficult to get sign off on a project which is orientated around safeguarding against an eventuality, rather than promoting a new feature. One method for the bold of heart is to simply tell your manager ‘I will solve this problem for you,’ rather than ‘I’m using a new tool’ – but obviously this approach is hardly without complications.

Lagging due to legacy

Ultimately, the DevOps community’s reticence might truly be a case of ‘it’s not you, it’s us.’ Even when there is a compelling case for adoption, often it would require an overhaul of the infrastructure stack – and many simply aren’t willing to commit to dealing with the backlog from a time – or cost – perspective.

Server Access Management made easy(-er)

Pusher’s Phil Tabrogge talked us through what to do when things go really wrong and you just need a shell – usually in a hurry. The problem of managing SSH access to servers has never gone away, and in fact, the less often it is needed the more reliable the tooling needs to be. As servers are no longer precious flowers, when managing SSH Public Keys, organisations often need to choose between shared keys, creating problems if the key needs to be changed, and relying on a puppet to keep keys updated by Configuration Management (a semi-manual process.).

Phil talked through his organisation’s solution to this problem: Hashicorp’s Vault. Vault is a tool for securely accessing secrets such as API keys, passwords, or certificates. The software provides a unified interface to any secret, while providing tight access control and recording a detailed audit log. This isn’t a new idea – it operates in a similar fashion to Kerberos. It’s a very user-friendly alternative, and, as a wise man once said, there are no new ideas – just new programming languages to write them with.