How did you get into DevOps?
Well, I initially started out as a Mechanical engineer, but I’ve been doing it since 1982, though not commercially. Commercially I’ve been in IT since 1987.
It all started when the company I was working for as a mechanical engineer knew I could write software. So, the other engineers would tell me the algorithm and ask me to programme it. This meant I got sent on a CAD course, where I started learning Unix. So, I started working as an engineer after taking the course, the end of summer ‘87. That’s where it all began.
So, after that, I was looking after the companies data processing department, as the 2nd in command. Then as a sysadmin for Linux.
After that, sysadmin led into DevOps, software development and systems administration, creating large-scale infrastructure. The year 2000 was the first exposure to what is now known as modern day DevOps.
What do you consider to be DevOps best practice? Is there such a thing as best practice in an increasingly agile world?
There should always be best practice in an agile world. The reason being, you have to change so rapidly, if there isn’t best practice from the outset you’ll lose control very quickly and chaos will reign.
The most important practice that people still don’t always seem to adopt, but DevOps is adamant should be there, is the communication rule. DevOps is all about feedback to make sure everyone knows what’s happening. It ensures a smooth transition of the project.
As well as communication, there should be a lack of fear.
If you’re too frightened to break something in the first place, you shouldn’t do the job.
The ones that aren’t scared are the ones that will happily break it just to see why it broke and work out how they fix it. They’re the people you want in DevOps.
How was the Academy designed?
It started with discussions with Kris and Norm (our partners and co-founders) and Nick and Matt (two of our senior engineers). We all sat down together and discussed how AL operate and what their engineers were doing. I adapted my plan based on AL’s practices and the customers they were working with.
There are too many technologies to learn in 3 months, so we had to streamline and pick the best of the differences. For example, Ansible and Puppet, Ansible is one method of how we provision systems by doing a push method, Puppet is the same style but does a pull. Though they’re similar in the ground, they have different underlying aspects. We wanted to make sure the grads knew these different methods and how they worked.
The initial programme started with premise style DevOps moving into the cloud. This gave the grads the ability to pick up technology such as shell script, Linux, and core concepts of IT, but hands-on, rather than having to learn just the theory. This year we saw that premise is becoming less of a requirement. So, we modified the programme to adapt it to them starting in the cloud earlier. We did away with on-premise and hardware. There’s already such a big change from last year, it just shows the programme is agile.
We obviously need to give the graduates a broad range of skills and technical abilities, but also they need to apply them to understand how they work. We use assessments and practical sessions to give context as to when and where they should be using these tools. As part of any assessment or exercise, they have to adopt agile processes such as sprint planning meetings. We encourage them to do daily standups every morning to cover what they’ve done, what they think they know, and what they’re still not sure on.
How does the Academy differ from other training?
Running the AL Academy, you have worked with Grads from different academic backgrounds, from mechanical engineering to chemical engineering. What are the core skills that give someone the aptitude to become a DevOps engineer?
Engineering degrees always have an element of problem-solving capabilities. That’s one of the things you want to be able to do. To be able to ask yourself, can I see a problem and be able to come up with one or several potential solutions?
Those with the engineering backgrounds are able to see a problem in a different way and approach it from a different angle. They’re not restricted simply by the technology.
Which tools do you think are the most important when getting started with DevOps?
Any automation server like Jenkins, TeamCity or GoCD – an automation server is always good. Then you’ll need at least one scripting language, so Bash, Python, Ruby, and a bit of PHP. Perl is my favourite but no one really uses it anymore. Linux OS of course, will always be the tool to start with.
For somebody just getting into it and wanting to get ahead of the game, you would want one of the orchestration tools (provisioning systems) such as Ansible, Puppet, Chef etc.
What do you think are the most important non-technical skills to have is?
Being able to communicate. For DevOps that is definitely the most important.
Which methods have you found to be most effective when teaching?
My favourite method is to task the Academy grads to do things themselves. Start by giving them some context first, then a few ‘follow my lead’ demos so they get the idea of how to use it. Then, just drop them in it by giving them example assessments. They can start to investigate themselves and ask me questions as they go.
Nature or Nurture? Basically, does it take a certain type of person to excel at DevOps, or could anyone pick it up?
Anyone can do it, but at what level is a different story. Rather than a natural aptitude, it takes a genuine passion for what you’re going to do. You need to eat, sleep, breath the thing you want to be able to do. But yes, if you have the passion, you can learn. If the inklings not there, it’s not going to happen.
What do you think it takes to be a great DevOps engineer?
Passion, communication, and a really good understanding of how systems work. So, that could be Linux, Windows, network equipment or how systems communicate with each other. That’s the technical side, on the interpersonal side, it’s great communication.
‘’Basically be able to articulate what it is you’re trying to do and achieve, be a good listener, work out what your client is actually trying to tell you, and have good documentation skills, so you can move onto your next project without leaving your customer with issues’’
If you can’t document, you’ll be stuck doing the same job over and over, because no one will ever know what you’re doing.
At AL we pride ourselves on our values and on our mission to ensure automation is a force for positive change. How do you think organisations should be enabling young people to have the skills organisations will need in a digital world?
Try to attract grads early and invest in training. They’re the ones that have new and interesting methods and ideas to solve the problem. One of the things AL does is encourage our people to question the norm.
In DevOps, because it’s fast pace, people want things to happen, and they want to be able to change their mind. You’ve got to keep an open mind in this industry, and if you’re closed minded – DevOps is not for you.
We work with our clients to de-risk and accelerate their business goals realisation. Our approach is based on tailoring our services to fit your needs leveraging our portfolio of strategy, execution, innovation and service delivery offerings to help you reach your objectives
We’re always on the lookout for exceptional talent and people who share our values. Even as we continue to grow, we maintain a family environment with respect and teamwork core to our culture.
Piotr Grześkowiak has been at Automation Logic for just over five years, starting out in our DevOps Academy after graduating in Computer Science with Information Security. During those 5 years, he’s gone from an engineer in training to a well respected senior engineer, trusted by the whole company. Piotr’s been on three Central Government client […]
We interviewed AL’s co-founders Kris & Norm about their journey building Automation Logic into the business it is over the last 12 years. From the values they’ve set in place, to the struggles they’ve faced. And obviously, because it’s pretty difficult not to mention it these days, the impact covid had.
A memoir of a Workload Migration engineer by Liam Rae-McLauchlan We’ve all read the blogs and articles about migrating to the Cloud and its benefits, but in practice it can be a daunting task. Maybe your organisation is planning to move to the cloud, or is already trying – up to 85% of enterprises are […]