)
)
Look beyond the blog title and image; this article isn't about the delicious handheld treat wrapped in a corn tortilla, courtesy of our Mexican friends. The debate may swirl around corn versus flour tortillas, cheese choices, and the quest for the ultimate Texas taco spot (San Antonio, for the win—sorry, Austin!).
TACOS lost its way by solving a Terraform or IaC problem rather than solving the Developer Experience, Practitioner pain point, or business problem. This blog attempts to navigate the TACOS revolution while pinpointing the mishaps and where TACOS missed the point entirely!
Infrastructure and applications teams wanted to manage their Infrastructure of Code using the same principles and precepts as application code.
Which TACOS am I referring to, precisely?
TACOS, short for Terraform Automation and Collaboration Software, provides a robust framework for efficiently managing and operating Terraform codebases. Since 2020, if not earlier, it has been a critical player in shaping the conversation around Infrastructure as Code.
Converged Paths: DevOps and “Modern” IaC
Though TACOS is credited with starting this trend, a closer examination of its roots shows that it originates from the early days of the DevOps movement, influenced by the widely-used open-source tool Terraform.
DevOps
The DevOps movement emerged in the late 2000s, founded on the principles outlined as follows:
- Agile Methodologies
- Continuous Integration and Delivery (CI/CD)
- Git Repositories and Workflows
- Incident Management
- IT Service Management
Infrastructure as Code
As Kat Cosgrove stated in an article written in 2023, “If you look at the history of computing, configuration management tools have been around since the 1970s. How did we get from make files to Terraform configuration?” Review the article to truly understand the rich and deep history of Infrastructure as Code. Let's start with the most popular tool to ensure that we focus on the “Modern” inception of IaC.
Terraform circa 2014
Terraform is an infrastructure-as-code software tool created by HashiCorp. Users define and provision infrastructure using a declarative configuration language called HashiCorp Configuration Language (HCL). I recall my first use and consumption of Terraform from my local Macbook, and I was amazed at how easy it was to provision resources on VMware and AWS without much effort.
Terraform solved the mundane tasks of provisioning workloads, but it became apparent that it had limitations. Whether you call them shortcomings, limitations, etc., or out of scope, the community quickly realized a need for improvement.
Let's review the OSS alternatives built to address these shortcomings to help articulate the enhancements made by the community, focusing on DevOps principles and precepts.
Terragrunt circa 2016
Terragrunt is a thin wrapper that provides extra tools that focus on the following:
- Keep Terraform configurations DRY
- Working with multiple Terraform modules
- Managing remote state
Seriously, the ability to provision an environment from code via Terraform was transformative, but who manages a single environment anyway? While Terragrunt often gets the most attention for keeping Terraform Code DRY, we should thank the project for Remote State Management.
Atlantis circa 2018
Atlantis was introduced to automate Terraform via pull requests with a focus on the following:
- Enable collaboration
- Enhance Pull Request Reviews
- Standardize workflows
Atlantis did more to bring DevOps principles and practices closer to DevOps than any other project.
Pulumi circa 2018
Pulumi took a different approach from the previously mentioned OSS projects and Terraform by going in a completely different direction. Rather than build on top of Terraform, Pulumi introduces its concept of building IaC in the language of your choice. All while attempting to solve some of the shortcomings that Terragrunt and Atlantis, respectively, tried to tackle.
Pulumi should be commended for their influence and work, but until recently, a big thank you to BSL; Pulumi was always the second or third choice for IaC.
The chart below helps articulate where each OSS addition helped bring IaC and DevOps together, maybe not completely, but at least enhancements.
The TACOS Generation
The idea of building SaaS capabilities on top of Terraform started in 2019 with Hashicorp introducing Terraform Cloud Remote State Management. While I wouldn’t consider the first iteration a TACOS platform, it helps launch the idea that Terraform was insufficient.
Terraform Cloud circa 2019
Terraform Cloud was introduced with significant fanfare with the following capabilities:
- Automation
- VCS Connections
- Remote Plan and Apply
- Notifications/Webhooks
- Collaboration
- State Management
- Private Module Registry
- Collaborative Runs
This is where TACOS started to go wrong, but I don’t think we saw it then!
Let me use Hashicorps own words and capabilities to help illustrate my point:
“Terraform Cloud is a SaaS application that brings free collaboration features to individual users and teams with additional paid feature sets that provide team management, self-service infrastructure, and governance features.”
Terraform Cloud was introduced to solve a Terraform problem, not an IaC, DevOps, or Application Development problem.
There was never a desire to get to the root of the problem, the development, operations, or management experience!
The Purpose Built CI/CD for IaC
The next iteration of TACOS started in 2020 with new and improved capabilities that continued to solve the Terraform problem with a stronger focus on DevOps, Developer Experiences, etc. Organizations like Env0, Spacelift, and Scalr took the “best” of Terraform, Terrarunt, Atlantis, and Terraform Cloud to build the next generation of TACOS solutions.
The problem statement was clear, and each organization decided to build a niche CI/CD solution for IaC. On the surface, it checks all the boxes.
- DevOps
- Terraform Automation and Collaboration
TACOS providers believed they were bringing IaC and DevOps together while enhancing or integrating the Terragrunt and Atlantis capabilities into a single solution. TACOS solutions validated the dominance of Terraform in the market while Pulumi remained relevant, but popularity and usage told a different story.
The Kubernetes Alternative
During the rise of the TACOS solutions, Crossplane (and Upbound) attempted to shift everyone's focus away from Terraform as the foundation or starting point for delivering Infrastructure as Code. Crossplane checked all the DevOps boxes. What better place to start than Kubernetes? I am not here to debate the significance of Kubernetes because that would be a futile effort. Kubernetes has solidified its place as the best orchestrator for containers.
Crossplane would deliver CI/CD for infrastructure with the help of the thriving tooling market backed by the CNCF, which includes all of the DevOps-centric requirements and capabilities to genuinely free developers from HCL, Terraform, etc. But was Kubernetes the best foundation to build upon? It turns out it wasn’t, thanks to the limitations of CRDs, the ecosystem tooling, and a general lack of belief in the community that it was a better alternative to Terraform.
Crossplane attempted to solve the Terraform problem by being the tooling replacement. However, the limitations in Kubernetes and the ecosystem highlighted that while the intentions were good, the execution and capabilities needed to be improved. Crossplane solidified this by introducing a Terraform provider. That should make you laugh at least a little.
Maybe the issue isn’t the specific tooling itself but the foundation on which they were started.
What did TACOS get right?
- Terraform is the best tool to deliver infrastructure as code
- Automation and Collaboration helped further advance the cause of IaC
- Drift Detection
- This should have been in place from the beginning
- Security and Governance
- Supporting additional IaC frameworks makes sense
- Pulumi, AWS CloudFormation, CDK, ARM Templates, and others are supported in some capacity
What did TACOS (and alternatives) get wrong?
- Purpose Built CI/CD
- Refactor existing code for future use
I know! Some of you immediately defend the above-mentioned points, but let's look at each more closely. Before we do, please put on the DevOps principles and practices that help us because that is where this should have started.
DevOps is a methodology used in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) to improve and shorten the systems development life cycle.
Below are some of the thoughts, comments, and concerns that can be said about the purpose-built CI/CD providers in the space since their inception, which still ring true today.
- Continuous Integration
- VCS, need I say more.
- GitOps, love it
- Another tool when we already have others
- Continuous Delivery
- Build, test, and prepare for a release
- Another tool when we already have others
- Configuration Management
- IaC + Drift Detection, game-changing
- State Management is close
- Policy as Code
- It seems legit, but “Security” still feels a bit out of the loop or at least not wholly integrated
- Monitoring and Logging
- Monitoring and logging are present but only for the IaC layer; what about the rest of the pieces and parts of the application
- Communication and Collaboration
- Yes, but in a silo
- Collaboration is present but lacking when moving beyond IaC across the other areas of the SLDC
I loved TACOS because of the original promise, but continuous improvement for IaC has become stale.
The next phase of TACOS may be something other than TACOS!
We are at an exciting point in the IaC journey that needs serious discussion.
- Was a purpose-built CI/CD the best path?
- Have we reached the peak integration with the original TACOS design?
- Where do AI, LLM, and ChatGPT fit into this space?
- What will it take to expand IaC to the entire development organization?
- What needs to be done to include Security more seamlessly?
- What else can be done to ensure Infrastructure as Code feels the same as Application Code?
If TACOS solutions aren’t the answer, what is? Be honest, your first thought is an Internal Developer Platform (IDP), right? However, we have already articulated the issues with Kubernetes as the focal point. 😜Not every application and service runs on Kubernetes anyway. And why does an IDP have to be solely focused on Kubernetes anyway? Maybe the answer lies somewhere in between all of this!
These questions are precisely what Terramate is trying to answer. And no, we do not have all the answers, but we listen to our customers, community members, and practitioners keenly to help them solve these difficult questions. Join our community, reach out on social media, and set up some time to talk with us about what you believe the next step of your IaC, TACOS, and IDP journey is.