The End of the Infrastructure Engineer?

Is the age of the infrastructure engineer over? While I was at VMworld 2011, I listened to a speaker talk about how people like me—people who are conversant in virtualization, networking, storage, servers, and data center hardware—are going to have to evolve/migrate into the application development space in order to survive in the “new cloud world” (my phrase, not the speaker’s). This speaker , either. This started me thinking. Are infrastructure engineers really a relic of the past, like punch cards?

I think we can all agree that the heavily-specialized infrastructure teams of the past—the networking team, the server team, the storage team—are no longer sufficient in the brave new world of converged infrastructure that blends networking, virtualization, and storage all together. I’d agree, in general terms, that IT infrastructure folks need to broaden beyond their core strengths into adjacent technologies in order to remain relevant. Storage engineers need to learn some networking and some virtualization. Virtualization engineers absolutely need to know storage, and networking is becoming a necessity as well. Networking engineers need to embrace virtualization and understand the impact of storage on their networks. Whether or not the silos ever come down fully or whether we’ll just “install sliding partitions,” as one colleague of mine said, isn’t yet clear. It is clear, though, that some blurring of the lines between these teams is a given.

Is it a given, though, that infrastructure engineers have to move up the stack into the application layer(s)? From an awareness perspective—meaning becoming more aware of the applications running on their infrastructure—I’d agree. Application development, though? That one I’m not so sure about. Yes, it will be/is helpful to understand what goes into application development and the infrastructure dependencies that are the result of the development choices. Again, that’s awareness, and yes—infrastructure engineers need enhanced awareness of adjacent technologies and the relationships with their core technology strengths. Awareness, though, is fundamentally different than being well-versed in application development.

Maybe I’m just being naive or ignorant, but regardless of how many layers of abstraction are inserted into the stack—and virtualization, in its simplest form, is another layer of abstraction—someone still has to manage the infrastructure. OK, so you’ve built a “private cloud” and you have highly virtualized infrastructure, pooled resources, self-service provisioning, etc. Someone still has to manage it. Someone still has to ensure that there is sufficient capacity, and that someone needs to understand the core technologies that make the private cloud tick. If we’re all moving “up the stack,” who’s left behind to manage the infrastructure?

This is why I’m not yet convinced that the age of the infrastructure engineer is over. Even if you have virtualized your servers, virtualized your network, and virtualized your storage, management of this infrastructure is still necessary. People who understand this infrastructure—both virtual and physical—are still necessary. Engineers who know the relationships among the virtualization layers and the various technologies are still necessary. Yes, the infrastructure engineer will change, grow, and evolve, but I think that the death of the infrastructure engineer is greatly exaggerated. We can’t all move up the stack into application development; someone has to stay behind and make sure everything runs the way it’s expected to run.

What do you think? Speak up and share your thoughts in the comments.