2 posts tagged with "AWS CDK"

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.

If you've ever tried to build a multi-account AWS architecture using CDK or CloudFormation, you've probably hit the same frustrating wall: cross-account resource references don't work without manual coordination and hardcoded values. What should be a simple task—like reading a parameter from Account A in a Lambda function deployed to Account B—becomes a tedious manual process. This behaviour is already documented and while AWS also documents workarounds, there’s no indication that this is going to change anytime soon. However, these approaches don't scale when you have multiple services and resources spanning different accounts across your organization.

This post walks through a practical example that demonstrates both the problem and a solution using orbits, a tool designed to seamless orchestrate all of your IaC with code.