Ready Steady Cook

by Software Engineer Graduates, Alistair Steele and Gregg Wighton

Two from our February 2017 Graduates cohort discuss their recent Graduate Project using Chef Technology to solve the problem of setting up a machine (laptop) adhering to company standards. Their aim was to introduce a working example of DevOps and learn more about that sphere. This post talks about the problem they sought to address using Chef, what DevOps is and the experience they have gained from their Graduate Project.

The Problem

During a new starter’s induction day, a considerable amount of time and effort is spent on setting up a Development machine (laptop). Tasks involve downloading software and creating a folder structure which adheres to the guidelines set out by the company. This manual process is time consuming and tedious, plus it allows room for human error. The same issue occurs for a current employee who has to rebuild their machine. A third issue can be seen with employees who have forgotten the company guidelines.

Company time, in particular for new inductions, would be better spent in various other ways. Allowing the new employees to read company policy or familiarise themselves with the office building and appropriate contacts.

A key aspect of this project was to eliminate user interaction and cut down on the potential human error. To achieve this, three technologies were considered, Ansible, Puppet and Chef. We chose Chef as it is serverless, scalable and Windows compatible.

With the technology selected we looked at how best to use Chef and what it’s capabilities were. This required a lot of research – and trial and error. Understanding the problem enabled us to create three main goals: Silent Installs of required software, Folder Structure and Environment Variables, all of which were to be automated.

Our objective was for the user to simply download Chef Client, connect to the repository on InnerSource and then run a single command on the command line. The Automated process will then kick off and deliver the finished product. So what will it achieve?

  • Ensures standardisation throughout the company
  • Saves the company valuable time
  • Speeds up Induction process
  • Silent installs of software, folder structures and environment variables

Using DevOps to tackle the ‘Wall of Confusion’

In the traditional flow of software delivery, the interaction between development and support is often one of friction. Development teams are wired towards implementing change and the latest features. Support teams focus on stability of production environments through carefully constructed control measures. This divide in culture is now commonly referred to as the “wall of confusion”.

DevOps looks to break down this culture by improving the performance of the overall system, so that supporting the application is considered when it is designed. One method of doing this is to start treating your infrastructure as code so that it can be rebuilt and validated just like application code.

One area that would benefit from provisioning infrastructure would be the configuration of development environments. Setting these up can often be tedious as they rely on specific versions of software, installed in an exact order with particular environment variables and other project specific configurations – all of which can cause delays to working on a project and are prone to human error.

Automation, Automation, Automation

Chef is a powerful automation platform that uses custom Ruby DSL to provision infrastructure. A key feature of Chef is that it ensures Idempotency – only the changes that need to be applied are carried out, irrespective of the number of times it is ran. While it is intended to configure servers, the flexibility of the platform means that it can be used to set up local development environments.

Diagram described in the text belowOur diagram shows the architecture and workflow for the project. A developer writes Chef code on their workstation, then uploads their code to a Chef repository hosted on GitLab, and installers kept in an S3 bucket on AWS. This code can be pulled down to a developer’s machine to be configured and run in Chef Zero. This is a feature (usually used in testing code) where both a Chef Server and Chef Client are run at the same time. This approach ensures that development machines can be quickly and reliably configured for a project. This also introduces portability into development environments so that testing and support teams can recreate these environments should they need to.

Ready for the Cloud

Chef is tightly integrated with Amazon Web Services through AWS OpsWorks. This means that the Chef code used to automate physical servers or workstations can be used to configure AWS resources. This ability to standardize both physical and cloud environments means that it is possible to create a smooth workflow for both Development and Support teams.

Our Grad Project take-aways?

From experiencing work in a support team, we can see the benefits of embracing a DevOps culture and workflow. The ability to standardize environments means that Development teams are free to implement new technologies that can then be easily transferred and controlled by support teams. Having completed Phase I of ‘Ready Steady Cook’, we aim to embark on Phase II- developing an automated setup for a specific aspect in the support team.

We have both gained valuable experience in working through a project’s complete lifecycle, from inception to development to testing and production. Throughout the project we utilised Agile methodologies such as working towards fortnightly sprints and daily stand-up meetings. This project has also widened the scope of our graduate training in that we have gained certifications in Chef and are working towards certifications in other DevOps technologies.

Sopra Steria is currently recruiting for the Spring 2018 Consulting and Management Graduate Programme. If you, or someone you know, is interested in a career with us, take a look here.

What IT service management can learn from CrossFit

Six months ago, when my children told me I was “great to bounce on”, I decided to sign up at the local CrossFit gym. I’d heard from friends that it was a good way to get in shape fast. CrossFit has a reputation for being somewhat tribal, with participants enthusiastically cheering, back-slapping and wearing garishly coloured clothes, so it was with some trepidation that I signed up for the induction to my local ‘box’ and set myself on a course to…

Forge. Elite. Fitness.

Two days later, it hit me hard. I couldn’t bend down far enough to put my socks on. Even brushing my teeth hurt! My head was full of acronyms such as WOD, AMRAP and EMOM and strange expressions such as “I totally RX’d Linda today, but I know I can lift more on the clean.” In short, I was a confused and broken mess. But something inside me clicked. I liked it and strangely, I embraced the pain. I was hooked.

I gave myself a week to recover and then bit the bullet and stepped back into the fray, partly because of what it could help me achieve over the longer term. I knew results wouldn’t come quickly, but with perseverance I was sure I could reach my objectives.

As weeks have turned to months, I’m still going, getting fitter, faster and starting to become a little less bouncy around the midriff. It still hurts, but I push past this and keep going because the will to succeed outweighs my desire to be a children’s trampoline.

For me, IT Service Management sometimes feels the same.

Bonding through adversity

It can get pretty intense in the box. Everybody is competing against themselves and the pain is very real even though the barriers to success are often more psychological than physical. A strong spirit of gym camaraderie is essential in getting the best out of everyone. Encouragement and praise is plentiful and audible; this helps maintain commitment and energy levels even when the going gets really tough.

It’s the same in an operations team that works in a fast paced, high pressure environment; a strong team spirit is essential in maintaining throughput of work and ensuring the team does not burn out. Give support to your colleagues, whether it’s a pat on the back, a well-timed joke or a few beers, it can make the difference between a team coping and falling apart. Get to know one another, trust each other, and enjoy working together.

Speaking a foreign language

“What on earth is an AMRAP?! You jerked what?! Your favourite Girl is Nicole?!” Such are the musings of a CrossFit newbie, as the acronyms and bizarre phraseology make CrossFit initially impenetrable.

IT Service Management (ITSM) can be just as bad. To the non-initiated, the fact that an issue is not the same as an incident which is not the same as a problem can be something of a conundrum. ITSM has an abundance of acronyms, abbreviations, and terminology that means nothing to your average developer, let alone the Chief Finance Officer (when you are trying to explain why you need £10K for that critical but under-performing SAN array).

I don’t think that’s a bad thing. Sometimes it helps to feel you belong to a private club that shares the same goal and interest. Having a common language helps us talk in a consistent and professional manner.

Scaling enables continuous output

At its most basic, scaling is the use of tools or alternative techniques to make CrossFit exercises easier and is particularly useful when you are starting out. Many routines (such as pull-ups) are beyond the reach of most mortals, so anything that makes the job a little bit easier is a godsend. It’s not cheating; it simply allows you to progress at your own pace and, most importantly, maintain it.

Going lighter isn’t the enemy to CrossFit. Stopping mid-workout is.

This is equally true of ITSM, where the ability to consistently deliver and maintain throughput is key to successful operations. Overburden a vital function and you might as well rip up that forward schedule of change.

We need to scale our operations. The use of tools to automate processes can pay massive dividends through the release of resource. If a process is slowing you down, make it more efficient. This doesn’t have to involve full blown Lean-ITSM. The removal of just one redundant step could mean the difference between getting that change deployed on time and missing the deadline. Consistent throughput of work though the removal of constraints is the key here.

Again, but faster

CrossFit is about getting stronger, faster, leaner and tougher. Athletes achieve this by performing an activity, analysing their performance, and then seeking to improve on this the next time round. CrossFit continuously encourages you to try to go that little bit harder, push that little bit more and find that last little pocket of energy you didn’t even realise you had.

ITSM should be like this. We face criticism for being overly bureaucratic, cumbersome, expensive or ineffective. These criticisms are not without merit and, like my ever-expanding waistline before CrossFit, are often the result of apathy and a reluctance to look introspectively for the source of the problem.

Continuous improvement processes should strive to first understand the baseline. Once this has been established, they must analyse the system to find out what can be added, removed, refined or improved to accelerate the flow of work. Then rinse and repeat. The team should always be challenging itself to go faster and improve performance but not at the expense of the overall machine. The value chain is only as efficient as its weakest link, so focus on the least efficient components first and make sure that when you cut out the fat, you are not losing some of the muscle with it.

“Having arms like Arnie won’t help you run any faster!”

Shout it out

“There’s only one rule of CrossFit and that’s that you never, ever, stop talking about CrossFit!”

CrossFit people can get a little obsessed and it does have a tendency to border on the intolerable for non-CrossFitters.

In my career I’ve come across a lot of ITIL* evangelists; hardcore supporters of the cause, unwilling to accept that there may be other ways of working or that, just perhaps, full blown change control isn’t required to reboot that printer in the lobby. But ITIL and ITSM is something to get passionate about. When I first found ITIL it was nothing short of a revelation. Here was an approach that allowed IT organisations to shine, add value and actively demonstrate, with meaningful metrics, how and why they were doing a good job and making a difference.

ITIL has come a long way since then, and now has global support in industry, but we shouldn’t be devout followers, deaf to all criticism. ITSM practices need to adapt if they are to keep pace with cloud, digital, and similar emerging technologies.

We have built ITIL and helped to promote the ITSM movement that has radically transformed the way that businesses have operated IT and it’s just as relevant now as it ever was, if we keep it fresh.

That is some achievement and, just like CrossFit, I think that is worth shouting about.

What do you think? Leave a reply below, or contact me by email.

(* ITIL – formerly known as the Information Technology Infrastructure Library)