devopsy.kinsta.cloud

Tag: IaC

ZEST Security Brings Generative AI to Cloud Infrastructure Security

ZEST Security has launched a platform that leverages generative artificial intelligence (AI) to remediate code created using infrastructure-as-code (IaC) tools.

Fresh off raising $5 million in funding, company CEO Snir Ben Shimol said the ZEST platform will both correlate and pinpoint the root cause of a vulnerability risk and generate recommendations and code to enable DevOps teams to address the issue.

Today it takes, on average, 30 to 60 days to manually remediate, for example, a cloud misconfiguration. The ZEST platform will reduce that time to a matter of hours, said Ben Shimol.

It also helps ensure the same mistakes are not repeated by identifying errors before code is used to provision IT infrastructure, he added. That’s critical because 80% of resolved issues resurface as developers make the same mistakes multiple times, noted Ben Shimol.

More challenging still, the tactics and techniques employed by cybercriminals continuously evolve, he added. An instance of cloud infrastructure that seemed perfectly secure can suddenly be vulnerable to a zero-day vulnerability, said Ben Shimol.

At the core of the ZEST platform is a large language model (LLM) that has been customized to identify IaC issues and generate Terraform, Pulumi or AWS CloudFormation code.

While cloud platforms are generally more secure than the average on-premises IT environment, the way are provisioned by developers often leads to misconfigurations that are easily exploited by cybercriminals.

Unfortunately, the average developer lacks cybersecurity expertise so the number of these potential misconfigurations that exist is extremely high. One of the reasons so many applications still reside in on-premises IT environments is that many IT and cybersecurity leaders are concerned that the processes used to build and deploy cloud applications, under the current shared responsibility model that cloud service providers require, are deeply flawed.

It’s not clear to what degree cloud service providers are working to address those concerns by providing developers with access to more training, but in the meantime, LLMs that have been trained to generate specific types of code are emerging. The issue now is finding a way to systematically review all the cloud instances that have been previously programmatically invoked using IaC tools.

In the meantime, the overall quality of the code used to provision cloud environments should steadily improve thanks to the rise of AI. That’s critical at a time when the number of applications being deployed continues to steadily increase. Less clear is to what degree funding for those AI platforms will be funded by cybersecurity teams that are held accountable for application security versus the DevOps teams that provision cloud infrastructure.

One way or another, however, cloud security issues will inevitably be forced as forthcoming regulations require organizations to lock down their software supply chains, many of which today are either partially or wholly dependent on cloud infrastructure.

Ultimately, better cloud security benefits everyone concerned. The challenge is that when cloud security is everyone’s responsibility, there is a tendency for no one to be held specifically accountable for ensuring it is achieved and maintained.

July 31, 2024
To Monetize HashiCorp, IBM Must Perform an Unprecedented Balancing Act

IBM’s multi-billion dollar deal to buy HashiCorp has left the hybrid cloud industry guessing what the future holds in store for the most popular provider of tools for DevOps and infrastructure-as-code (IaC).

HashiCorp was rumored to have been looking for an acquirer for several months before the deal was announced. Despite enjoying top dog status in the IaC space thanks to its flagship Terraform app, the company had been struggling to translate its popularity into profitability, resulting in immense pressure from shareholders to do something drastic.

HashiCorp’s financial struggles were all too apparent when it published its fiscal 2023 financial results, revealing a $274 million loss on a total revenue of $583.1 million that year.

Its inability to drive a profit is thought to be what prompted the company to make the controversial decision of replacing Terraform’s open-source Mozilla license with a more restrictive Business Source License (BSL 1.1), which caused an uproar among developers and partners. Such was the Terraform community’s dismay that it quickly responded by creating a Terraform fork, eventually called OpenTofu, which rapidly accumulated a big following.

IBM’s challenge is to turn HashiCorp’s fortunes around, and there has been a lot of speculation over how the company intends to do that. It can go one of two ways — either it can make Terraform more restrictive, binding it more tightly with its own cloud products and services, or it can perform a rapid U-turn and embrace the open-source community once more.

Open Source is a Tough Business

HashiCorp is not alone in its struggles. The challenges of monetizing open-source software are well documented, and many of HashiCorp’s peers have opted to take a similar approach, making their products more restrictive in an effort to stop bleeding cash. Redis, for instance, recently mirrored HashiCorp’s move when the company announced it was dropping its Berkeley Software Distribution license in favor of a new Redis Source Available License and Server Side Public License model, placing restrictions on how its database software can be modified. Elasticsearch made a similar move in 2021.

The problem with open-source software is that its development is anything but free. While there are a handful of projects led by hobbyist developers, the reality is that most are under the control of big technology firms that employ armies of developers to maintain them. Google, for example, is the main contributor to the Kubernetes project, and it pays hundreds of developers to work on that initiative full-time. This is possible because the company makes money from selling cloud infrastructure services that support Kubernetes workloads.

However, other companies cannot do this, and HashiCorp is a prime example. For most users, the open-source version of Terraform had already provided everything DevOps teams needed to orchestrate their cloud environments, and they saw little reason to pay for the premium Terraform Cloud product, even if it was a little easier and had some nice add-ons.

HashiCorp said in October 2023 that it was hoping to become profitable by the second half of its fiscal 2025 year, but the growth metrics that the company has reported in recent quarters make this goal look like a longshot at best.

Open or Closed? That is the Question

One of the reasons why Terraform quickly became the most popular IaC offering was its cloud-agnostic nature. Most organizations these days are multi-cloud and Terraform gives them a common configuration language.

For IBM, maintaining this cloud-agnostic nature of Terraform might be perceived as a conflict of interest. With IBM Cloud having a tiny market share of just 1.8%, it seems to make little sense to keep supporting a tool that enables people to use its competitors.

This has led to concerns that IBM plans to bind Terraform more tightly with its own cloud offerings. The company may opt to prioritize integration with IBM Cloud at the expense of other cloud infrastructure platforms. It also seems likely that IBM will want to integrate Terraform with Red Hat, which is now its biggest revenue growth driver. Interoperability could be limited to IBM’s products, and access to its source code could be limited to paying users only, to maximize revenue.

The Terraform community is unlikely to appreciate such a move, given its reaction to HashiCorp’s licensing changes last year. In an op-ed in Forbes, Futuriom analyst Scott Raynovich highlighted the extremely negative response by many Terraform users, accusing the company of turning its back on its open-source roots.

“The open-source licensing had enabled thousands of partner companies to incorporate Terraform and other HashiCorp coding into products that are sold commercially,” Raynovich noted. “The announcement also lit a fire under the age-old debate of what’s cool and what’s not cool in the open-source community. As you can imagine, a lot of people thought it wasn’t very cool.”

However, there is plenty of optimism that IBM could be good for HashiCorp. In particular, there was a positive reaction from the Terraform community on Reddit, with many members expressing their hope that IBM would make Terraform open source again. While a more restrictive approach might make sense from a revenue perspective, IBM will also be well aware of the benefits of such a move.

Sebastian Stadil, a co-maintainer of the forked OpenTofu project, recently told The New Stack he would be open to reconciling with Terraform if ever HashiCorp decided to return to a more open licensing model. He also revealed that OpenTofu’s maintainers have held confidential talks with IBM, without providing any details.

It is clear that OpenTofu, with its less restrictive model, represents a significant threat to Terraform; so IBM might well be motivated to eliminate one of its biggest potential challengers by returning to the open-source path.

Terraform is Not the Only Show in Town

A decision by IBM to continue along the path laid out by HashiCorp’s management is unlikely to result in everyone abandoning Terraform. For many users, it will be far too inconvenient or challenging to swap it out for some other kind of cloud provisioning tool, especially if subsequent versions of OpenTofu are less compatible with Terraform over time.

Although Terraform is widely seen as the leading IaC tool, it is not so popular that it can influence the entire industry. DevOps practitioners are exemplified by their resourcefulness and their innovativeness, and they will always be able to find an alternative way forward.

In a recent panel discussion hosted by IaC management framework company Env0, Ohad Maislish, CEO, commented on the tool ecosystem around Terraform and how that might translate for companies that embrace alternatives. “OpenTofu is a unique example of something that from day one already has a very mature ecosystem of adjacent solutions and technologies,” he said. Today, many cloud providers already offer open-source modules to support deployment via OpenTofu.

OpenTofu isn’t the only alternative, either. Pulumi is another option, though it also has financial sustainability concerns, with a business model that seems similar to HashiCorp’s old, pre-license switch. Then there is Crossplane, which has a more Kubernetes-centric flavor and is backed by the Cloud Native Computing Foundation. A third option is for Terraform users to instead go with the dedicated offerings of the major cloud infrastructure providers, such as Cloud Formation for AWS, Config Controller in Google Cloud and Bicep on Microsoft Azure.

Striking the Right Balance

Whichever path IBM decides to take, the tech giant’s leadership will do well to remember that in the DevOps industry, there is a mindset that emphasizes principles over the tools required to do the job.

Should Terraform evolve in a direction that displeases the DevOps community, the industry will simply switch to a new standard. After all, one of the things that characterizes the DevOps movement is the ability of teams to quickly adapt and embrace new tools and systems that allow them to get things done faster and more efficiently.

For now, IBM is keeping its plans for Terraform under wraps. The challenge it faces is to keep the majority of Terraform’s users happy, while finding a way to turn a profit. Getting it right means performing an extremely delicate balancing act that has few precedents. It may not be impossible, but it will be an impressive feat if IBM can do it.

July 29, 2024
Benefits and Best Practices for Infrastructure as Code
Infrastructure as code (IaC) has changed how the infrastructure is managed and automated by treating configurations and infrastructure setups as code. It allows for the provisioning and managing of infrastructure through automated scripts to increase efficiency, consistency and scalability.

IaC is incredibly relevant in modern DevOps practices, enabling rapid deployment, version control and collaboration, which are essential for supporting continuous integration and continuous deployment (CI/CD) workflows.

In this post, we will look at some of the biggest benefits of implementing IaC and the best practices for doing so.

The Benefits of IaC

Adopting IaC for your projects has many benefits — from enhanced operational efficiency to consistency across environments.
- Speed and Efficiency
IaC dramatically reduces deployment times and operational overhead. Instead of manually configuring hardware or virtual machines, IaC allows you to define infrastructure requirements in code.

This automation enables quick, consistent deployments across environments, eliminating manual errors and the need for repetitive setup tasks. As a result, you can focus on development and innovation, which speeds up the delivery of new features and services while reducing costs associated with manual operations.
- Consistency and Standardization
By defining infrastructure through code, IaC directly minimizes human error, replacing manual configurations with automated processes and ensuring consistent configurations across different environments. Executing the same code eliminates the discrepancies that manual setups often introduce and enhances the reliability of deployments.
- Scalability and Flexibility
IaC supports scalable infrastructure management by enabling rapid provisioning and de-provisioning of resources through automation. This adaptability allows systems to scale up or down efficiently in response to changing requirements. Infrastructure can dynamically adjust to varying load demands without manual intervention, optimizing resource utilization and responsiveness.
- Auditability and Compliance
IaC also brings significant benefits in maintaining compliance and simplifying the audit process. Through version control, IaC ensures every change to the infrastructure is tracked and documented. It creates a transparent, auditable history, providing a clear, immutable record of all infrastructure modifications. This helps adhere to compliance standards and streamlines audit activities.

Best Practices for Implementing IaC

As we’ve seen above, adopting infrastructure as code can significantly improve how you manage and provision IT resources. However, you should follow the best practices to reap its full benefits. In this part, we will outline essential strategies such as version control, code reuse, security measures and automation, which are crucial for effective IaC implementation.
- Modularize and Reuse Code
Creating modular IaC components involves breaking down infrastructure into smaller, reusable pieces that can be shared across projects. The strategies here include:
- Defining clear interfaces
- Using parameterization to customize components for different environments
- Packaging common patterns as templates or modules.
This approach promotes leveraging pre-built components to achieve reusability, reduce duplication and accelerate the deployment process.
- Keep Security in Focus
Integrating security practices into the IaC lifecycle is crucial for maintaining robust security postures. It includes conducting regular security scans to detect vulnerabilities early and applying the principle of least privilege to limit access rights for users and systems to the minimum necessary. These practices help prevent security breaches and ensure compliance with security standards, safeguarding the infrastructure throughout its lifecycle.
- Automate Testing and Deployment
Automated testing and deployment processes in the development process can be streamlined by CI and CD. CI ensures that code changes are automatically built and tested, facilitating early detection of errors. CD automates the deployment of code changes to various environments, accelerating the delivery of new features and fixes while ensuring stability and reliability.
- Version Control Everything
Using version control systems for IaC scripts is essential for tracking changes, improving collaboration and enabling rollback capabilities. It ensures that every modification is documented, providing an audit trail that enhances transparency and accountability. The VC practice supports effective team collaboration on IaC scripts and helps maintain the integrity and reliability of infrastructure deployments.
- Document and Review Code Regularly
Related to version control, documenting IaC configurations and conducting regular code reviews are very important for ensuring clarity, maintainability and quality.

Documentation provides a clear understanding of the infrastructure setup and intent, allowing easier maintenance and onboarding. Meanwhile, code reviews enhance code quality by identifying potential issues and making improvements.

Overcoming Common Challenges in IaC

In the process of adopting IaC, you may use tools like Pulumi and Terraform and may often encounter obstacles such as configuration drift, where the actual state of the infrastructure diverges from what was defined in the code. This can lead to inconsistencies and operational challenges. You should also put significant concerns into ensuring security and compliance within rapidly deployed infrastructures and managing the complexity of large-scale, multi-service environments.

The best practices mentioned above should help mitigate these challenges. For example, rigorous version control and state management policies can help track and reconcile differences, preventing drift. Integrating automated security scans and compliance checks into the CI/CD pipeline ensures that security standards are embedded from the outset. For managing complexity, adopting modular design principles and reusable components can simplify the management of large infrastructures.

Additionally, providing comprehensive training and leveraging community insights can further empower your team to utilize IaC methodologies effectively.

Wrapping Up

IaC revolutionizes IT infrastructure management by automating and codifying the deployment processes, ensuring consistency, efficiency and security. By adopting IaC best practices, such as version control and automated testing, organizations can significantly enhance their operational agility and responsiveness to changes.
July 16, 2024
Scaling with Terraform: How to Manage Infrastructure at Scale

Managing large-scale infrastructure is a complex task that requires a strategic approach, especially when using infrastructure-as-code (IaC) tools such as Terraform. As organizations expand, their infrastructure must scale accordingly; however, it often becomes more intricate and challenging to manage. Terraform provides a robust framework for defining, provisioning and managing infrastructure, but scaling these operations requires a deep understanding of both Terraform and best practices for large-scale infrastructure management.

In this article, we will delve into effective strategies and practices for managing Terraform infrastructure at scale.

Benefits of Using Terraform for Large-Scale Infrastructure

● Scalability: Terraform is designed to handle complex infrastructures with ease. Its modular architecture and state management capabilities allow you to scale your infrastructure efficiently.
● Consistency: By defining IaC, Terraform keeps your infrastructure consistent across different environments and reduces the risk of configuration drift and errors.
● Automation: Terraform is a great help when it comes to automating provisioning and management of infrastructure, enabling you to deploy resources quickly and reliably. This automation is crucial for large-scale environments where manual intervention is impractical.
● Collaboration: Terraform’s configuration files can be versioned and shared, promoting collaboration among teams. The collaborative approach ensures that everyone is on the same page and reduces the likelihood of conflicts.

Strategies for Managing Terraform at Scale

As you scale your infrastructure, the complexity of managing resources and ensuring stability increases exponentially. The strategies outlined below will help you scale effectively with Terraform.

Structuring Your Terraform Code

Modularization
A key strategy for managing Terraform at scale is modularization. Breaking down your Terraform configuration into reusable modules enhances readability, maintainability and reusability. Modules are self-contained packages of Terraform configurations that manage a specific set of resources. By utilizing modules, you can standardize configurations across different environments and projects, reducing redundancy and errors.

Organizing by Environment
Separate your configurations by environment (e.g., development, staging and production). This structure prevents accidental changes in production and allows for environment-specific customization.
Example Directory Structure:
├── environments
│ ├── dev
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── provider.tf
│ │ ├── terraform.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
│ └── prod
│ ├── main.tf
│ ├── outputs.tf
│ ├── provider.tf
│ ├── terraform.tf
│ ├── terraform.tfvars
│ └── variables.tf
└── modules
├── ec2
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
└── network
├── main.tf
├── outputs.tf
└── variables.tf

Terraform workspaces are used to manage multiple environments (e.g., development, staging and production) within the same configuration. The isolation ensures that changes in one environment do not impact others.

State Management

Proper state management is crucial when dealing with large-scale Terraform deployments. The Terraform state file contains mappings between your configuration and the deployed infrastructure. Using remote state storage, such as AWS S3 with DynamoDB for state locking, ensures consistency and prevents conflicts.

terraform {
backend “s3” {
bucket = “bucket-name”
key = “path/to/terraform.tfstate”
region = “us-east-1”
“encrypt” = true
dynamodb_table = “terraform-locks”
}
}

Optimizing Resource Configuration and Performance

Here are a few tips to achieve optimal performance in large-scale environments:

● Maintain Consistency in Naming Conventions: Follow a consistent naming convention for resources to make it easier to identify and manage them, especially in large deployments.
● Use Data Sources: Dynamically fetch information about existing resources to avoid hardcoding values.
● Minimize Resource Dependencies: Reduce dependencies between resources to enable parallel deployments and speed up provisioning.
● Apply Lifecycle Hooks: Control the order and conditions under which resources are created, updated or destroyed.
● Review and Update Regularly: Keep your Terraform configurations up to date with the latest features and practices.

Automated Workflows

Integrate with CI/CD Pipelines

Automate your Terraform workflows using CI/CD tools such as Jenkins, GitLab CI and GitHub Actions to minimize manual effort and ensure consistency across deployments.

CI/CD pipelines enable you to automate various stages of your Terraform workflows, including validation, planning and application of changes. This automation ensures that every change goes through a standardized process, reducing the risk of inconsistencies and errors. For example, when a developer submits a pull request with infrastructure changes, the pipeline can automatically trigger the validation and planning stages and notify the relevant team members for review. This process ensures that changes are peer-reviewed and meet the required standards before being merged and applied.

Advanced CI/CD Integration

Terraform Cloud, Terraform Enterprise or Spacelift offer additional features including remote runs, state management and policy as code. These services help manage Terraform at scale by providing a centralized platform for collaboration, governance and automation.

Policy Enforcement

As your infrastructure grows, enforcing policies becomes crucial to ensure compliance and security. Terraform provides Sentinel, a policy as code framework that allows you to define rules governing your infrastructure. By integrating Sentinel policies into your CI/CD pipelines, you can automatically enforce best practices and organizational standards. Alternatively, you can use Open Policy Agent (OPA) with Terraform to achieve these results.

Wrapping Up

Scaling infrastructure with Terraform requires a blend of strategic planning, best practices and the right tools. The key points above can help you effectively manage Terraform infrastructure at scale, ensuring your systems are resilient, scalable and compliant with organizational policies and industry standards.

July 8, 2024
Security, Automation and Developer Experience: The Top DevOps Trends of 2024

If you ask most folks to describe the top DevOps trends in 2024, you’ll likely hear buzzwords like AI or DevSecOps.

Those are certainly trendy topics. But based on my everyday work helping businesses plan and execute DevOps strategies, I’m noticing a different set of salient trends in DevOps. Although much is being said about how technologies like AI might impact DevOps, the biggest changes I’m seeing right now involve other types of solutions and techniques.

Here are what I view as the three most important current DevOps trends, along with a breakdown of how they may change DevOps tools and processes.

Policy-Based Management and IaC Drive DevOps Security Innovation

Security has always been a priority for DevOps practitioners. But right now, I’m seeing DevOps teams adopt new strategies to improve the security of the applications and environments they support.

One large-scale change is the greater use of cloud-based policy management to enforce security best practices in cloud environments. Teams configure cloud services and resources using the code-based configuration frameworks that cloud providers support, then scan the configurations to detect risks.

This approach makes it possible to enforce cloud governance consistently, centrally and automatically. Instead of simply writing governance policies and hoping that engineers remember to follow them when they configure cloud resources, businesses are building automated governance guardrails via policy-based management.

In a similar vein, more and more of the DevOps teams I work with are embracing static code analysis of infrastructure-as-code (IaC) templates as a means of detecting risks. As with policy-based management of cloud resources, an IaC-centric approach to infrastructure provisioning makes it possible to automate infrastructure management and identify security risks earlier in the development lifecycle.

Some teams use cloud policy and IaC code scanning to warn one another about security policy changes that might cause an application or service to break. They do this by inserting configuration changes into their code using “audit” mode if their configuration framework supports it, or by configuring IaC scanners to flag changes if an audit feature is not available. This allows engineers to detect whether a change might cause a problem for an existing deployment.

This is important because security and application teams operate separately in many organizations. When the two groups lack an efficient way to communicate about changes, they can disrupt each other’s operations – the “right hand/left hand” problem. Configuration scanning provides a systematic way to ensure that each group is on the same page when it comes time to introduce changes – and the “audit” mode approach provides a grace period that allows time to react before a change takes effect.

Doubling Down on DevOps Automation with GitOps

Another overarching trend currently reshaping DevOps is using GitOps to make DevOps automation more efficient and consistent.

GitOps is the use of Git (or a similar source control system) to manage automated DevOps workflows. It involves defining configurations using code and applying them through features like GitHub actions.

When you opt for GitOps, you move DevOps automation controls from individual workstations to centralized source control repositories. The result is the ability to track and manage all automated workflows via a central hub. Doing so increases efficiency and mitigates issues like different engineers working with different versions of the same automation frameworks on their personal desktops.

In addition, GitOps automatically generates records of what changed and how it changed, because every action is logged through the source control system. This isn’t exactly documentation in the traditional sense and means that GitOps comprehensively documents every change – which is beneficial because human engineers tend not to be so thorough when documenting their actions.

To be sure, GitOps is not without its challenges. Implementing GitOps effectively requires additional skills – namely, expertise with both IaC frameworks and source control systems – that not all DevOps engineers possess. I also notice a tendency on the part of some teams to set up GitOps pipelines but rely on manual approvals instead of automated actions to trigger changes. That approach largely undercuts the value of automating pipelines in the first place.

However, these are challenges that teams can solve through education and by fully leaning into GitOps. In addition, techniques like automated testing of GitOps configuration code can help to build teams’ confidence in automations and reduce reliance on manual approvals.

Going forward, expect to see more adoption of GitOps techniques among teams seeking to level up their approach to DevOps automation. Automating individual DevOps processes (such as software testing and deployment) won’t be enough; truly efficient organizations will turn to GitOps to automate their entire DevOps workflows, from end to end.

Investing in Developer Experience

Making software delivery processes more predictable and efficient is merely a step toward DevOps’s ultimate goal, which is to help developers become productive and satisfied with their jobs.

To that end, I’m noticing interest and investment in developer experience right now. This is playing out through two interrelated initiatives.

One initiative is platform engineering. It involves creating DevOps teams that specialize in certain functions, such as network management or security. Those teams are designated to support those functions throughout the organization. This approach reduces cognitive overhead for developers by freeing them from the need to handle types of work outside their main focus. In other words, instead of forcing developers to be DevOps generalists, platform engineering lets different teams focus on doing what they know and enjoy best – leading to greater productivity and higher levels of job satisfaction.

The other major developer experience trend currently playing out is developer self-service. This means developers can obtain the technical solutions they need on demand without a complicated procurement process. In most cases, organizations enable self-service by implementing internal development platforms (sometimes called internal developer portals) (IDPs) which host ready-made infrastructure resources and software environments that developers can deploy on a self-service basis.

There are risks inherent in these trends. They require specialized types of skills. When poorly implemented, platform engineering and IDP solutions can create more problems than they solve. However, when you ensure that your teams have the requisite expertise, and deploy a carefully planned IDP that gives developers access to the resources they need, you’re likely to see a significant reduction in friction within your organization and a boost in developer productivity and happiness.

Real-World Changes, Beyond the Hype Cycle

Admittedly, discussing DevOps trends centered on security, automation and developer experience may not be as exciting as debating whether AI will take away DevOps engineers’ jobs. But if you want to know what’s truly changing in the world of DevOps – as opposed to which conversations are most hype-worthy – these are the places to look.

Security, automation and developer experience are also among the domains of DevOps where there is a great deal of opportunity to innovate – and, indeed, where adopting new tools and techniques will be critical for organizations that don’t want to be left behind as DevOps evolves.

May 17, 2024
Hashicorp Versus OpenTofu Gets Ugly

When HashiCorp dumped its open-source Mozilla license for the Business Source License (BSL 1.1) for its flagship program, infrastructure as code (IaC) tool Terraform, many Terraform developers and partners were ticked off. As open source developers are wont to do in such situations, they created a Terraform fork, called OpenTofu.

So far, that’s business as usual when a company shifts a project away from open source. Things heated up, though, when the Linux Foundation announced it would support the new fork. Now, the conflict between HashiCorp and OpenTofu is starting to boil, as HashiCorp accused OpenTofu of “not respecting the terms of its BSL license governing its Terraform codebase.”

Them’s fighting words!

OpenTofu replied, “OpenTofu vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code.” The organization added, “HashiCorp may be conflating code that it had previously been open-sourced under the MPL and more recently developed code it published under the BSL.” And, OpenTofu says, it will “issue a written response providing a more detailed explanation of its position.”

So, what is this code in question? Neither Hashicorp nor Terraform is saying, quite yet. However, it appears to be a “removed block” automation process that enables Terraform to manage resource deletion.

Matt Asay, MongoDB‘s VP of Developer Relations, revealed this accusation. He accused OpenTofu of lifting the “removed block” code, which was released under the BSL a few months after the OpenTofu fork was created. “The tell? OpenTofu took this BUSL-licensed HashiCorp code, removed the headers, and tried to instead relicense it under the Mozilla Public License (MPL 2.0),” Asay wrote.

Oh, it’s on now.

Even before news of the legally threatening message emerged, prominent open source leaders attacked Asay’s claim. Bryan Cantrill, the hyper-cloud Oxide Computer co-founder and CTO, claimed, “This is an extraordinarily serious accusation – and the cited files frankly don’t substantiate it.”

Cantrill is far from alone in thinking that there is insufficient evidence to justify the accusation that OpenTofu has stolen any code. Until we have harder evidence, the issue will remain a case of “He said, she said.”

Chris Aniszczyk, the CTO of the Cloud Native Computing Foundation (CNCF), a Linux Foundation-related organization, doesn’t think it’s a good look for HashiCorp. He said it’s “embarrassing to see a company light all of its hard-earned developer reputation on fire, on top of attacking open source.”

Dan Lorenc, CEO and co-founder of Chainguard, a software supply chain security company, warns this could be the start of something big and ugly in software development circles. “I don’t have any philosophical or ethical issues with source-available licenses, but their proponents are going to have to address these cease-and-desist threats,” he wrote. “Developers working in OSS (OSI/FSF approved licenses) are going to be prevented from engaging with or even looking at source-available projects completely to prevent the risk of lawsuits. It’s just too risky to pretend otherwise.”

Lorenc adds, “There’s no gradual transition here, it’s going to be a hard fork in communities if these lawsuit threats keep continuing. And I know which community I’d bet on sticking around.”

I lived through the SCO-Linux copyright wars. I think I know who will win, too.

Photo credit: Quino Al on Unsplash

April 9, 2024
The IaC Weight on DevOps’ Shoulders
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?

The Pitfalls of IaC Silos

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:

1.) Knowledge Gaps Widen

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.

2.) Collaboration Suffers

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.

3.) Releases Slow to a Crawl

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.

The Obstacles of Change

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:
- Uncontrolled sprawl
- Ballooning costs
- Security concerns
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.

From Silos to Shared Responsibility

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:
- Automate everything—If DevOps practices have taught us anything, it is that manual cloud environment maintenance doesn’t scale. Automation has been the backbone of much of the evolution we have undergone when it comes to infrastructure operations, and this has been powered by the programmability and everything-as-code mindset—from IaC to policy-as-code (PaC). This automation-based optimization makes it possible to reduce neglected resources through regular and automated analysis and response. What you get is cost savings and the prevention of runaway sprawl.
- Empower through governance—Remember when we spoke about automation and governance? Well, programmatic policy enforcement is a good way to constrain unwanted resource proliferation without manual intervention. Governance comes in to handle auto-remediation of misconfigurations or other anti-patterns that do not align with automated policies, which simplifies environment management at scale. Importantly, governance, if done right, can be a tool to empower teams, break silos and encourage autonomy. Having the right guardrails in place is how you instill confidence and provide helpful direction.
- RBAC for the win—Role-based access control (RBAC) limits permissions to appropriate needs, establishing important guardrails that can help prevent some of the issues we spoke about above, including sprawl and security concerns.
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.

An Evolutionary Vision for IaC and DevOps

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?

Stop by Booth L12 at KubeCon EU to speak with an expert or see a demo!

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.
March 13, 2024
Survey: Significant Shift in IaC Tool Preferences

A survey of 350 IT professionals conducted by Firefly, a provider of a platform for managing cloud computing environments, suggests usage of infrastructure-as-code (IaC) tools is evolving rapidly in the cloud computing era.

For example, more than 40% of the respondents reported that, to some degree, they are already using OpenTofu, an open source IaC tool that was launched as a fork of the Terraform IaC in the wake of changes to the software licensing terms it is made available under by HashiCorp. Well over half said they planned to use OpenTofu in the future. That compares to 60% using Terraform today, but only just over 20% said they planned to use Terraform in the future.

The licensing changes HashiCorp implemented only affect third-party entities within a third-party platform. However, the survey indicates the number of end users affected by that change is more substantial than anticipated. A full 56% of respondents described the changes made to the Terraform license as disruptive.

The survey also finds there is a lot more diversity in terms of the types of IaC tools being employed, with both the IaC tools from Pulumi and the open source Crossplane framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) also gaining traction. The report finds more than 40% of respondents are also using Pulumi, with well more than half planning to use that IaC tool in the future.

Crossplane, meanwhile, is now being used by 40% of respondents, with 60% planning to adopt it.

Conversely, the report also notes the number of organizations planning to migrate away from CloudFormation from Amazon Web Services (AWS) is rising. While well over 60% use AWS CloudFormation today, only a third plan to use it in the future.

Cindy Blake, vice president of marketing for Firefly, said as organizations employ additional cloud platforms, IT teams are clearly looking for tools that make it easier to centralize the management of multiple computing platforms. That trend will only accelerate as more DevOps teams adopt platform engineering as a methodology for managing the building and deployment of applications at scale, she added.

In fact, noted Blake, it’s already fairly common for IT teams to use two or more frameworks. The report finds 57% of respondents work for organizations that are using two or more frameworks. Overall, the report finds that more than 64% of respondents have also codified more than half of their cloud assets.

The number of organizations employing IaC tools to programmatically manage infrastructure is only going to increase, said Blake. The report, for example, found that three-quarters of respondents either already are or plan to use IaC tools to configure software-as-a-service (SaaS) application environments. In the longer term, advances in artificial intelligence (AI) will make it simpler for organizations to achieve that goal. Open source tools such as AiAC, for example, already make it possible to leverage large language models (LLMs) to generate code. Those types of tools will eventually eliminate the need to master specific programming languages to provision IT infrastructure as code, noted Blake.

It’s not clear how IaC tools within the context of DevOps workflow will evolve, but the one thing that is certain is that the number of types of tools being adopted has never been more diverse.

February 29, 2024
Immutable Infrastructure: The Next Step for DevOps

Immutable infrastructure, a concept that is rapidly gaining traction within the dynamic field of DevOps, offers a transformative approach to organizational security for companies of all sizes.

Instead of the traditional method where existing components are continuously updated and modified, immutable infrastructure advocates for an entirely different philosophy: Components are replaced wholesale with new versions and never altered after deployment. This type of paradigm shift promises a plethora of advantages, chief among them being enhanced consistency and reliability, which is a potential game-changer for DevOps practices.

This article offers a thorough exploration of immutable infrastructure, taking a look at its core principles and examining why it’s becoming a focal point in the DevOps community. To help further bring these concepts to life, we’ll thoroughly examine the tools and techniques that are pivotal in its implementation.

Understanding Immutable Infrastructure

Immutable infrastructure is rapidly gaining traction in the world of cloud services and DevOps for its innovative approach to managing servers and components. Once deployed, these elements are not modified or updated; instead, new servers are created from a common image whenever changes are necessary.

This type of approach simplifies rollback procedures and minimizes troubleshooting, as the integrity of servers is maintained. Furthermore, this methodology, facilitated by OS-level virtualization, marks a significant departure from more traditional practices.

And with the AI market already worth $313 billion, integrations of models and solutions will only become more popular. Integrating AI into immutable infrastructure can significantly enhance its efficiency and reliability.

In such systems, AI can be used to monitor and analyze system performance continuously. By applying machine learning algorithms, it can predict potential issues and automate the process of deploying new server instances before problems arise.

Comparing Immutable and Mutable Infrastructures

The Immutable Approach

Immutable infrastructure offers streamlined change tracking and rollback, with each new server or VM being easily identifiable. Its uniform configuration across servers simplifies testing and the unaltered state post-deployment reduces complexity.

This makes it ideal for environments with numerous interdependent elements, such as in DevOps and cloud computing, virtually eliminating configuration drift.

Challenges With Mutable Infrastructure

In contrast, mutable infrastructure necessitates more time for server provisioning due to manual configurations. It’s prone to various update failures and connectivity issues, with each server’s unique configuration complicating diagnostics.

This traditional approach struggles with unpredictability, making it less suitable for modern DevOps practices and resulting in frequent configuration drifts.

Advantages of Immutable Infrastructure

Opting for immutable infrastructure brings numerous benefits. Support calls are significantly reduced and security is enhanced, thanks in part to the use of machine learning to identify anomalies.

The implementation of safelisting rules strengthens security controls. Moreover, this approach mitigates configuration drift and negates the need for synchronization during updates, leaning on cloud platforms for swift VM management. It also ensures rapid recovery due to easy rollbacks and encourages experimentation, thus fostering innovation.

Best Practices for Immutable Servers

Adopting immutable servers involves several best practices all organizations would be wise to apply. Building images in a chroot environment helps isolate changes while keeping test suites lean and efficient while avoiding overburdening the change process as a whole.

Caching installation files near the build location optimizes update speeds, layering images on top of a base server image expedites updates, and minimizing the OS image reduces boot times and security risks. Additionally, using containers can dramatically speed up and simplify the process.

Essential Tools for Immutable Infrastructure

When it comes to immutable infrastructure, certain key tools have emerged as indispensable for efficiently managing and maintaining this modern approach. These tools help create, manage and deploy server images and infrastructure-as-code throughout organizations.

Here’s a closer look at some of these essential tools:

Packer

Packer is a crucial tool for creating identical machine images for various platforms from a single source configuration. This tool is instrumental in the immutable infrastructure because it allows for the creation of fixed server images that can be quickly deployed, ensuring consistency across environments.

Terraform

Terraform by HashiCorp is another key player, enabling users to define and provide data center infrastructure using a declarative configuration language. It helps maintain the infrastructure-as-code, which is an essential aspect of immutable infrastructure.

Terraform allows for safe and predictable changes to infrastructure, with efficient management of both cloud and on-premises resources.

Docker

Nowadays, Docker is synonymous with containerization, allowing applications to be packaged into containers—consistent, isolated environments that encapsulate all the necessary components of immutable infrastructure.

Docker helps to simplify the deployment process and ensures that applications run the same way everywhere, aligning perfectly with the core principles of immutable infrastructure.

Kubernetes

While not directly mentioned earlier, Kubernetes deserves recognition for being a powerful orchestration tool for containers, including those that are managed by Docker. Kubernetes excels in automating deployment, scaling and management of containerized applications, which aligns well with immutable infrastructure principles.

SaltStack

SaltStack offers configuration management and orchestration tools, standing out for its ability to manage and automate more complex and scalable infrastructures, making it suitable for environments where immutable infrastructure is implemented. SaltStack ensures that server configurations are enforced and maintained as defined, preventing drift.

Jenkins

An open source automation server, Jenkins plays a significant role in the continuous integration and continuous deployment, or CI/CD, pipeline. Jenkins helps to automate the various stages of the delivery pipeline, which is crucial in testing and deploying immutable infrastructures.

Ansible

While Ansible is generally associated with configuration management, it also excels in automated deployment. Because it doesn’t require agents on the servers it’s managing and uses a simple, human-readable YAML syntax, it’s useful for setting up and maintaining immutable servers.

Git

Git, a version control system, is essential for tracking changes in the configuration code, scripts and templates used to create and manage immutable infrastructure. It allows teams to manage their infrastructure-as-code, ensuring a detailed audit trail of what was changed, when and by whom.

Ultimately, a slew of tools and platforms are available to make the transition to immutable infrastructure as seamless as possible. From container orchestration with Kubernetes to configuration management through Ansible, you have a robust array of options at your disposal.

Yet, when it comes to handling specification files or any form of documentation, you want an added layer of security. A robust custom document viewer with extra security features, for instance, could be an invaluable asset in this regard, offering the ideal blend of accessibility and protection while ensuring that your infrastructure is immutable and secure from prying eyes.

Choosing the Right Tools For Your Organization

When integrating immutable infrastructure into your operations, selecting the right mix of tools that align with your specific requirements and existing workflows is crucial. Essential factors such as compatibility, scalability and ease of use should be considered to create a robust, efficient and effective immutable environment.

Each of the tools highlighted above has its own strengths and is a part of a broader ecosystem designed to support the reliable, consistent and secure deployment of applications and services across organizations of all sizes. Companies can fully embrace the immutable infrastructure model by learning how to properly harness these tools, improving stability, scalability and efficiency across all of their IT operations.

November 17, 2023
DevOps Halloween: Tricks and Treats

The world of DevOps is like a labyrinth—filled with choices at every turn. Some paths lead to efficiency and success, while others may lead to unexpected challenges and delays. In the spirit of Halloween, let’s explore the tricks and treats of DevOps choices to ensure your team ends up with a bag full of treats rather than some nasty tricks.

Version Control: Treats of Consistency, Tricks of Complexity

Treat: Implementing a robust version control system is crucial for any DevOps team. Tools like Git provide a reliable way to track changes, collaborate on code and maintain a history of your project’s evolution.

Trick: However, the complexity of these systems can lead to confusion and errors if not properly understood. Branching strategies, for instance, need to be clearly defined to avoid chaotic merges and lost work.

Continuous Integration & Continuous Deployment (CI/CD): Speedy Treats, Tricky Configurations

Treat: CI/CD pipelines automate the process of code integration, testing and deployment, speeding up release cycles and ensuring more reliable software.

Trick: Setting up these pipelines can be complex and error-prone. Misconfigurations can lead to failed builds, delayed releases or even the deployment of buggy code to production.

Containerization: The Sweetness of Isolation, Beware of the Overhead

Treat: Containers provide isolated environments for applications, ensuring consistency across development, testing and production. Tools like Docker and Kubernetes have revolutionized application development and deployment.

Trick: Containerization adds an additional layer of complexity to your infrastructure. Mismanagement of containers can lead to resource inefficiencies, and Kubernetes itself has a steep learning curve.

Monitoring and Logging: The Treat of Visibility, The Trick of Overload

Treat: Comprehensive monitoring and logging give teams visibility into system performance and behavior, enabling proactive issue resolution and performance optimization.

Trick: The sheer volume of logs and metrics can be overwhelming. Without proper tools and strategies for filtering and analysis, important information can be lost in the noise.

Infrastructure-as-Code (IaC): Sweet Automation, Sour Complexity

Treat: IaC tools like Terraform and AWS CloudFormation allow teams to automate and version infrastructure setup, ensuring consistency and reducing manual errors.

Trick: IaC scripts can become complex and difficult to maintain. Errors in these scripts can lead to misconfigured infrastructure, potential security issues and resource waste.

Collaboration and Communication: Treats of Teamwork, Tricks of Misunderstanding

Treat: DevOps emphasizes the importance of collaboration between development and operations teams, fostering a culture of shared responsibility and continuous improvement.

Trick: Miscommunication and lack of alignment between teams can lead to inefficiencies, mistakes and a breakdown in the collaborative process.

Security: The Unseen Specter

Treat: DevSecOps enables a “shift left” on security, integrating security checks and practices early in the development life cycle, ensuring safer, more secure applications.

Trick: But this integration requires continuous attention and maintenance. Outdated dependencies, misconfigured settings and inadequate security practices can leave your applications vulnerable, turning the unseen specter of security issues into a ghastly reality.

What about you? What areas of DevOps are ripe for trick or treat this Halloween season?

In the grand scheme, DevOps offers a treasure trove of benefits, from faster releases and improved collaboration to higher-quality software. However, it’s not without its challenges. Navigating the DevOps landscape requires a careful balance between embracing automation and maintaining control. By being aware of the potential tricks and focusing on the treats, teams can build efficient, reliable and scalable systems. Like a group of trick-or-treaters navigating the neighborhood on Halloween night, success in DevOps comes from preparation, collaboration and the ability to adapt to unexpected surprises. So, put on your costumes, grab your bags and get ready to collect those DevOps treats!

Image Source: Photo by Antonio Gabola on Unsplash

October 31, 2023