It’s often challenging for established tech companies to adopt modern DevOps practices around infrastructure-as-code (IaC). It’s not so much in adopting the syntax, but rather the DevOps culture that IaC is part of for engineering organizations.
Organizations often struggle to transition from traditional operations models to collaborative DevOps culture, which is a byproduct of transitioning infrastructure operations to code.
In many cases, legacy tendencies persist, while IaC duties stay siloed within ops-centric DevOps teams—which is the exact opposite of the benefits of leveraging powerful technology like infrastructure-as-code. What this ultimately creates is bottlenecks in development velocity and product iteration.
With all this in mind, it begs the question: What changes can enable a smoother IaC journey?
Having DevOps teams shoulder the entire IaC burden is the exact anti-pattern we’re looking to avoid when truly transitioning to DevOps culture in our organizations. What many organizations start to experience is these familiar pain points that start to emerge:
Developers—by nature of their day job as software engineers—often lack access, visibility and context into infrastructure changes. Yet, with more and more infrastructure requirements shifting left, they are left (pun intended) with insufficient capabilities to manage these growing needs.
This is compounded when they are faced with minimal cloud permissions. Limited permissions make it difficult to experiment and familiarize themselves with cloud tools and capabilities the way they would with code and its parts of the stack.
Meanwhile, DevOps teams—as the exact mirror image and the nature of their role in the organization—don’t grasp application needs and objectives. This often results in a widening chasm of broken communication and collaboration around IaC initiatives.
A common tool that exacerbates the problem is a ticketing and support platform. Developers, as their modus operandi, lacking a shared understanding of the domain, will often resort to opening tickets to achieve their goals. This creates a culture of inefficient cross-team communication via ticketing systems.
This doesn’t mean the ticketing platforms are the problem, it just results in inefficient communication methods, as developers don’t always know what questions to ask.
What this does mean is that DevOps engineers operate largely on instinct, being mostly in the dark on the real application requirements that can’t all be communicated in a simple Jira ticket. This results in final solutions that rarely satisfy needs on the first attempt and take longer to deliver.
DevOps teams hold the responsibility for conducting and orchestrating release engineering, on top of provisioning environments, maintenance, monitoring and other tasks that fall in the DevOps engineering domain.
This is why DevOps tasks can become a bottleneck, as they not only dictate deployment timing (due to important considerations of uptime and client disruption, among others) but are also tasked with juggling infrastructure changes across many and multiple environments.
This causes unpredictable delays in provisioning dev environments and other developer-oriented tasks that frustrate developers and stall production updates, and delivery velocity.
Recognizing these inefficiencies and shifting these responsibilities left became the popular way for DevOps leaders to distribute IaC duties. This allowed developers to gain sufficient autonomy to choose the solutions for their needs, while DevOps teams provided guidance and oversight for how to practically achieve these solutions.
However, like all things shift left, this comes with its own set of unique challenges. Adopting the DevOps paradigm faces fundamental obstacles that add further complications and complexity to these cultural transitions, including:
On the one hand, distributing the IaC load lessens the burden on the DevOps teams, but the downside is that it becomes difficult to understand which resources are actually in use and which have been temporarily created for testing purposes.
With many owners creating resources on demand, once they are no longer needed, these leftovers create confusion around dependencies and make cloud platforms disorganized and difficult to maintain.
Just like enabling more hands to touch IaC creates greater sprawl and disorder, more users with less governance invite careless sprawl in terms of costs as well. This often results in duplicate and unused resources accumulating, wasting budgets that are currently tight, and every penny counts. With a lack of automation and oversight, environments grow messy and expensive.
The sprawl issues can also impact security, as expanding permissions raises valid security concerns that are intensified when clouds become disorganized and difficult to maintain.
Well-intentioned developers may misconfigure resources or expose sensitive systems, and without proper methods to manage drift or misconfiguration, this can pose real risks to organizations and systems. Another important aspect that also increases with less oversight is intentional insider risk.
OK, that must have been really disheartening—and you’re probably thinking you should run for the hills before attempting any transitions to shared responsibility.
But wait—don’t panic yet. It is possible for teams to redistribute IaC responsibility while avoiding these pitfalls.
Below are some key factors to help you make the transition smoother in the short and the long term:
RBAC will enable developers to gain the necessary freedom while minimizing security risk. Minimum required access encourages responsibility and constraint.
Now that you have a solid grasp of the principles, it’s time to put them into action!
Fortunately, there are numerous solutions at your disposal. You can jump in and build them yourself using capable tools like Jenkins or Atlantis.
Alternatively, for a more comprehensive approach, there are excellent commercial IaC management tools on the market. These can assist you in reaching your objectives swiftly and with greater efficiency.
As technology complexity increases, no single team can handle infrastructure alone. Dev and Ops must unite abilities to shepherd modern systems and the underlying code powering them. This requires closing knowledge gaps through collaboration and communication
With a thoughtful process, IaC automation, governance guardrails and the right access policies, tech leaders can guide this cultural transition smoothly without exposing the organization to unnecessary risk and spending.
When done right, Shared IaC responsibility will boost velocity, agility, and autonomy—the trifecta of crucial traits that quantify and qualify elite engineering teams and differentiate companies in a competitive landscape.
Interested in learning more about env0 to manage your IaC at scale and confidently?
To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.
Filed Under: Blogs, Continuous Delivery, Continuous Testing, DevOps Culture, DevOps Practice, Infrastructure as Code, Infrastructure/Networking, IT as Code, Social – X Tagged With: devops culture, IaC, infrastructure, infrastructure as code, scalability
Secure Coding Practices
Step 1 of 7
14%
Does your organization currently implement secure guardrails in the software development process?(Required)
Yes, extensively across all projects
Yes, but only in specific projects or teams
In the process of implementation
No, but planning to in the near future
No, and no plans to implement
What are the biggest challenges you face in implementing secure guardrails within your development processes? (Select all that apply)(Required)
Lack of awareness or understanding
Technical difficulties in integration
Resistance from development teams
Lack of suitable tools
Cost constraints
Other
Other, tell us more:
How effective do you find secure guardrails in preventing security vulnerabilities in your projects? Rate on a scale from 1 (Not effective) to 5 (Highly effective)(Required)
1
2
3
4
5
To what extent are your secure guardrails automated?(Required)
Fully automated
Mostly automated with some manual processes
Equally automated and manual
Mostly manual with some automation
Entirely manual
What features do you prioritize in a secure guardrail solution? (Rank in order of importance)Ease of integration into existing workflowsComprehensive coverage of security vulnerabilitiesCustomizability for specific project needsMinimal impact on development speedActionable insights and recommendationsSupport for a wide range of programming languages and frameworks
What are your organization’s plans regarding the adoption or enhancement of secure guardrails within the next 12 months?(Required)
Expand the use of secure guardrails to more projects
Enhance the capabilities of existing secure guardrails
Maintain current level of secure guardrail use without changes
Reduce reliance on secure guardrails
No plans related to secure guardrails
What best describes your primary role?(Required)
Security Engineer
DevOps Engineer
Platform Engineer
Security champion on the development team
Software Developer
CISO (or equivalent)
Sr. Management (CEO, CTO, CIO, CPO, VP)
Manager, Director
Other
Δ
