People involved in long standing feuds tend to forget why they started fighting in the first place. The current multi-cloud feud is not about Hatfield’s AWS vs McCoy’s Azure. It’s really a battle over IT’s mortal enemy: sprawl. Inevitably, sprawl will grow when you manage multiple infrastructures, but that’s not just because you choose to use more than one cloud. Sprawl includes your tool choices, operating systems, programming languages and CI/CD pipelines. The question becomes how can you un-sprawl multi-cloud operations?
Scaling in spite of multi-cloud sprawl
One thing is for sure, sprawl creates complexity and fragility. But we just said that sprawl is inevitable, especially if you are managing multiple infrastructures (aka multi-cloud). So how can we scale and grow?
The answer is to add a layer of orchestration. Orchestration makes it possible to coordinate actions between tools with simple if-then-do-that rules. With an orchestration abstraction, it is possible to take events from one system and pump them into a tool of choice. Then voila! You have a simple way for everyone to use their tool of choice! Problem solved!
Except now, we have orchestrator sprawl too.
TACO sprawl
The explosion of Terraform Orchestrators (aka TACOs) demonstrates the point. As Terraform began to be adopted by individuals and teams in isolation, there was a clear need for platforms that could coordinate, consolidate and store all of the plans that were created. A fleet of projects and products swiftly followed to fill the gap. Now we have a new feud around picking the best of these new Terraform Orchestrators.
It became easier to coordinate Terraform operation, but that didn’t address either the broader organizational or adjacent tooling coordination problems. And once you start talking about a multi-cloud environment, the sprawl starts to be painful.
What is wrong with TACOs?
With tool focused silos, many got too wrapped up building a Terraform orchestrator instead of an Orchestrator that can run Terraform. And this didn’t happen only with Terraform. The same thing happened with orchestrators that focus on configuration (e.g.: Ansible), containers (e.g.: Kubernetes), or code (e.g.: Gitlab). This distinction is important because in a multi-cloud, multi-tool, multi-everything world, single tool orchestrators automatically create the need for the dreaded orchestrator of orchestrators. Single tool orchestration is fundamentally fragile, but orchestration is the key to having the flexibility to respond and adapt.
So RackN built an IaC Orchestrator that can run Terraform
RackN focused on building an infrastructure as code-based orchestration and pipelining capability at the center of our architecture instead of building around a specific tool or infrastructure type. After years of working with customers’ operations teams, we know that heterogeneous systems are the norm. Furthermore, teams will be required to support many tools as well as multiple generations of platforms.
After all, the purpose of building a platform is for to disappear so that teams can focus on their own jobs.
You may not be able to eliminate sprawl, but you can smooth the effort to interconnect your every expanding infrastructure, operating system and tools environment. Visit RackN.com/IaC101 to see how Digital Rebar IaC pipelines and orchestration help you combat sprawl in your own environments.
