Show HN: Opta, a high level abstraction for Infrastructure-as-Code | Hacker News Reader

Show HN: Opta, a high level abstraction for Infrastructure-as-Code

github.com

I'm following a similar approach with Kubestack. Although for a much smaller use-case, being exclusively focused on building Kubernetes platforms using Terraform.

Your scope sounds more like Gruntwork. How would you say you differentiate?

For me the focus is important because the wider the use-case, the broader the customizations different orgs will require. Focus on a narrow use-case means one can provide more value.

Frameworks on the software development side also are better with a narrower use-case. There's no one size fits all.

Kubestack also has a UI to design your Kubernetes platform and export that to Terraform code. Making it super easy to get started.

https://www.kubestack.com/cloud

I've been evaluating Kubestack internally and I had just a couple questions. First of all, thank you for your work! I can't tell what the business case is. Is Kubestack something you're just passionate about offering totally for free to th community? Second, how does your ArgoCD module compare to the other popular one in the space? [1]

And finally, do you know of any users using Kubestack together with Terragrunt? I'm a big fan of Gruntwork's tooling. Given Kubestack is "just" Terraform, I don't see any reason why it wouldn't be compatible except when used together with the kbst CLI tool.

[1] https://registry.terraform.io/providers/oboukili/argocd/late...

Thanks for the kind words. I'm building Kubestack because I believe strongly that frameworks make sense for IaC too and that platform teams need a better DX if they are supposed to deliver a better DX to app teams.

I'm currently helping companies build their Kubernetes platforms using Kubestack. So that's the "business model" for now.

The modules in the catalog, like e.g. ArgoCD, differ from other modules in so far as that they are built automatically from upstream releases. I maintain the Kustomization Terraform provider, which allows integrating native K8s manifests into Terraform and have Kustomize patches, generators etc. available to customize the upstream manifests. The Kustomize overlays can be defined in Terraform through the provider/modules and as a result you can use values from Terraform to configure the K8s manifests without maintaining K8s YAMl in HCL.

More details here: https://www.kubestack.com/framework/documentation/cluster-se...

Regarding Terragrunt I'm not 100% sure. Last time I checked they maintained different environments in different directories and then the CLI copies/symlinks/whatever that into a configuration before it runs Terraform. Kubestack however does use Terraform workspaces (in the TF CLI, not TF Cloud sense) for that purpose. There is just one code base. And modules have inheritance based configuration per environment. I'm not sure how well Terragrunt works with Terraform workspaces. If it does, then it should with Kubestack too.

Edit: added the Terragrunt answer.

How does this differ from a set of Terraform modules?

A quick glance at the docs don't seem to make it obvious other than the custom CLI.

(Opta's lead maintainer here)

Hey! That's a good question and something we need to document better. In short, Opta is a framework to build opinionated TF modules that work well together (and a CLI to deliver those modules to non-experts). A wide set of modules have been built by our team but it is very customizable and we expect folks to add their own or augment the existing ones with custom TF code.

Additionally, we augment vanilla TF modules with a variety of things that improve the scalability of a TF codebase - stuff like pre/post hooks, abstraction for creating environments and services, "better" state management, etc.

Reply on news.ycombinator.com