Class of ’17 DevOps Academy: Where Are They Now? An Interview with Seb & Chrystel

Nearly two years ago we did a piece with two of our first DevOps Academy Graduates, they had just left the academy, and were doing some work with one of our clients for a few weeks to get some experience. If you missed it, you can take a look here. Fast forward to now and they have both spent the past year working with one of AL’s biggest clients, and have moved together to the next big project. During their time here they’ve used all they learnt from the Academy, but also picked up a wealth of knowledge along the way.

This is their take on how their experience has shaped them into the engineers they are now.

What technology would you say you’re most skilled/experienced in now? Is it different from what you thought it would be when you left the academy?

Seb: For our first project, engineers primarily spent their time with a specific tool; I worked mainly with Jenkins, for example, while others would focus on Terraform or Ansible work. While we would dip into different parts of the project depending on the client’s needs and priorities, it was interesting to develop a more in-depth knowledge of a certain toolset while on-site.

Chrystel: In the Academy we learned about cloud infrastructure with AWS, using Cloudformation and AWS native features for everything. Since then, I have only worked with Azure on client site projects, first making heavy use of third-party tools such as Jenkins for CI/CD and Terraform for infrastructure coding, and now, in contrast, I am using Azure native features like Azure DevOps and ARM templates. The tools I have used on site have changed a lot over the last two years but it has all been to achieve similar goals.

Are there any technologies or tools that you’ve found consistently helpful over the last couple of years?

Seb: You need all the basic networking and programming knowledge, but ultimately the core skill is to find the answer to whatever problem is thrown at you in the most efficient manner possible. This can mean seeking out the right person to speak to via slack, being proficient in your google-fu, or simply asking for help from someone who has seen the problem before. That’s more of a skill rather than a particular tool, though – I’d say that a decent knowledge of git is essential. While we were in the academy it quickly proved to be the bane of our lives, as we didn’t have enough experience in collaborating on a project like that with it, or at least I hadn’t. If we hadn’t developed that skill then, the problem would have ballooned to silly proportions once we were on-site with a large team to work with.

Chrystel: Knowing how to properly use a good text editor is a big help day to day. I use Atom but there are loads out there. You can configure extensions and features to do some very useful things like formatting code, syntax highlighting and integration with GIT. Knowing the tricks and shortcuts of your chosen editor can make collaboration easier, speed up your coding and help you spot mistakes much more easily.

Expectation versus reality: What things did you think you would need to be good at tech-wise and how does that compare with the skill set you actually find on site?

Seb: I thought that to solve problems on-site I would need in-depth knowledge of whatever toolset they were using, and while that clearly helps, it isn’t necessary for most tasks I’ve come across. Again, the ability to find the answer to whatever issue you’re facing is key, and you do not need to pore over documentation for hours to do that. Prior experience is still invaluable of course, even in ways you do not expect; I spent much of my time on R&D working on Bash scripts, and I found that little bit of experience helped me pick up the Jenkins DSL work.

Chrystel: Agreed, it’s more important to just pick something up and run with it than be an expert to begin with. Transferable skills and understanding the logic means you can pretty much pick anything up. A big difference for me was going from the academy where we were building things from scratch to client site where things are often already built and you need to work with what you have to build on aspects of it.

‘You learn best practice in the academy, you learn to work with what you have on client site.’

I think when you’re on R&D, for example, you can develop in-depth knowledge of a certain tool but that won’t necessarily come up on the day-to-day job. However, there are patterns that re-occur between different sites and different tools and recognising those is as important as knowing them in-depth syntactically.

You have experience working with AWS and Azure cloud – how do they differ?

Seb:  The first thing that comes to mind is that AWS seemed a little more integrated. The example I’m thinking of is creating a CI/CD pipeline, as I found that AWS had all the components necessary (CodeBuild, CodeCommit, CodeDeploy, etc.) while with Azure we had to rely on VSTS externally. Other than small things like that though, they are more similar than they are different. The skills translate.

Chrystel: I would say the way they name things in Azure is more intuitive, people know exactly what each part means. For example the DNS zone, you know what that does. AWS likes to use interesting names, i.e Route 53 for DNS or EC2’s for Virtual Machines. Also, Azure’s resource groups mean when you go to delete a set of things you can be sure they’re deleted, AWS can leave traces of the build left in other areas so you need to double check.

Do you have an example of when you’ve had to learn a new skill quickly to be able to deliver a client requirement?

Chrystel: The project we’re working on now requires us to use a CICD tool called Octopus Deploy, something many of us had never used before. It’s mainly for building infrastructure, but also to release applications. A different user experience to Jenkins but does a similar job.

We had to pick it up quickly because the client does releases and updates through Octopus multiple times a day, and you need to scope for environment.

Seb: Octopus was something we had never seen or used before, but within the first week we were there we were doing releases. Again you don’t need the depth knowledge, it’s just a case of looking at what exists already and how it’s structured.

What are the benefits you’ve seen of working in an Agile way?

Seb: I think it’s having that general awareness of what the whole team is working on. If you’re working on something and know a member of the team has done it before you can cut down working time by communicating with them. On a previous project, we slowly regressed away from agile ways of working under time constraints and I definitely think it affected our awareness of what we were working on and our output as a team.

Chrystel: I think it’s important to have agile ceremonies like retros and sprint planning to continuously realign yourself with the project goals. That way you know your purpose and what you’re working toward, if you go out of agile ways of working you can lose perspective and lose track, ending up diverted from the real purpose.

What advice would you pass on to STEM grads looking for a career in DevOps?

Seb: You definitely need an awareness of the big cornerstones, the general ethos and the whole point of having DevOps in the first place. It’s very business-focused, so you need to care about the outcomes for the client and not just the code you’re faced with.

Chrystel: DevOps is more about being able to work with a little knowledge of a lot of different tools than being the expert in one specific tool or coding language.  You need to be able to pick up new tools fast, and see the common patterns between them.

For more information on our DevOps academy, view our page here.