Louis Dussarps

While cloud services offer great flexibility in their usage and consumption, their growth has also led to an increase in the supply, with a multiplication of APIs, tools, and platforms to enhance, facilitate, and optimize access to cloud services. [1] This proliferation of offerings is one of the reasons that has led to the heterogeneity of cloud environments and the difficulty of their interoperability. [2]. It is now widely accepted that “cloud resource management, traditionally handled by system administrators, must now be automated to be efficient, secure, and dynamic.” [3]

From this perspective, Ops teams and developers must be supported by complex engineering platforms called Internal Developer Platforms. These platforms must ensure requirements for quality of service, security, and cloud cost, while also allowing administrators access for audit, customization, and modification purposes.

Databases follow the principle of transactions — a set of changes that must either all succeed or all fail. But when an application interacts with multiple databases or connects to various APIs (as is the case for most applications today), the guarantees of ACID are lost. Workflows, state machines, and the saga pattern help achieve a similar level of reliability, often at the cost of more complex code. Here, we introduce a Node.js framework that makes it easy to write such workflows in TypeScript.

To follow along, you can find the full source code in Orbit’s GitHub repository.

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.

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.

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.