Reskilling for the future: Why developers and infrastructure pros need to escape their comfort zones

Matthew Finio: How is the relationship between developers and infrastructure professionals changing?

Miha Kralj: The whole development profession changed with the dawn of “software-defined everything”—software-defined networking, software-defined storage, software-defined computing.

In the past, we had the infrastructure people on the left and software development people on the right and they barely talked to each other. One was serving all the underlying plumbing and assets, and the other was doing all the coding and making dreams come true.

Now, all of that is collapsing. Neither side is prepared for the era we now live in. And neither understands security, so we can bring that into this as well. They need to start learning from each other, and it’s hard for both sides.

It’s like the Who Moved My Cheese book—neither side feels very comfortable if they are coming from the old traditional world. Younger generations that grew up with Gmail and YouTube, they live in that new, combined world. But people who came from the traditional infrastructure side or development side struggle because they didn't learn the other side in the early years of their career.

MF: So, both developers and infrastructure people should rethink their job descriptions?

MK: Exactly. Developers should no longer think that they are just application developers. Infrastructure people should no longer think that they are just operations people. The modern teaming constructs of product engineering environments apply here, where everyone can do somebody else's job if needed. There are still specializations, but a developer, when needed, needs to be able to jump in and write some Terraform script, which would traditionally be a very infrastructure-focused task.

So, when you ask somebody what their job is, they shouldn't say “I am a software developer” or “I'm an infrastructure/operational person.” All of them build a product or help create a service and it will never launch without all those bits and pieces put together correctly. Everybody needs to understand the full chain, the full lifecycle, everything from bottom to top.

MF: You mentioned Terraform. What are some other infrastructure concepts that developers need to learn?

MK: Developers frequently don't understand exactly how underlying infrastructure really works and what can be durable, what can be ephemeral.

If you, for example, make some change on the host or container or serverless component that is running something, is that change going to persist when that component, that virtual machine jumps somewhere else? So, the concept of systems that are storing their states elsewhere, stateless systems, is one of the precursors that developers can start to understand. How do you make it infinitely scalable? How do you make very durable and elastic systems? All those architectural concepts are implemented in software, but they're actually based on infrastructure patterns.

Also, it's worth understanding all the security patterns of how to create the minimum surface area in code that has the least possibility of attack. And how to properly communicate with some far service. Are you going to write a little chatty service that is sending a hundred little chatty questions over the wire every second? Or do you want to package all the requests and send them over in bigger chunks less frequently?

These are super important decisions that every software developer needs to make, but they will not understand why they are making them if they don't understand what’s happening under the hood—how actual systems work. That understanding of the system from bottom to top is crucial. The developer needs to write good, clean code that is not choking the system, that is not locking the database, that is not doing bad things.

If you go 20 or 30 years back, we had a dedicated profession that was optimizing database queries for the minimum number of cycles required by CPU, the minimum amount of locking of the data. Lots of that arcane knowledge is lost. But it’s still super important to understand how to create a high-performance system and how to create a cost optimized system. All those lessons shouldn’t be forgotten.

You're thinking, “Oh, hey, this is 2025, old man, sit down! The modern world is totally different. You have no clue!” Well, we built this modern world, and we’re here to help the new developers and new infrastructure people use it as efficiently as possible.

MF: Can you describe some ways developers can use infrastructure as code tools to improve their workflow?

MK: Yes. A good example would be how a developer can create a proper workflow for their own code to be automatically tested and then compiled and packaged whenever they create piece of code and commit it to a repository. Developers should not need some infrastructure person to do that for them. Making a nice YAML script on GitHub is an infrastructure as code task that every developer can optimize to make that process as efficient as possible.

So, for example, a developer does not need to have full packaging and full validation and full testing if they are sitting only on the development branch. That developer will say, “Hey, I’m on the development branch, I can ignore all of those 20 tasks that are meant only for the production branch.”

But if you are in production, you need to do a whole bunch of automation, spin up the machine that is going to do the full security vetting and validation of the code and so on. All those little decisions that are going to impact how quickly you get compiling done and how quickly you see the results after you committed the code—every developer should be able to change infrastructure as code scripts and fit it to their own workflow.

It's like how those same developers like to fine tune their own integrated development environment. They prefer their own fonts and colors and keyboard shortcuts and all of that. They should also be able to configure their own workflows—what happens after you commit to the code. That is all knowledge coming out from IaC, infrastructure as code.

MF: What specific things should infrastructure professionals understand about app development today?

MK: Infrastructure as code—IaC—literally means that infrastructure people are becoming coders. Infrastructure is defined with scripts, with data, with code, which means that infrastructure script or code needs to go through the same software development lifecycle as any code that developers write:

• It needs to be properly documented.
• It needs to be properly stored into a repository.
• It needs to be properly versioned.

It needs to be treated the exact same way. Traditional infrastructure people weren’t understanding this or able to do it. Infrastructure people can configure things, clickety click through a mouse, and maybe they can write some Bash scripts or something.

But now it is completely expected that infrastructure people are actual coders for infrastructure. They need to understand Git. They need to understand how to do the security scanning of their infrastructure as code assets. Their assets need to become properly versioned and they're going to be peer reviewed, and they need to understand what the pull request is. These are all standard terms and activities that every software developer knows by default.

Infrastructure people need to become full stack. And full stack engineers are hard to build and hard to find. There’s a shortage of people who understand everything from the bottom—how the packets are flowing and how the network works and how the kernel in the operating system works—all the way to the top. For example, how do I actually write multiple software dependencies? Use packages that are either open source or internal? How do I write asynchronous code? All questions of pure software development. Two huge domains collapsed into one. The change management and the reskilling and upskilling for talent isn’t there.

MF: If reskilling and upskilling is such a challenge, then how should infrastructure professionals stay up to date with development trends and technologies?

MK: Well, there are no more infrastructure-specific people and developer-specific people, all of that collapsed together into a single domain. They're all learning those new trends—changes in the software development lifecycle and especially now changes with AI.

As we go into an AI-native type of development, both infrastructure people and application developers need to learn it. Everybody suffers from the FOMO effect and thinking that they’re already behind. They just learned how to do prompt engineering and now they're being told they need to learn how to write agents on Semantic Kernel or whatnot.

People need to help each other out, they need to find the right balance. How much time needs to be spent staying up-to-date and knowing that you still have the leading edge? It used to be 5%, now it’s 10%. Generative AI helps. But this ratio between how much time you need to learn versus how much time you apply that and make something that is providing business value or IT value is skewing more and more towards learning.

MF: And before we wrap up, what are some key things developers and infrastructure professionals should keep in mind about modern applications?

MK: There are no split tasks anymore. Modern applications have infrastructure almost built in. For example, a modern developer is going to write a code and request to make a container. There is no infrastructure person making a container for them. Some jobs require more infrastructure focused work, but also development. And some jobs require more software development, but also infrastructure knowledge and access.

So, what infrastructure professionals need to consider is to become software developers. And the same for software developers, they need to become infrastructure professionals.

Those roles are not separate, they’re merging. It’s like a decade or more ago, when every professional software development shop had developers and testers. Nobody talks about testers anymore because those two roles merged. That same type of collapsing and merging of roles—this time between developers and infrastructure people—is happening now.