7 ms·
I think the best solution is K8s and some tool to help you generate the yaml files. Terraform, CDK, and Pulumi all work similarly. At the end of the day, you d
by ahzhou 5y ago
I think the best solution is K8s and some tool to help you generate the yaml files.
Terraform, CDK, and Pulumi all work similarly. At the end of the day, you declare a DAG that says how you want your infrastructure to work and use that DAG to come up with a list of changes you should make. Then you execute each of those changes via API calls and hope that reality on your cloud provider really does reflect the state DAG that you've built. CDK is better than the rest here, because it's got the best ability to measure the state.
When you work with K8s, on the other hand, you tell your infrastructure what shape it should be in with yaml files and then let your infrastructure figure out the best way to get there. When combined with something like ArgoCD, you've got a really powerful deployment stack.
The obvious downside is you've got to figure out how to get that all working.
- orf 5y agoWhat does “measure the state” mean?
- pid-1 5y agoI really didn't understand the state thing nor how CDK and Terraform aren't declarative. That said, I like how K8s + YAML allows a more "self service" like approach to IaC. In my org the goal of our devops team is to specify some common patterns for applications, then allow devs to use themselves. Both CDK and TF are really bad dealing with several apps spread over different repos that share resources (e.g.: ECS Clusters, VPCs, etc...).
- tmerse 5y agoBoth CDK and TF are really bad dealing with several apps spread over different repos that share resources (e.g.: ECS Clusters, VPCs, etc...). I had good experience by going a submodule route. One multirepo containing a CDK infra submodule and multiple repositories as submodules which each output resources (lambda code, etc.) which in turn can be imported more easily by cdk.
- jpgvm 5y agok8s is fundamentally just a much better API. YAML on the other hand is awful so I recommend Jsonnet instead to generate the k8s manifests. I currently use Tanka for this.
- bleepblooop 5y ago"let the tool figure out how best to get there" doesn't really sound any different than the concept of the other systems you were describing. It sounds like the difference is largely just some implementation details: rather than a one-shot run through a DAG which will abort out if anything doesn't match the plan, I assume the kubernetes approach will just keep retrying until it converges, as if you were running "terraform apply" in a loop constantly until it tells you there are no changes left to make. Is there something about the kubernetes approach that differs in capability rather than just implementation approach? These underlying APIs are always fallible so I don't really see how you can get away from some sort of converging process where total convergence (without errors) might not actually be possible until you change the configuration.