You are representatives of the DevOps Business Line at Future Processing. Can you make a brief summary of what your work is like day to day and what you enjoy most about it? 

Adam Brodziak, DevOps Architect: What I like most about my work as a DevOps Architect is that every day brings new and interesting challenges. My scope of work is rather broad – I deal with issues related to software development, delivery, and maintenance. That’s what I missed when I worked with programming only.

In the area of DevOps, I get feedback which I didn’t get in the past. Thanks to this, I know what actually happens in production: how software operates, if it works properly, if there are any bugs. For me, this is crucial information, which helps build good-quality software. 

And that’s what DevOps is about: it combines programming and production. We see how software is created and how it functions. This gives rise to the dynamics that I like so much: there is always something going on. 

Aleksander Owrew, Senior DevOps Engineer: What I like most is that we deal with practically every aspect of the software delivery cycle: with the code, tests, application configuration, implementation, and its monitoring. Each stage presents new challenges, which is how we keep developing. 

Let’s solve the greatest puzzle now. There are countless publications explaining what DevOps is and is not. How do you understand DevOps and what is DevOps like in practice at Future Processing? 

Aleks: To sum up DevOps in one sentence, I’d say that it’s a collection of good practices that increase performance – as long as they get implemented at the stage of software production and maintenance. 

Adam: Precisely. It’s a set of best practices, based on a certain philosophy. In fact, we don’t just create software: we solve our client’s problem and deliver value. This is the source of all the actions that are referred to as DevOps practices. 

Aleks: They are good practices not only in a technical sense, but also from the perspective of organisational culture and cooperation. DevOps is all about continuous improvement, both of the process and in personal terms. 

Aleks, you’re a Senior DevOps Engineer. Can you say a bit more about this role at Future Processing? 

Aleks: As a Senior DevOps Engineer, I receive a lot of trust from Future Processing. I can work freely and in fact, I organise my work my way. I define the details of the infrastructure based on the client’s requirements, I consult possible solutions with my teams, and I share my experience connected with system and process building and maintenance.

I’m working with two teams: I’m the only DevOps in one of them and I cooperate with a colleague from outside Future Processing in the other team. Apart from working with the teams, we’re also active in our internal community. We meet regularly to share experience, talk, and bond.

Aleks Owrew

Senior DevOps Engineer

Adam, you’re a DevOps Architect – that’s an even higher level of expertise. How does your role differ from what Aleks does? 

Adam: My work is largely based on strategic activities and mentoring others, taking care of their development – but I don’t shun coding, either. Like Aleks, I’ve got plenty of freedom. When an engineer has doubts about the direction chosen for a given project, they can always come to me and we’ll analyse the situation together. 

For instance, this happened several times with Aleks: he had a technical or process-related doubt and we discussed the possible solution. Mentoring at Future Processing is not one-way, though. Soon, I’m going to ask Aleks how he did a couple of things in the AWS Cloud Development Kit, because that’s what I need in my work. 

If it’s necessary, I also dig in the code myself or solve problems connected with servers, for example.

All in all, I spend most of my time making sure that people that I take care of know what to do, that they know the best practices, that they follow the right models and avoid traps. However, I sometimes allow them to make a mistake – to let them see why it’s better to avoid this mistake. Obviously, all of that happens in a safe environment! They need this kind of lesson once in a while.

Adam Brodziak

DevOps Architect

Tell us a bit more about mentoring. How does it work at Future Processing? 

Aleks: At Future Processing, we actively share our knowledge. Like I’ve mentioned, we’ve got an entire community to share information and seek help – not only from the old-timers, but also from our intern peers. 

Adam: Within our community, we have the DevOps Business Line, where we focus on the development of our field. At the moment, there are nearly twenty people working in the DevOps line, but we intend to make this team grow. Our main goal is to promote DevOps values throughout the company and, as a result, to improve the quality of the software that we build. 

Your job descriptions suggest that DevOps and SysAdmin are different things, but they often get confused in the names of roles in other companies, for example. How do you think, why is that the case? 

Adam: I think this is because DevOps is quite hyped these days. The same happened to Agile 10 years ago. DevOps is in a similar position now. Everybody says they work in DevOps now – but this isn’t always true. As DevOps is strongly related to the infrastructure, computers, and servers, admins often get renamed as DevOps, although their position and duties don’t change, they don’t receive additional training, and they don’t understand the philosophy that I’ve mentioned before.

Companies frequently say that they are looking for DevOps but then it turns out that in fact, they want to employ system engineers or administrators. We don’t do that as the DevOps line at Future Processing.

If we search for people with experience in IT infrastructure management, with expertise in the field of operations rather than dev, with some knowledge on Linux, the Cloud, and Infrastructure as Code tools, we offer them other roles with opportunities for development and for future change towards the DevOps line. 

Jarosław Wachowicz, Head of DevOps: Speaking about the names of positions, we must say that DevOps is different from other -Ops. There are many: CloudOps, DevSecOps, DevSecMLOps… Like in this meme with a triceratops.

What’s all this thing with the triceratops?

Jarek: All began with a meme showing the development of DevOps. Over the years, many names have arisen: from Ops itself to more extended compounds, which sound a bit like buzzwords. So the joke is that the next stage of development will be TriceratOps. People wonder what those names refer to exactly and how one line differs from another. 

How does that function at Future Processing? How do you differentiate between roles, positions, and business lines? 

Adam: At Future Processing, DevOps is focused on building a platform that supports the development team. In practice, this is about building infrastructure that would allow easy – or, in other words, automated – development and integration of software, to be further delivered to development, test, and production environments. 

DevOps prepares these environments properly: by launching services and systems and configurating them in accordance with IaC. IaC is very important to us, as it allows us to maintain the infrastructure in the same way as the application code, as part of version control. We can also create copies and modifications of environments without the need to do that manually each time. What’s more, IaC serves as documentation for this element of the system. 

All the additional elements of the names – NoOps, DevSecOps – refer to certain methods and approaches connected with DevOps practices. For instance, “Sec” refers to the good practices that ensure the security of the system, whereas NoOps is an approach aimed at software maintenance which is ready for breakdowns and able to handle them automatically, to automate administration. As a result, in this approach there is no Ops work – operational support is hardly necessary. 

We don’t add all these segments to the names of DevOps roles, but we do adopt the approaches related to them. So, there is no obligatory on-call or on-standby support.

The technical aspects that I’m talking about here are really important, but we must remember about the less technical aspects of DevOps as well: about the culture and good practices. We’re responsible for propagating them throughout the company. 

Now that we’re done with terminology and we’ve covered the subject of dinosaurs, let’s get to the core: what technologies are you using in your current projects? 

Aleks: Only the interesting ones. 🙂 In my case, this is usually work with the cloud infrastructure, currently – in AWS and Azure. I start the apps in a managed Kubernetes cluster. Depending on the project, I describe the infrastructure using the CDK or ARM (for Azure), and I keep the pipelines near the repository – in GitLab and Azure Pipelines. It’s worth mentioning that if a given methodology is not imposed by certain requirements, we’ve got room to choose the one we like best: of course, within the limits of common sense and best practices. 🙂 

Adam: We have a love-hate relationship with the CDK. 

What does it mean? Tell us more about the CDK. 

Adam: This is a good tool which makes work easier, especially for the programmers. Thanks to the CDK, a complicated configuration can be described with code: something that the programmers use in their day-to-day work. This is an example of a task which brings our two worlds together: the world of development and the world of operations.

Why did I call it a love-hate relationship? Because this great tool has its darker sides: there are many bugs. I have already reported several of them and fixed one. In spite of that, the tool is effective and makes our work easier. 

What are DevOps projects like at Future Processing? 

Aleks: I think that every project is different, just like the people that work on it are different. Depending on the team’s experience, the role of DevOps may differ. At the moment, I’m working with experienced teams, whose members know the best practices of software development. My work there boils down to purely technical task: building and maintaining the infrastructure. These teams are open to suggestions and ultimately, the choice of the practices to be included in the process is up to them. 

Adam: Our main role in all the projects is to spread the DevOps practices. We’re part of a team to improve knowledge and increase the use of DORA metrics (DORA: DevOps Research & Assessment), which provide tangible benefits of using DevOps. In a way, we’re like consultants. Alongside the developers and specialists who will then take care of system maintenance, we build platforms that help development teams work more effectively. 

The CDK, which has already come up here, is a good example. It turns complex configurations into code. Thanks to that, developers don’t need to learn difficult configurations in AWS because they receive code that they know and understand. 

How did you come up with the idea to focus on DevOps in your professional life? Wouldn’t you rather be Java or .NET developers? 

Aleks: To me, the area of DevOps offers more challenges than programming. I’ve always been into those additional tasks related to software delivery: deployment, maintenance, configuration, etc. I’m a curious person and I want to develop. I prefer to know a bit of every technology than specialise in a single one. 

Adam: It’s more or less the same with me. My adventure with DevOps began in 2009 – back then, I didn’t even know that the thing I was doing had a name.

I remember my conversation with the Head of Technology: it turned out that our views on the importance of DevOps were compatible. We both could see that the best companies in the industry were already implementing it, which meant that our clients would also start doing that soon – and that they would start asking us about DevOps too.

And that’s what happened. Large and stable companies that are our clients at Future Processing know what DevOps is about, they understand this approach and they want to use it. They can see that DevOps translates into better results.

The DORA reports show a statistically proven correlation between the success of an organisation and the use of DevOps best practices. And our clients believe in numbers. 

Is DevOps a development-oriented career path? From your point of view, what are the opportunities for expanding your knowledge and project experience in this area at Future Processing? 

Aleks: The DevOps career path is definitely development-oriented. Every day, we are faced with a number of challenges and we need to acquire new skills to solve them. There are special professional development programmes at Future Processing. You can learn technologies that are becoming more popular and sought after by clients.

I was part of a programme like that when I worked in my previous team. I received a specified amount of time to develop towards DevOps: I got a learning package and the support of other, more experienced DevOps specialists. 

Adam: Self-learning packages are designed so that after completing a course, you can onboard a project as soon as possible and do something useful with the know-how you’ve just obtained. Another opportunity is mentoring, like I’ve mentioned earlier. Every new person that enters the area of DevOps is assigned a mentor – together, they define their future development path. At Future Processing, there is a separate department that deals with learning and development: FPAcademy. Of course, we cooperate with this department as trainers.

Recently, we’ve talked about a course on Kubernetes, because we see that there’s a growing need for learning about it, not only among DevOps but also among developers. This is a grassroot initiative supported by the FPAcademy department. 

Is being a DevOps expert just about technical skills? What traits should a good DevOps engineer have, in your opinion? 

Aleks: Technical skills are a must. You don’t become a DevOps at the junior level. This role is addressed to persons with technical expertise: mostly, they’re developers and QAs who have experience with code. As far as soft skills are concerned, what matters most here is the ability to convey your vision and convince the team to it.

You need your communication skills. As a DevOps, I need to be able to communicate with the client: to get my ideas through and present a given solution as the best option. 

Adam: Soft skills are very concrete skills, in fact. The ability to sell your ideas (the power of persuasion) is really important in this respect. Moreover, you need to be able to communicate your ideas and values and their purpose. Also, you should understand the processes that take place in your organisation: the processes of software development, deployment, and maintenance.

All of that comes with practice. That’s why we seek people with experience – people who have seen a number of bugs and breakdowns and can tell interesting stories about them. 

To wrap this up, tell us what you like most about your work at Future Processing. 

Jarek: It’s definitely the atmosphere. Adam and I worked in many companies previously and we do appreciate the atmosphere at Future Processing. The happiness of the employees being part of the corporate mission is not an empty slogan. 

There is a motto written on a wall in our office: “Great software, because we put people first”. When I first came here, I hoped that at Future Processing – unlike in the case of many other companies – those words wouldn’t just turn out to be a platitude. After 5 years here, I can say for sure that those hopes have been fully met.

Jarek Wachowicz

Head of DevOps Business Line

Adam: I’m immensely impressed with the evolution that has taken place at Future Processing since the moment I joined the team. From a large, disorganised business, Future Processing has turned into and even larger but perfectly organised company, which has preserved its culture and the values lying at its core. 

Jarek: The management board have been determined to make sure that the changes do not interfere with the fundamental values of the company. We run regular research (e.g. the yearly “Happy Team” study) which helps in measuring the employees’ attitudes and analysing carefully how the changes introduced recently influence them. If necessary, we change the direction; if the study confirms that the changes are right, we move on.

And that’s what I find amazing: that the “soft” aspects, such as happiness and unique culture, are measured using special models and nurtured even deeper based on them. This is a combination of heart and mind.  

Deliver high quality software solutions  

Work with us and turn your idea into a great software solution for your company’s needs. 

Explore our potential