Why Infrastructure Engineers Should Start Thinking Like Software Developers

Several years ago I started my career as a C++ programmer, but being relevant as a software engineer today would require many more software engineering skills. The same logic holds for infrastructure engineers.

The status of cloud adoption today

About 94 percent of enterprises and 50 percent of governments use some form of cloud (private/public) today. And as per an estimate from Forbes, 83 percent of workloads will be in the cloud by the end of this year. These stats imply that infrastructure teams should be ready to:

• meet expectations of faster release cycles, with several releases per day becoming the norm; and
• provide application access at scale (millions of concurrent sessions, potentially across the globe) with 24x7 availability.

However, only 30 percent of all infrastructure teams are using DevOps. For financial services firms, this number is even lower, at 12 percent. Since there is never a one-size fits all approach to infrastructure and operations, the picture below illustrates a way to think about this issue.

Broadly, we can group all applications in an enterprise to be either business enabling (e.g. security, email, communications, ERP systems) or business critical (transaction processing, online channels, websites).

Infrastructure teams that support business-enabling applications and use scripting (cli, perl) solely should consider adopting a more programmatic approach (e.g. Python). This can help in two ways: a) minimize the proliferation of one-off/ad-hoc scripts and b) make the team less reactive to change requests and incidents, as a programmatic approach will build in greater flexibility.

Development skills you should be considering

Infrastructure teams that support business critical applications should consider a more transformative approach through DevOps and Infrastructure as Code methods to closely align with the needs of their development counterparts. To do so will require, at a minimum, a good understanding of some basic principles of good software development.

• Implement source code versioning using a code repository like GitHub, where everyone can contribute and merge changes into a single version.
• Design for testability by building in tests for recovery and resiliency at the very beginning instead of being an after thought.
• Create modular design principles by writing code that facilitates easy peer reviews and also allows for testing at different levels (unit, system and regression). Setting up a staging (lab) environment for rapid testing is a necessity.
• Documenting code clearly minimizes people dependencies and prevents configuration drift. This is so every engineer follows the same rules about naming variables, function calls, conditional logic and other programming constructs.

So, where should infrastructure teams start?

1. Develop a basic understanding of DevOps concepts like immutable infrastructure and declarative programming constructs, CI/CD pipelines, tools from ISVs and cloud providers. One of my colleagues provides an excellent read on the topic of DevOps.
2. Make decisions about tools (everything from code repositories to provisioning, containers, orchestration and pipeline management tools) quickly. There are many tools and picking the right tool can be overwhelming. The good news is that there is not a significant difference in functionality among tools, however, there is a clear set of leaders and followers in the vendor landscape.
3. Practice pair programming early to start thinking like developers and write "good code."
4. Have ready access to a staging (sand box) environment to experiment and learn.

Now is a good time for infrastructure engineers to start adapting and mitigate the risk of diminishing relevance. Make sure to follow our DevOps topic area to stay up to date on the latest from our experts, or reach out directly to start the discussion around your unique needs and goals.