Tom Marcuzzi

If most CI/CD tools today are robust, the way we define scripts in them comes with a few drawbacks:

• they have strong vendor lock-ins;
• they are difficult to test and debug locally;
• they all use a different syntax in YAML, which is difficult to extend and compose. For all these reasons, when the person who wrote them is not around, it’s not uncommon that teams don’t know what scripts do. They rarely evolve and their maintenance is hard.

Using code and native Node.js modules to write CI/CD could solve all these problems and comes with a lot of benefits:

• it’s possible to debug locally. To avoid regressions, it's even possible to test the CI/CD with a normal testing framework;
• it offers better reusability across projects and greater composability;
• it uses code instead of configuration, making it easy to catch errors, manage retries, loops, and conditional logic;
• it integrates seamlessly with the rich Node.js ecosystem.

Cdk8s is a great tool to write your Kubernetes IaC templates using standard programming languages. But unlike the AWS cdk, which is tightly integrated with CloudFormation to manage stack deployment, cdk8s has no native deployment mechanism.

By default, it allows you to synthesize manifests and deploy them using kubectl apply, or optionally through Helm. While both approaches can work, they often fall short for more advanced use cases — for example, when you want to programmatically chain deployments, export values from the chart, or implement a custom rollback and prune strategy.

In this blog post, we’ll explain how we built a model-driven orchestrator for cdk8s using Orbits — a lightweight framework for orchestrating cloud resources and workflows. We’ll show how you can use it, adapt it to your own needs, or even build your own orchestrator based on the same principles. If Orbits fits your use case, you can directly reuse what we’ve built.

Infra is code! At first glance, this slogan might be the most stupid one ever read for a long time — if not on the entire planet, then at least in the web sphere. Yes, infrastructure has always been code: from the Ubuntu web server to the Cockroach database, it is nothing but code controlled by code. But if the Ops field has progressively shifted towards the notion of Infrastructure as Code, it is precisely because there is a substantial difference: the DevOps domain is better formalized as a description of reproducible artifacts rather than as a prescription of successive commands to execute. Thus, boldly displaying this slogan Infra is code! on any article should make any somewhat experienced DevOps practitioner pause.