Amido code leader: inside Kubernetes and ITIL
This is a guest post for the Computer Weekly Developer Network written by William Ayerst in his role as senior consultant at Amido, a company that specialises in the implementation of ‘cloud-first’ software deployments.
Ayerst reminds us that, for a number of years, Information Technology Infrastructure Library (ITIL) was a golden hammer with which to forge a productive, stable IT environment, but changes in working practices have brought its shortcomings into sharp relief.
Let’s also remind ourselves that ITIL as a concept was introduced as a way to manage an IT environment… but it has grown to encompass managing processes and customers. As an ITSM best practice, ITIL has become a broad wheelhouse, and is typically interpreted by business as vast and monolithic both in the sense of its perceived importance and difficulty in absorption.
ITIL has its own governing bodies, internal references and specific terms and concepts — one that allows a common language to be spoken by business, IT and auditors. Let’s dig inside and get our hands dirty.
Amido’s Ayerst writes as follows…
One of the most obvious disruptors to the lifecycle evangelised by departments who have come to interpret ITIL as a prescriptive solution, is the rapidity of feedback provided by modern deployment methods such as serverless functions, container-based deployments and software suites designed specifically to encourage and facilitate continuous integration, testing, delivery and deployment.
The paradigm of planning biannual version updates does not gel with the speed demanded by clients and customers: truly, with the commoditisation of IT services in the cloud, time to market is one of the only remaining differentiators.
Kubernetes is a primary example, and one I’d like to cover in a little more detail below.
Faith in automation
The topic of Continuous Integration (CI) / Continuous Delivery (CD) was brought up in a recent conversation with a legal services organisation that was operating in a rigidly structured environment. The IT department was being brought to its knees by overly bureaucratic ITIL processes, they were eager to hear input on how to improve.
As an evangelist of Modern IT, one of my first suggestions to any organisation is to embark about the voyage of integration and delivery automation. Their enthusiasm turned to dismay when I brought up the topic of continuous deployment .
“We simply do not have the faith in our technology or processes [to support continuous deployment]”, they said.
The codification of widely spaced releases on disparate systems and a reliance on ‘go to’ people to fix issues as they arose had fully eroded their ability to deliver at velocity.
Glass waterfall
Nassem Taleb’s book “Antifragile” espouses the view that the opposite of Fragility is not Resilience – it is Anti-Fragility: a system which becomes stronger when it is exposed to stress, or when it changes.
The accountant who receives a monthly pay cheque may think his situation is more stable than a taxi-driver whose income varies daily – but the former could be laid off and spend weeks or months finding another job, whereas the taxi-driver doesn’t face the same challenge. This paradigm maps directly to the choices that an organisation makes around continuous integration, delivery, and deployment – and the automated testing and releasing around it.
ITIL does not mandate, but is certainly synonymous with Waterfall development integrated into a hefty Change and Release Management process.
The sense of security around having a model wherein manual intervention is required and gated behind conference calls, email threads and GUI clicks belies a dangerous inertia. Code goes stale, infrastructure drifts and best practices change — and bundling the requisite updates and dependencies into a single deployment process spaced weeks or months apart adds significantly to the risk of a failure.
In the past, mechanisms by which continuous deployment were achieved would be oriented around scripts and third-party tools; triggered Octopus deployments, PowerShell commands to swap Cloud Service slots. Time to deployment from commit would be measured in tens of minutes, or hours – a fashion client routinely operated with deployment operations running fifteen minutes or longer with this pattern.
Immutability, idempotence & iteration
Containerised applications via Kubernetes brings much to the table to expedite this process and introduces integrated functionality to support continuous deployment. Applications can be hosted in local runtime environments on developer machines and executed in a local container or Kubernetes instances to debug in a more closely aligned environment.
The CI/CD pipeline consumes that same Docker and Kubernetes resource configuration in the form of Dockerfiles, Helm Charts and K8S resource files. Those container images become immutable artefacts… and the resource files and charts idempotent definitions.
With automated linting, unit, integration and smoke testing performed in this pipeline and the adoption of a GitFlow style branching model within a version control system (with its own set of criteria on automatically approving merges and PRs) can give near-instantaneous feedback… and potentially remove any human intervention other than to give a green light to deploy to a production environment.
Kubernetes takes this further with built in functionality to handle readiness and liveness checking of code, rolling deployments (which can roll back automatically in the case of failure). Deployment times are in the order of seconds, rather than minutes. External infrastructure dependencies can be handled internal to the application code repository, rather than as a separate provisioning pipeline.
In summary
Tools like Kubernetes prompt us all to evaluate with greater scrutiny, the business value provided by the processes implemented as a result of an ITIL framework, against that returned by adopting modern IT methods.
Beyond all this, as DevOps engineers and proponents, we need to ensure we do not fall into the same trap into which many organisations that implement ITIL as a prescription have fallen. DevOps cannot develop and grow in a vacuum, and we must be ever conscious of to ensure our journey includes and is relevant to the business and auditors.
We need to ensure that we have a language which the business understands, that can demonstrate control and be audited, and which can orchestrate processes without becoming lingua incognito.