> How do you envision the DevEx for managing in...
# platform-blueprints
h
How do you envision the DevEx for managing infrastructure resources and other dependencies?
Everybody talks about infrastructure as code, so that's definitely what I would see for us. Currently we have AWS resources (CloudFormation) and Kubernetes manifests as YAML in the same repo as the application code. We do not use Helm or any advanced templating (just Mustache). Changes are applied via CI/CD when deploying a new version (CloudFormation update, kubectl "apply"). Some teams already use AWS CDK and I can foresee us adopting something higher-level (than YAML) going forward. There are some trade-offs between what is possible to customize locally vs. how to allow central changes across 200 teams. YAML is not so bad right now as we do automated PRs to change certain things as needed (e.g. Kubernetes API version updates needing changes). Full "code" can make this harder to achieve (interpreting turing-complete code from automated tools). We definitely strive to increase leverage, i.e. remove toil from engineers and move to centrally provided services incl. updates etc.
b
When you say, “Something higher level than a YAML” Could be something like Pulumi?
Or are you just removing the need for application engineers to understanding IaC?
h
Yes, for "something higher level than YAML" I refer to any abstraction, advanced templating or generation logic/code (Jsonnet, Pulumi, CDK, ..). We follow "you build it, you run it" so engineering teams need to have some understanding of infrastructure (e.g. configure managed cloud services), but we want to remove toil so it's a trade-off on what to expose (easy things should be easy, hard things should be possible).
1
b
Nice!