In the early times of Infrastructure as Code (IaC) and along with Terraform ubiquity, Terraform Automation and Collaboration Software (TACOS) were introduced as a way to bring IaC under the same governance and collaborative workflows that we use for application code. I still remember building my first Jenkins IaC pipeline and how complex it was, and I was looking for tools of salvation.
However, as our cloud and DevOps landscape continuously changes we always need to re-examine our tools and methodologies to see if they stack up. This is compounded when we look at the entire ecosystem’s evolution, the momentum of other IaC tools, the introduction of more modern CI/CD and pipeline tools, as well as the changes Terraform itself has undergone –– from open source to source available, and its pending acquisition. These changes alongside a more widespread adoption of GitOps practices, enforcement of Policies as Code (PaC), and relevant tooling, and Governance as Code (GaC), which is also gaining momentum.
We started to witness that instead of solving a problem, TACOS actually create a problem. The fragmentation is too high. DevOps want one CI/CD pipeline. It’s hard to justify having a dedicated, fragile CI/CD system just for IaC –– that’s really yesterday’s practice.
As we move deeper into the cloud native era, the question arises: Are TACOS still relevant or are they becoming a burden to the modern DevOps stack?
Controversial option: Here is why and how I believe you should opt for your main CI/CD system to get everything that TACOS provide and more. Let’s dig in.
The Original Appeal of TACOS
When TACOS first came onto the scene, they offered a compelling proposition: streamline the deployment of IaC, integrate with existing tools and provide a dedicated pipeline for managing infrastructure. DevOps engineers were hungry for such a solution. For teams transitioning from manual provisioning to IaC, TACOS were a natural progression. They promised to reduce errors, increase visibility and improve collaboration between developers and operations.
The initial appeal of TACOS included several areas of friction:
- State management and version control
- Workflow automation and policy enforcement
- Collaboration and role management
- Scaling and performance considerations
While at the same time, these benefits also came with their own unique set of challenges. All this value essentially needed to be managed within a separate and disparate platform that adds layers of complexity, and maintenance overhead. TACOS often need to integrate with other tools and services in the DevOps ecosystem, such as cloud providers, secret management systems, and monitoring tools. Each integration point introduces potential complexities and requires careful management. The more tools you add to the mix, the more fragmented your infrastructure management can become.
However, as the DevOps landscape has matured, so have the tools that have been relied on daily for many decades, as well as the introduction of new tools that came in to address gaps in our processes and stacks. CI/CD platforms like Jenkins, GitHub Actions and Argo CD have evolved significantly to meet new and evolving needs and challenges. They now offer robust support for IaC, making the need for an additional dedicated IaC pipeline — what TACOS essentially provide — less obvious.
Are TACOS Still Relevant in the Modern DevOps Stack?
One of the critical selling points of TACOS is the dedicated IaC pipeline. TACOS were built to help automate workflows, such as plan and apply steps in Terraform, integrating them into a broader CI/CD process. They often include features for policy enforcement, where you can define rules that must be adhered to before infrastructure changes are applied. This might involve integrating with PaC frameworks like Open Policy Agent, ensuring that changes meet security and compliance standards before deployment.
But in practice, this can be a double-edged sword. Investing hundreds or even thousands of engineering hours to move from a well-established CI/CD pipeline like Jenkins or GitHub Actions to a TACOS solution can be costly and time-consuming. The fragmentation introduced by managing separate pipelines for application code and infrastructure can lead to increased complexity, both in terms of cloud architecture and organizational workflows.
- Increased fragmentation. You already have many tools, should you really add another one?
Aside from practical considerations, I will also argue, that alongside the benefits there are actually some downright dangers:
- A TACOS is essentially a single point of failure. If the TACOS is malfunctioning (don’t forget they’re also running on the cloud), you as a business can't deploy to your cloud either. Are you comfortable with your state files being hosted on another SaaS vendor?
- Security. The TACOS handles and has access to all of your secrets, sensitive data and keys. Are you OK with that too?
In addition, when issues arise, whether in your CI/CD pipeline or your TACOS-managed IaC pipeline, you end up managing them separately. This separation can lead to a disconnect between developers and infrastructure engineers, further complicating troubleshooting and collaboration.
The Case for Consolidation
Given the challenges associated with integrating TACOS into an existing CI/CD pipeline, it's worth asking: Why not improve your current CI/CD tools instead? Modern CI/CD platforms are more than capable of handling IaC workflows, and by consolidating these processes, you reduce complexity and improve efficiency.
In fact, enhancing your existing CI/CD pipelines to better support IaC allows you to connect easily with Policy as Code and Governance as Code initiatives. These integrations can provide a more holistic approach to managing infrastructure, without the need for an additional layer of tools. This was also the underlying premise we, at Firefly, kept in mind when building workflows in our platform. We don’t claim to be better than the industry DevOps tools engineers have grown to know and love. We wanted to make the experience of working with them easier.
The industry doesn’t need more tools, to be honest. We are in an age where the problem is not innovation, it's integration, management and maintenance (not to mention cost and efficiencies of scale). No single platform can do it all. What mostly happens is these become a jack of all trades and master of none.
Platforms need to integrate better with existing tools and empower engineers to improve the experience with their existing stacks. When we built workflows, we wanted platform and DevOps engineers to streamline their work with their CI/CD of choice –– whether GitHub Actions or Azure DevOps — not force them to work with a different and separate platform to gain benefits.
The cognitive load with managing the high-scale, many-dependency, event-driven, cloud fleets that power our world today is huge and can lead to costly mistakes. The CrowdStrike one is just the first that comes to mind. The more tools we can provide engineers to stay within their domain of expertise and existing platforms, will help simplify the complexity and overload.
Your Key to Simplifying the Cloud, Not Complicating It
As cloud environments grow increasingly complex, the last thing teams need is more systems to manage. The allure of TACOS lies in their specialized capabilities, but in many cases, these can be replicated, or even improved, by extending the capabilities of existing platforms. By doing so, you avoid the pitfalls of fragmentation and ensure that your DevOps stack remains cohesive, efficient and easier to manage.
While TACOS have played an important role in the evolution of Infrastructure as Code, their relevance in the modern DevOps stack is increasingly being questioned. The hidden costs of managing TACOS — whether it's the time spent on configuration, the challenges of integrating with existing tools, or the potential for fragmentation — can outweigh the benefits, particularly for organizations that already have robust CI/CD pipelines in place.
Rather than introducing another middleman, the focus should be on empowering your current platforms with the capabilities they need to handle IaC effectively. This approach not only simplifies cloud management but also brings developers and infrastructure engineers closer together, fostering a more collaborative and agile environment.