*Cross posted from my blog https://davidjeddy.com.
Disclaimer: Before we dive into my reasoning against Terraform let me state this: I personally think it is an amazing tool that has enabled organizations of all sizes stay competitive in the modern ultra-high velocity market of today's world. That being said not considering the down sides of a tool / process / methodology is destructive and detrimental to everyone.
Terraform, the Infrastructure as Code (IaC) offering from Hashicorp, touts itself as having 'one safe workflow across providers' and being 'simple and powerful'. The community around Terraform even adds the claim that Terraform prevents vendor locking (that is, getting stuck with a single provider for a service). Searching Google for the phrase 'Terraform prevent vendor lock in' and you will see over 64000 results. Seems to be a pretty popular topic!
While I like Terraform, using it to prevent vendor lock in is bullshit; The belief of preventing vendor lock in is a false promise of freedom framed by a non-issue. You are already locked in: Windows, OSX, Li/Unix; iOS, Android; On-Prem, Cloud; .NET, Java, OSS; AWS, GCP, Azure , OpenStack. The moment you chose a provider you are locked into that provider without a level of effort to migrate to another provider.
I head you '...but with Terraform you just change providers and you are good to go...'. O really? GCP has t2.micro instances with the same network and root volume throughput? Azure has the same networking as AWS? AWS has the same read access times to long term storage as GCP? No, no they do not. The current cloud providers, while offering some of the same basic level of services do not provide enough overlap that flipping a value in a configuration file allows an environment to be migrated.
The strength of cloud service providers is not in the general offerings, but in the niche offerings. Leveraging the niche specializations in a manner that is holistic to the service your organization offers should be the goal. Yes, you can, and should, use ALL the providers when and where it makes sense. Leverage GCP for AI, Azure for virtual desktops, AWS for storage and BI data analytics. Picking one provider does not mean you are limited to only them. If your IT dept. says otherwise someone has some other motive for not embracing the mindset of 'right tool for the right job'.
At this point it has to be pointed out that yes, using multi-cloud is complicated. Lots of networking, compute calculations, bottle-necks to be aware of, pricing schemes, recovery processes, etc, etc, etc... I fail to see how this is any different than the monolith-to-micro-service shift the software industry recently went through. Applications are already breaking down into smaller and smaller parts. To the point where all 3 major providers have FaaS (functions as a Service) offerings. At this point every function basically points to a URI now so that URI be hosted on another cloud provider is transparent to the application and the end user. Configuration stays in the IaC files, secrets in a secret manager, and deployments merged into the CI/CD process you already have.
In summation; the notion that a magic bullet solution exists that with save you from your future self is bu****it. The fear of your future self / business situation is leveraged against you in a drive to enable on-boarding. Look past the hype, past the slick marketing ploys, past the exuberant presentations. Vendor lock does, and will always, exist. Leverage the specialized offerings from all the vendors; even if it means missing out on the 'cool new toys' of today. We all know how fast computing changes.
Top comments (6)
The argument of an infrastructure-as-code solution preventing cloud vendor lock in is the same as Hibernate (or similar) preventing you from having DB lock in. Fallacy, as you have so many other issues and factors for cloud/db change that the provisioning/querying code is such a tip-of-the-iceberg....
I think it's not that you need (or don't need) Vault - it's just you need a solution to externalize secrets from the codebase in a secure manner.
Preventing vendor lock-in comes in two places:
To prevent that an out of the box approach is needed and first become with a good design. For example when you start with terraform you should logically separate the modules that are tied for each infrastructure provider, aws, gcloud or azure so that in case you want to change infrastructure you can import different modules in the live server deployment modules.
Ideally, the live server environments should not have internal knowledge of AWS or Gcloud but see them as black boxes.
Very much agreed. One of the best practices with IaC is the decoupling of the hardware running an application and the application services itself. If you have resources available I could use to help exemplify this decoupling I would love to share them.
On the point of frameworks, they are all opinionated. Using services with no alternatives; I agree. The business would have to make the decision between 'do we use the new hotness with no alternative' or 'do we hold off till we have choices to fall back to'. Either way, the conversation has to be started.
What do you think? Would you use a service that has not alternatives?
I’m running Kubernetes (ultimate cloud agnostic solution) on GCP + Terraform... still suffering from vendor lock-in. I agree, It’s a total pipe dream.
So very, very true.
This is true because they don't design to anticipate the change in infrastructure or the existing tooling is unknown to them or they don't know how to use it.