Item — HN Reader

We have a moderately complex set of services we deploy with some separation of application code and infrastructure. No application code that runs on VMs is deployed as part of the infrastructure IaC - that’s all loaded once the “empty” infra is in place. The grey area is around non-VM compute like Lambda and Step Functions, which can be a part of the infra templates.

The way these services work requires an initial set of code to create the resources, and while it would be possible to send a “no-op” payload for the infrastructure deployment and then update it with real application code later, that seems pedantic (to us).

Maybe someday that changes, but for now it isn’t at all burdensome and we’ve been very successful with this approach.

2 comments

Yeah, we've solidified that the day-0 path of deploying an empty image or no-op code deploy when first provisioning a service is the way to go and then letting CI/CD pick up the actual deployments longterm. I can see the "this seems pedantic" POV, but this is what we've found works across a number of cloud native services and accomplishes the end goal of managing infra with IaC and deploying with whatever tool we want for the application layer.

We have a similar array of deployment targets and the method is context dependent. The Kubernetes declarative manifests and reconciliation loop for applications is winning out, for our devs and industry at large. The cloud funcs / lambda are an annoying corner case, we do that with a late step in CI/CD currently, with a move to a dedicated Argo setup just for CD (workflows, not CD because that only does helm well)