add iac blog post #51
Conversation
| While Pulumi is a serious contender in the IaC arena, it might not be all sunshine and rainbows: | ||
| - Pulumi uses Terraform providers as a fallback, meaning it often has the same limitations as Terraform. | ||
| - Pulumi only allows you to save a change plan (e.g. for review with a different tool) when using `PULUMI_EXPERIMENTAL=true`, implying that the feature is not yet stable. | ||
| This is in stark contrast to Terraform, where a plethora of tools on the basis of just planfiles, e.g. Infracost and Checkov. |
| - Pulumi uses Terraform providers as a fallback, meaning it often has the same limitations as Terraform. | ||
| - Pulumi only allows you to save a change plan (e.g. for review with a different tool) when using `PULUMI_EXPERIMENTAL=true`, implying that the feature is not yet stable. | ||
| This is in stark contrast to Terraform, where a plethora of tools on the basis of just planfiles, e.g. Infracost and Checkov. | ||
| - Pulumi's language flexibility, while theoretically being interoperable, causes its plugin ecosystem to be split across multiple languages. |
There was a problem hiding this comment.
Are there really features I can only use in certain programming languages?
| {{< img src="/images/iac-in-2024/1_terraform.png" alt="Terraform Architecture" >}} | ||
| {{< /figure >}} | ||
|
|
||
| Terraform tracks information about Terraform-managed infrastructure in a statefile. Developers configure resources using the Hashicorp Configuration Language (HCL) DSL, which Terraform tries to apply to the real world based on definitions provided by providers. |
There was a problem hiding this comment.
I think you should explain that HCL is purely a descriptive language almost free of imperative statements. Often imperative statements have to be defined through resources, which limits its usability for complexer state-machine like resource configurations.
| ## Cloud Development Kit for Terraform (CDKTF) | ||
|
|
||
|
|
||
| Moving to an entirely different IaC tool (with its own ecosystem and peculiarities) can be quite a large step. |
There was a problem hiding this comment.
I'd remove the braces.
| Moving to an entirely different IaC tool (with its own ecosystem and peculiarities) can be quite a large step. | |
| Moving to an entirely different IaC tool tends to be major undertaking, especially once yo consider the individual ecosystems and peculiarities. |
|
|
||
|
|
||
| Moving to an entirely different IaC tool (with its own ecosystem and peculiarities) can be quite a large step. | ||
| If the benefits of general-purpose languages are too tempting to ignore, but Pulumi is too heavy, then the Cloud Development Kit for Terraform (CDKTF) might be worth checking out. |
There was a problem hiding this comment.
You did not say anything about Pulumi being heavy before. What do you mean? Explain it.
And then explain why CDKTF is less heavy.
| {{< img src="/images/iac-in-2024/4_crossplane.png" alt="Crossplane Architecture" >}} | ||
| {{< /figure >}} | ||
|
|
||
| Just like other IaC solutions, Crossplane allows a platform team to define their own abstraction layers around sets of infrastructure resources, and to then have developers interact with those abstraction layers. |
There was a problem hiding this comment.
Last time we looked at crossplane it had absurd limitations:
No optional resources / if-statements. No remote_state like in terraform so you could not base off your db-server from a network module provided in another composition. I think these need to be validated and documented.
| Just like other IaC solutions, Crossplane allows a platform team to define their own abstraction layers around sets of infrastructure resources, and to then have developers interact with those abstraction layers. | ||
| However, Crossplane uses Kubernetes as its backend. | ||
|
|
||
| Crossplane works by having developers create and modify instances of Crossplane resource definitions (defined by platform teams) in a given Kubernetes cluster, which the Crossplane controller then synchronizes with the outside world. |
There was a problem hiding this comment.
I think one of the main advantages is to incorporate resouces in a helm chart and have infra config together with your app config, enabling a unified gitops approach.
| As with Pulumi and the CDKTF, vendor-specific flavors of Kubernetes-based infrastructure controllers also exist. | ||
| These are Google's Config Controller, the AWS Controllers for Kubernetes (ACK), and Microsoft's Azure Service Operator. | ||
|
|
||
| Crossplane distances itself from these competitors with its support for the compositions of resources, rather than having lone resources that are only a shallow representation of underlying Azure/AWS/Google cloud resources. |
There was a problem hiding this comment.
I guess you could hint that compositions have to be build through a package manager like helm?
| - [Winglang](https://github.com/winglang/wing) (a new language) and [Microsoft Radius](https://github.com/radius-project/radius) (a new data structure) both try to be an integrated orchestration platform. | ||
|
|
||
|
|
||
| ## One More Thing |
There was a problem hiding this comment.
That is super random. Maybe make this another article and/or post it internally?
| categories: [] | ||
| tags: ["IaC", "terraform", "infrastructure", "devops"] | ||
| draft: true | ||
| summary: It's 2024 and you're STILL using Terraform. It might be time for a switch. |
There was a problem hiding this comment.
I think the article highlights technologies with very differing depths. Also I think a lot of comparison towards terraform is missing. Why might a certain solution be a better tool in which situation?
I would add a sentence in each tool section: Use this tool IFF...
Also I think Terraforms strengths are not very well explained. I think it is worth mentioning that this is still the most common default, the strongest ecosystem (providers AND modules) and the biggest hiring pool, lowest complexity of all solutions.
But it has weaknesses and there you should compare them to the other tools. Example: complex conditionals are hard, slow development speed, licensing issues, fragmentation through tofu...
Also I think you should give a statement if we should continue using terraform.
| {{< /figure >}} | ||
|
|
||
| Just like other IaC solutions, Crossplane allows a platform team to define their own abstraction layers around sets of infrastructure resources, and to then have developers interact with those abstraction layers. | ||
| However, Crossplane uses Kubernetes as its backend. |
There was a problem hiding this comment.
This, to me, is in fact a huge difference and might be worth elaborating in one or two more sentences. "Using Kubernetes as its backend" also means that the controller has to run continuously in a cluster, which - unlike purely CLI-based tools - means that it will appear in your cloud cost bill at the end of the month. Of course, this is an insignificant sum for most projects, but if you're in a smaller project and you might not even be using Kubernetes, this may actually be a factor.
| However, Crossplane uses Kubernetes as its backend. | ||
|
|
||
| Crossplane works by having developers create and modify instances of Crossplane resource definitions (defined by platform teams) in a given Kubernetes cluster, which the Crossplane controller then synchronizes with the outside world. | ||
| This does require you to have a good relationship with YAML. |
There was a problem hiding this comment.
I'm not sure what you want to say here. Is it just about Crossplane resource definitions being written in yaml (which is arguably a noteable advantage over Terraform because when you do "something with cloud" you're probably quite familiar with yamls anyway and you'll only see HCL in HashiCorp products)? Is it a joking remark that Crossplane requires a lot of yamls (then maybe reformulate it)? Or is it something entirely else?
No description provided.