Coding can be meaningful, rewarding, and even exhilarating, but often focusing on what matters is made difficult by all the small tasks that divert your attention from the core work.

This is what DevOps can fix for the developer. By revising workflows, optimizing tools and automating everything that takes away from development, the DevOps expert basically acts as a personal coach, enabling developers to focus on what’s most important. 

Polar Squad ❤ Devs is our new initiative that highlights best practices and sparks up conversation about the benefits DevOps brings to developers.

At Polar Squad, many of our people have transitioned from a role of a software developer to a DevOps expert. As the first part of our PS ❤ Devs initiative, we’d like to share their stories and thoughts about how developers can benefit from DevOps – and vice versa.

Interviewees

Can you give us a bit of background about yourself?

Tatu: I would describe myself as a DevOps Generalist with a Software Engineer background. I Have been working with “IT” for 8+ years. I have studied Computer Science at University of Helsinki to a Bachelor of Science level. Outside of work, I play video games, go to the gym, bicycle and sometimes enjoy hiking.

Mikko: I think I’ve always been a bit of a jack of all trades, master of some; for a long time, I aimed for a career in advertising/graphic design, but creating my own websites as a kid quickly spiraled into frontend development, full-stack stuff, more infrastructure things and now finally into DevOps Consulting. I’ve been professionally doing development & DevOps for seven-ish years, some of those overlapping with my Bachelor of Engineering studies at Metropolia UAS (Media Technology). I’ve been into photography for about 15 years and all my remaining spare time goes into esports, movies and finding new music.

Masi: I entered the world of IT in 2008 as a .NET developer, after two years of studies at Metropolia UAS. I graduated from there as a Bachelor of Engineering, specializing in Digital Media. I had no programming experience prior to 2006, so I practically learned the basics in school. Thanks to an awesome teacher, I really got excited about programming. The first 7 years of my career were mostly about designing and developing ASP.NET web applications and working as team lead. I have a wife and three children. In my free time, I spend time with the kids, do crossfit at the gym, and occasionally some climbing. I also have a professional drone that keeps me busy when I realize the weather is optimal for aerial footage.

How long have you worked as a developer? How long have you worked in DevOps?

Tatu: About the first 3 years of my software-related career I worked as a Software Engineer. After that it has been roughly 5 years of working with DevOps.

Mikko: I initially started off as a frontend developer, but pretty quickly transitioned to a full-stack position. After spending a couple of years doing mainly software development, I started picking up more infrastructure projects and DevOps-y ways of working. Finally, after about five years of development, I decided to focus solely on DevOps and have been doing that for nearly two years now.

Masi: Roughly 10 years. This was mostly about developing ASP.NET based web applications and working with Microsoft stack. I started to shift to automation and cloud infrastructures in 2015, when I changed jobs and the culture at my new employer was much more agile and in line with modern DevOps practices. Even though my role in projects there was sometimes to work as a developer or tech lead, it was more often about automating cloud infrastructures and building CI/CD pipelines. I’ve worked in DevOps for roughly 4 years now.

What made you switch to DevOps?

Tatu: I wouldn’t say that I switched to DevOps at any point. It was more like a natural transition. First, I shifted to do more test automation and projects related to test automation infrastructure. A lot of work related to building and maintaining CI and CD solutions was also part of my duties. After some time, I started doing a lot of Docker-related stuff and then, building infrastructure to the cloud with Cloudformation and Terraform.

Mikko: Like Tatu, it has been more of a smooth transition over time than a switch. For me, the initial spark was improving build tooling and deployment workflows in my own projects, which obviously got me hooked on CI/CD ideas, and after some years, Docker and others came along. I actually did my Bachelor’s thesis on automation of container-based software build pipelines and while doing that at my last workplace, I saw the need and started getting interested in teaching others about more DevOps-y ways of working. So, for me, DevOps has always been about problem-solving – something that comes to me pretty naturally.

Masi: I’ve been gradually switching to DevOps. This has a lot to do with the cultural aspects of my various workplaces. My first employer was a very traditional Software Integrator company with hierarchies and siloes. Developers were not expected to automate deployments, nor were they required to. My second employer was very lean in hierarchy and the culture there really inspired me to start doing things the modern way. That’s where I learned the basics of DevOps, and it made me realize this is what I would like to concentrate on. The value of having full automation for cloud infrastructure and running automated code deployments was becoming a reality. 

What was the most challenging thing you had to learn when transitioning to DevOps?

Tatu: Coming from a software engineering background, I think it must have been gaining an understanding of networking and security in a deeper, low-level context.

Mikko: In addition to lower-level things, like networking, the biggest journey for me has been the “people” aspect of DevOps: Although initially for me “DevOps” was mostly about automation, tooling and everything else technical, it’s clear doing thing the DevOps way requires a lot of people and good communication skills to really make an impact that reaches beyond a single project. Lately, I’ve also taken an interest in the security landscape of infrastructure.

Masi: Switching from Windows GUI to cross platform and OS tools. Developing in the Microsoft ecosystem did not require Git, YAML or command line tools back in the days. It’s a Linux userland today and OS tools are embraced. I’ve had to learn how to work with Docker and containers in general. I hardly use Visual Studio anymore, it’s been replaced by VSCode and different CLIs. New tools also keep popping up in the OS ecosystem all the time. Keeping up with the latest trends requires continuous learning. 

What was the best thing about transitioning to a DevOps expert role?

Tatu: It enables me to do and learn on a broad level. It opens many doors and only closes a few. I think I have always wanted to be a generalist, so working as a DevOps expert fits that well.

Mikko: It really has opened up a lot more opportunities to work on new and more complex things. The role also allows me to move between high-level things, like managing a cloud at the organizational level, and low-level tasks, like automation and infrastructure development. If I’d have to pick one best thing, it’d be that I can really focus on making the developers’ workflows from code to production as fast and reliable as possible. That was the thing that sparked my interest in DevOps, originally.

Masi: It has allowed me to deepen my knowledge and expand my skills to whole new domains. I’m no stranger to container technologies anymore and I’m comfortable with deploying services to Kubernetes, for instance. Finally I can focus on one area and get really good at it.

Is there something from your developer background that you find especially useful as a DevOps expert?

Tatu: I often work with software developers, so it helps to have past experience in that same role.

Mikko: The best way to understand and sympathize with developers’ issues is to have been one. I have faced the same technical and organizational struggles as the people I help today. For example, building platforms is a whole lot easier if you actually understand what developers need from such things. On the other hand, I can’t be sure the situation would be too different if I had a background in “Ops” – my perspective would just be different. Maybe it’s just the developer in me talking, but I feel like the transition from software development to managed services and higher levels of abstraction is easier to approach from the perspective of a user, instead of someone who used to build and maintain those things.

Masi: It has definitely been an advantage to know what it’s like to be in the developer’s shoes. I know the common pain points, especially when developing in the .NET ecosystem. Mastering version control and Git are also a must. I can read and debug code and use the same tools developers use – all this helps troubleshoot issues developers are facing in their daily work. I also maintain my coding skills; it’s a valuable asset to have in your toolbox. Solving problems and also being able to prevent developers’ manual mistakes from happening, that’s it. 

Is there some lesson you’d like DevOps experts to learn from developers?

Tatu: DevOps tools are often used to automate and test software. But the tools themselves  often lack testing and automation. So I would like to see more of a software developer mindset when building CI/CD pipelines or cloud infrastructure with IaC. I would like to see a development environment for CI/CD and tests for Terraform code.

Mikko: I actually feel like a lot of the DevOps tooling is moving, albeit sometimes slowly, towards the good practices the tools themselves enable: multi-level testing, automation, modularity and reproducibility. But that’s still somewhat in its infancy; I think only really advanced teams and organizations do things like E2E testing of infrastructure code, like Terraform. Things like infrastructure-as-code can also benefit from agile (with a lowercase “a”) software development practices, especially when building platforms and re-usable infrastructure.

Masi: I co-sign what my colleagues already pointed out. Introducing the same techniques and standards that comply with writing software should apply to automating infrastructure and deployments, as well. This is actually doable, but the tooling around, say, Terraform is not that good yet. I would like to see how technologies like Pulumi are applied in real life projects. It would be better to take the language that developers are using for writing the actual application code and use it for IaC, too. 

Why did you decide to work for Polar Squad?

Tatu: It was partly due to chance. My old colleague working at Polar Squad contacted me after I had decided to “look for new opportunities”. I knew that this guy wouldn’t work in a “bad company”. In the interview, the atmosphere was  very honest and no false promises were made. Finally, I liked the possibility to work in a company focusing mostly on DevOps consulting.

Mikko: After deciding to find something else to do, I got approached by a recruiter who set up a few interviews for me. One of them was actually for our friends at Wunderdog – a digital products and services company in the same ecosystem as us, right next door to our Helsinki office. At the interview, my spiel about CI/CD, the DevOps way and infrastructure development ended – obviously, looking back at it – with the interviewer suggesting I talk to Polar Squad. In the interviews I had with Polar Squad, I felt such a genuine interest in the things we were talking about, I don’t think not starting was ever an option. Later on, I actually found out that a previous colleague was also working at Polar Squad, so I knew I was in good company.

Masi: My old friend was one of the founders of the company. I just happened to check out what the company was about and asked if he would like to chat about it. I realized this could be a chance for me to focus solely on practicing DevOps in customer projects and learn more from experienced colleagues. After a couple of talks – maybe I should call them casual interviews – I decided to take a leap of faith which I haven’t had to regret.

Do you have any advice for people wishing to learn more about DevOps?

Tatu: For myself, learning by doing has always been the best approach when trying to learn something new. So maybe building a CI/CD pipeline or getting hands dirty with Terraform would be a good place to start.

Mikko: To further emphasize what Tatu said: a lot of the literature, presentations and other material out there describes things on a rather conceptual level or shows über-complex setups with thousands of services. Turning that into a reality requires trying it for yourself and seeing what works for your use case and what doesn’t. This is actually a bit of a pet peeve of mine – I like to see concrete examples, even if they might not be applicable to everyone, and not just leave things “as an exercise for the reader”. If you’re just starting out, setting up a CI pipeline is a logical place to begin and nowadays quite straightforward. For those who are further along, I’d perhaps look more into the conceptual literature for Continuous Deployment. Trying to implement some part of your manually set up infrastructure as code (e.g. with AWS CDK or Terraform) and trying re-creating it from scratch just via code would be valuable. Finally, I’d suggest attempting to create some automated verification for a thing that currently gates your production deployment (anything from E2E tests to canary deployments and automatic rollbacks).

Masi: Start from something small that requires being hands-on. Let’s say you have a simple web application. Try to get it running in one of the major cloud platforms, first by manually configuring it in place. Then, figure out how it could be done using IaC and deployed from your host machine. Finally, implement a CI/CD pipeline, which takes care of provisioning and deploying the app, and marvel at how good it feels to have it automated. As for the process and practices side of things, keep in mind that DevOps covers the whole lifecycle of building and releasing software. The more you understand the big picture the better. It helps to have real-world working experience from different roles of the application lifecycle.

Big thanks to all our interviewees! In this article, we wanted to highlight how the disciplines of software development and DevOps have a lot to gain from close collaboration and dialogue. If the article sparked new ideas or you have questions for us, we’d love to hear them.