DEV Community: Anil Jaiswal

GitOps at Scale: What Breaks at 200 Repos and 40 Teams

Anil Jaiswal — Mon, 27 Jul 2026 05:11:54 +0000

Originally published on aniljaiswal.com.

The GitOps demo is gorgeous. One repo, one app, one cluster. You change a value in Git. A few seconds later, the cluster changes to match. Production is a commit hash. Rollback is a git revert. Everyone in the room nods, and you roll it out.

Two years later, you have 200 repos, 40 teams, and four environments. The beautiful model is groaning. The ArgoCD controller is pegged. Someone hotfixed prod with kubectl three weeks ago, and nobody noticed until the next deploy quietly reverted it. A team deployed into another team's namespace by accident. Promoting a change from staging to prod means copy-pasting YAML between folders and praying. And every change, even a one-line config bump, is now a pull request waiting on a review.

None of this means GitOps was the wrong call. It means GitOps is a distributed system like any other. The simple setup that works for one team does not survive forty. The principles hold. The shape has to change. Here is what breaks as you scale, roughly in the order it bites, and how to fix each part.

The control plane melts before you notice

The first thing to break is the least interesting and the most disruptive. The controller runs out of headroom. ArgoCD, Flux, whichever you run, is a reconciliation engine. It constantly compares the desired state in Git against the live state in the cluster, for every resource it manages. At one app, that is nothing. At a few thousand apps across dozens of clusters, that loop is real, steady work, and the default single-instance setup buckles.

The symptoms are sneaky, because they are not outages. Syncs get slow. A change you merged takes ten minutes to land instead of ten seconds. The UI times out. Reconciliation falls behind, and the gap between merged and deployed stretches. People stop trusting that Git is the source of truth, and that quietly kills the whole idea.

The fixes are operational, and you want them in early, before the melt. Shard the application controller across replicas, so the load spreads across clusters instead of hammering one process. Turn off polling and drive syncs with webhooks, so a push triggers reconciliation right away instead of the controller re-listing every repo on a timer. And raise the reconciliation interval for things that rarely change. Re-diffing a stable app every three minutes is pure waste at scale.

# argocd-cmd-params-cm: spread controller load and stop re-listing everything constantly
data:
  # Shard the application controller across replicas (one shard per N clusters)
  controller.sharding.algorithm: round-robin
  # Back off the default reconciliation timer; webhooks handle the urgent path
  timeout.reconciliation: 300s

The deeper point is simple. Your GitOps controller is production infrastructure. It has capacity limits, and it needs the same monitoring as anything else you run. Alert on reconciliation lag and sync latency before your engineers notice. When they notice, it is by losing faith that Git reflects reality.

It is worth saying plainly, because this is the failure that erodes everything else. The whole value of GitOps rests on one belief: what is in Git is what is running. The first time a merge takes fifteen minutes to land, or a sync fails silently and nobody is paged, that belief cracks. Once it cracks, engineers start checking the cluster directly instead of trusting Git. And the moment they do that, you have all the ceremony of GitOps and none of the guarantee. Controller health is not a nicety at scale. It is what keeps the source of truth actually true.

Registering 200 apps by hand does not work

The second thing to break is the idea that someone declares each application by hand. In the demo, you write one Application manifest pointing at one repo. At 200 repos, times four environments, hand-maintaining 200-plus manifests is a full-time job nobody wants and everybody gets wrong.

The fix is to generate applications, not declare them. ArgoCD's ApplicationSet does this. You describe a pattern once, point a generator at your set of repos, teams, or clusters, and it produces the Application objects for you. A new service shows up, matches the pattern, and gets deployed. No human edits a registry.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: team-services
spec:
  generators:
    - git:
        repoURL: https://git.corp.local/platform/service-catalog
        revision: main
        # Each service drops a config.json under its own directory; the
        # generator turns every match into an Application automatically.
        directories:
          - path: "services/*"
  template:
    metadata:
      name: "{{path.basename}}"
    spec:
      project: "{{path.basename}}"
      source:
        repoURL: "https://git.corp.local/{{path.basename}}"
        targetRevision: main
        path: deploy/overlays/prod
      destination:
        server: https://kubernetes.default.svc
        namespace: "{{path.basename}}"
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

The shift is from registering apps one by one to describing how apps map to the platform. That is the difference between onboarding a new service in a day and onboarding it through a ticket queue. Ask why platform teams fail to get adoption, and half the answer is that onboarding was manual and slow. ApplicationSets are how you make it automatic.

Drift, and the question of who wins

The third thing to break is the assumption that Git is the only thing changing the cluster. It is not. Someone will kubectl edit a production resource during an incident, because it is 2 a.m. and that is faster than a PR. Someone will scale a deployment by hand. An operator will mutate something. Now live state and Git disagree, and the whole model hinges on what happens next.

There are two choices, and you have to pick on purpose. With self-heal on, the controller treats Git as absolute. It reverts any live change that does not match, right away. That is the pure GitOps promise. It is also how you erase the 2 a.m. hotfix that was keeping prod alive, ten minutes later, silently, because someone merged an unrelated change and triggered a sync. With self-heal off, drift is detected and shown but not corrected. The human hotfix survives. But now your cluster can quietly drift from Git and stay that way, which chips away at the source-of-truth guarantee.

Most mature setups land on self-heal on, plus making the emergency path go through Git so there is nothing to erase. If the 2 a.m. fix is a one-line commit to a fast-tracked branch instead of a kubectl edit, self-heal is your friend, not your enemy. The fix is now the desired state. The hard part is not the config, it is the culture. You have to make the Git path fast enough that engineers actually use it under pressure. And you have to alert on drift loudly, so when someone does bypass it, everyone knows at once instead of finding out at the next sync.

# Detect drift everywhere; auto-correct deliberately. Notifications make
# a bypass visible instead of silent.
syncPolicy:
  automated:
    selfHeal: true      # Git wins, so the emergency path must go through Git
    prune: true
  syncOptions:
    - RespectIgnoreDifferences=true

Secrets do not go in Git, but the reference to them does

The fourth thing to break is obvious in hindsight and still catches teams. GitOps wants all desired state in Git, and you cannot put secrets in Git. A plaintext database password in a company repo is a breach waiting for an audit to find it.

The fix is that Git holds a reference to a secret, never the secret itself. Two patterns dominate. Sealed Secrets encrypts the secret so the ciphertext is safe to commit, and only the in-cluster controller can decrypt it. The External Secrets Operator goes further. It keeps the real secret in a proper secrets manager, and Git holds only a pointer to where the value lives. That is the cleaner model at scale, because your secrets sit in one system with rotation and access control, instead of scattered as sealed blobs across repos.

# Git holds the pointer. The value lives in the secrets manager and is
# pulled into the cluster at runtime, never committed anywhere.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: app-db
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: prod/app/db
        property: password

This ties straight into governance. When security asks where the secrets live, "in our secrets manager, referenced by a pointer from Git, never in a repo" is a clean answer. "Base64 in a values file" is a failed audit. Get this right from the first repo. Retrofitting secret handling across 200 repos later is exactly the kind of migration nobody has time for.

Blast radius: 40 teams cannot all deploy everywhere

The fifth thing to break is isolation. In the single-team demo, whoever controls the repo controls the deploy, and that is fine. With 40 teams sharing one control plane, a flat setup means any team can deploy into any namespace on any cluster, by accident or on purpose. That is too big a blast radius. The first cross-team incident, team A's ApplicationSet grabbing team B's namespace, teaches it the hard way.

The fix is to make isolation structural, not a convention. ArgoCD's AppProject is the boundary. It limits which repos an app can pull from, which clusters and namespaces it can deploy to, and which resource kinds it can touch. Each team gets a project scoped to their own repos and namespaces, and the control plane enforces it. A team cannot deploy outside its boundary, because the project rejects it, not because a policy doc asked them not to.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-payments
spec:
  # Only this team's repos can be sources
  sourceRepos:
    - "https://git.corp.local/payments/*"
  # Only this team's namespaces, only on the clusters they are allowed on
  destinations:
    - server: https://prod.k8s.corp.local
      namespace: "payments-*"
  # No cluster-scoped resource changes from a team project
  clusterResourceWhitelist: []
  roles:
    - name: deployer
      policies:
        - "p, proj:team-payments:deployer, applications, sync, team-payments/*, allow"

This is the same least-privilege thinking a good IAM policy applies to a cloud account, pointed at your deploy plane. A boundary you can cross by forgetting a convention is not a boundary. The one the platform refuses to let you cross is.

Promotion across environments is where the copy-paste chaos hides

The sixth thing to break is the one people feel every day: getting a change from dev to staging to prod. The simple setup has a folder per environment, and promotion means copying YAML from the staging folder to the prod folder. At scale, this is a swamp. Environments drift apart because someone forgot to copy one change. Reviews are noisy, because the diff is full of duplicated boilerplate. And nobody can tell at a glance whether prod is actually running what staging validated.

The pattern that holds is rendered manifests. Instead of promoting templates and re-rendering per environment, you render the fully-resolved manifests once, per environment, into a branch or folder. Promotion becomes a diff of the actual final YAML that will be applied. You can see exactly what will change in prod, line for line, because you are looking at the rendered output, not a template that might resolve differently. Promotion is then a small, honest pull request that moves a known-good state forward. Not a copy-paste of templates with a prayer that they resolve the same way in prod as they did in staging.

The key discipline: the same artifact moves forward. The same digest-pinned images and the same rendered config that passed in staging is what goes to prod. Promotion is moving a validated thing forward, not rebuilding it and hoping. If prod re-renders from a template, you tested one thing in staging and shipped a slightly different thing to prod, which defeats the point of having staging at all.

Everything is a pull request now

The last thing to break is social, not technical, and it surprises teams because it is a side effect of GitOps working. When Git is the only way to change production, every change becomes a pull request, even the trivial ones. A one-line config bump that used to be a kubectl command is now a PR, a review, a merge, and a sync. Multiply by 40 teams, and review becomes a bottleneck. Worse, it becomes a reason to route around GitOps entirely, which is how you get the 2 a.m. kubectl edit that started this whole thing.

The fix is to match the friction of a change to its risk. Not every change needs a human reviewer. Auto-merge low-risk, well-tested changes, like an image digest bump that passed CI. Save human review for the risky surfaces: RBAC, network policy, resource limits, anything cluster-scoped. Push validation left with policy checks in CI, so a broken manifest fails on the PR, before it ever reaches the cluster, instead of failing a sync and paging someone. And give teams real autonomy inside their AppProject boundary, so a team changing its own namespace is not gated on a central platform team. That gating is the most common way a platform becomes the bottleneck everyone resents.

# Fail bad manifests in CI, on the PR, not at sync time. Cheap gate,
# huge reduction in review load and in 2 a.m. surprises.
- name: validate manifests
  run: |
    kubeconform -strict -summary rendered/prod/*.yaml
    conftest test rendered/prod/*.yaml   # policy: no privileged pods, limits set, etc.

The principle under all of these fixes is one line: GitOps should make the safe path the easy path. If following the process is slow and painful, engineers will bypass it under pressure. And a bypassed GitOps process is worse than none, because now you have the overhead and none of the guarantee. Fast auto-merge for safe changes, hard gates for risky ones, and real team autonomy are what keep people on the paved road.

Rollback is not just git revert

There is one more thing that breaks, and it breaks at the worst possible moment: during an incident. The GitOps pitch says rollback is a git revert. At small scale, that is true. At scale, "revert the commit" hides a few sharp edges you do not want to find while production is down.

The first: a revert only rolls back what the commit changed. If the bad deploy also ran a database migration, a sync hook, or anything with a side effect outside the manifests, reverting the YAML does not undo it. Your pods roll back to the old version and then fail against a schema that moved forward. That is worse than the outage you were fixing. This is the same irreversible-migration trap that bites air-gapped upgrades, and the fix is the same. Migrations have to be backward compatible, so the old version can run against the new schema. Otherwise a revert is not really a rollback.

The second is ordering. A real application is not one resource, it is a graph of them. Roll back in the wrong order and you can wedge yourself. ArgoCD sync waves let you set that order, so on the way back the database and config settle before the app that depends on them. If you have never tested a rollback, you do not know your order is right. You are hoping. Hope is not a rollback strategy.

The third is speed and clarity under pressure. A stressed on-call engineer at 2 a.m. should not be reasoning about git history and sync waves. The revert should be one obvious, documented action. ArgoCD's own rollback to a previous synced revision is often faster and clearer in the moment than a git revert plus a wait for reconciliation. Decide and rehearse this before the incident, so rollback is muscle memory, not improvisation. A rollback path you have never run is a rollback path that does not work, and you will find that out exactly when you can least afford to.

What actually scales

Step back, and the pattern is the same every time. The GitOps principles, declarative desired state, Git as the source of truth, continuous reconciliation, never stop being right. What breaks is always a shape or an operational assumption that was invisible at one team and load-bearing at forty. The controller needs sharding. Apps need generating, not declaring. Drift needs a deliberate policy and a fast path through Git. Secrets need a reference model. Teams need enforced boundaries. Promotion needs rendered artifacts. Reviews need risk-matched friction.

None of this is exotic. All of it is far cheaper to build in early than to retrofit once you are at 200 repos with the control plane on fire. If you are standing up GitOps today for a handful of teams, build as if you already have forty. Shard the controller, generate your apps, enforce project boundaries, and reference your secrets, before you need any of it. The demo topology is a trap, precisely because it works so well at small scale that you forget it was never built for the scale you are heading toward.

GitOps at scale is still GitOps. It just stops being a clever trick with one repo and becomes what it always was underneath: a distributed system you have to operate with the same rigor as the systems it deploys. Treat it that way from the start, and the beautiful demo becomes a platform that holds. Treat it as magic, and it holds right up until the day it very publicly does not.

Building a Cron Expression Parser using Python

Anil Jaiswal — Sun, 03 Sep 2023 09:24:24 +0000

Introduction

Task scheduling can be a complex task in software development, especially when it comes to specifying when and how often a task should run. This is where cron expressions come in handy. Cron expressions are widely used to define schedules for recurring tasks, but they can be a bit cryptic to read and understand. That's where the "Cron Expression Parser" project comes to the rescue.

What is a Cron Expression?

A cron expression is a string representing a schedule that determines when a task should be executed. It consists of five time fields: minute, hour, day of month, month, and day of week, followed by a command to execute. Each field can have various values or operators to define the schedule. For example, a cron expression like */15 0 1,15 * 1-5 /usr/bin/find tells us that a task should run every 15 minutes, at midnight, on the 1st and
15th day of every month, from Monday to Friday, and the command to execute is /usr/bin/find.

Simplifying Cron Expressions

While cron expressions are powerful, they can be challenging to interpret, especially for those new to them. That's where the Cron Expression Parser comes in. This Python-based tool takes a standard cron expression and converts it into a readable table format. Let's take a closer look at how it works.

How the Cron Expression Parser Works

Our Cron Expression Parser takes a standard cron expression as input and does the following:

Parsing: It breaks down the expression into its individual fields, such as minute, hour, and so on.
Handling Operators: The parser intelligently handles various operators used in cron expressions, including * (any value), - (range), , (list), and / (step).
Formatting: The tool formats the parsed cron expression into a clear and organized table. Each field name is displayed in the first 14 columns, followed by the corresponding time values.

Example Output

Let's take our previous example cron expression:

*/15 0 1,15 * 1-5 /usr/bin/find

The Cron Expression Parser converts it into the following table:

minute        0 15 30 45
hour          0
day of month  1 15
month         1 2 3 4 5 6 7 8 9 10 11 12
day of week   1 2 3 4 5
command       /usr/bin/find

Why Use the Cron Expression Parser?

Clarity: It makes complex cron expressions easy to understand, even for those not familiar with cron syntax.
Error Detection: The tool can quickly spot issues or errors in your cron expressions.
Efficiency: It simplifies the task of creating and debugging cron schedules for your recurring tasks.
Open Source: The Cron Expression Parser is open-source, so you can use it freely and even contribute to its development.

Getting Started

Using the Cron Expression Parser is straightforward. You can find the code and detailed instructions in my GitHub repository. Simply clone the repository, run the script, and input your cron expression. You'll get a neatly formatted table in no time!

Conclusion

Managing task schedules is a crucial part of software development, and cron expressions are a powerful tool for this purpose.
However, understanding and working with them can be challenging. The Cron Expression Parser simplifies this process, making it easier for developers and administrators to create and manage task schedules. Give it a try, and you'll never look at cron expressions the same way again!

Feel free to raise a Github issue if you find something broken.

Infrastructure as Code: A Beginner's Guide

Anil Jaiswal — Sat, 19 Aug 2023 07:06:49 +0000

The percentage of software companies that use IAC tools in the world is growing rapidly. In 2022, it was estimated that 55% of software companies were using IAC tools, and this number is expected to reach 75% by 2028.

What is Infrastructure as Code?

At its core, Infrastructure as Code (IAC) refers to the practice of managing and provisioning infrastructure resources through code and automation. In essence, it treats infrastructure components in the same way software developers handle their codebase. Instead of manually configuring servers, networks, and other resources, developers can define and manage these elements using code scripts and templates.

The Significance of Infrastructure as Code

The importance of adopting Infrastructure as Code (IAC) cannot be overstated, particularly in today's dynamic and competitive tech environment. Here are some key reasons why embracing IAC is essential:

1. Consistency and Reproducibility: Manual setups are prone to errors, and inconsistencies between different environments can lead to unexpected issues. IAC ensures that the infrastructure is defined in a consistent manner across all stages, from development to testing and production. This consistency facilitates easy replication of environments, reducing the risk of discrepancies that often lead to production outages.

2. Version Control and Collaboration: Treating infrastructure as code allows teams to leverage version control systems, just like they do for software code. This enables collaboration, tracking changes, and maintaining a historical record of modifications made to the infrastructure. As a result, teams can work together seamlessly, iterate efficiently, and revert to previous configurations if needed.

3. Automation and Efficiency: With IAC, repetitive tasks and configurations can be automated, freeing up valuable time for developers and operations teams. Automated provisioning not only accelerates the deployment process but also minimizes human errors that can arise from manual interventions.

4. Scalability and Flexibility: As applications grow and evolve, so does the need for scalable infrastructure. IAC allows teams to define scalability rules and configurations upfront, ensuring that the infrastructure can seamlessly adapt to changing demands without requiring substantial manual adjustments.

5. Disaster Recovery and Redundancy: IAC facilitates the creation of disaster recovery plans and redundancy setups by codifying backup configurations and failover mechanisms. This ensures that in the event of a failure, the recovery process can be initiated promptly and consistently.

6. Documentation and Auditability: Traditional setups often lack comprehensive documentation, making it challenging to understand the intricate details of the infrastructure. IAC inherently brings documentation through code comments and self-explanatory scripts, enhancing auditability and facilitating a deeper understanding of the infrastructure's architecture.

Comparing AWS CDK, Pulumi, and Terraform: Making Informed Choices

As organizations continue to embrace Infrastructure as Code (IAC) principles, the landscape of tools and frameworks to achieve this goal has expanded significantly. Among the prominent players in this arena are AWS CDK, Pulumi, and Terraform. Each of these tools brings its unique approach and features to the table, catering to the diverse needs of developers and operations teams. In this section, we will delve into a detailed comparison of these three tools, highlighting their strengths, weaknesses, and use cases.

AWS CDK is a framework for writing infrastructure code in JavaScript, TypeScript, Python, or Java. It uses the AWS CloudFormation service to deploy infrastructure. AWS CDK is a good choice for organizations that are already using AWS and want to use a tool that is tightly integrated with the AWS ecosystem.

Pulumi is a multi-cloud IAC tool that supports over 60 cloud providers, including AWS, Azure, and Google Cloud Platform. It uses a variety of programming languages, including Python, Go, C#, and JavaScript. Pulumi is a good choice for organizations that want to use a tool that is not tied to any particular cloud provider.

Terraform is an open-source IAC tool that supports over 200 cloud providers and infrastructure services. It uses a domain-specific language called HashiCorp Configuration Language (HCL) to define infrastructure. Terraform is a good choice for organizations that want a flexible and extensible IAC tool.

Here is a table that summarizes the key differences between AWS CDK, Pulumi, and Terraform:

Feature	AWS CDK	Pulumi	Terraform
Programming languages	JavaScript, TypeScript, Python, Java	Python, Go, C#, JavaScript	HashiCorp Configuration Language (HCL)
Cloud providers	AWS	Over 60	Over 200
Extensibility	Good	Excellent	Excellent
Cost	Free	Free	Free

Similarities

All three tools can be used to automate the provisioning and configuration of infrastructure.
All three tools can be used to manage changes to infrastructure.
All three tools can be used to track changes to infrastructure.
All three tools can be used to roll back to previous configurations.

Differences

AWS CDK is tightly integrated with the AWS ecosystem.
Pulumi supports over 60 cloud providers.
Terraform is an open-source tool with a large community.
AWS CDK uses JavaScript, TypeScript, Python, or Java.
Pulumi uses Python, Go, C#, or JavaScript.
Terraform uses HashiCorp Configuration Language (HCL).

Getting Started: Tutorials for AWS CDK, Pulumi, and Terraform

Embarking on your journey with AWS CDK, Pulumi, and Terraform can be exciting, but getting started might seem a bit overwhelming. Fear not, for each tool provides excellent resources to guide you through the initial steps. In this section, I'll provide you with brief tutorials to help you kickstart your experience with these powerful Infrastructure as Code tools.

AWS CDK:

Installation: To begin, ensure you have Node.js and npm installed. Then, install the AWS CDK CLI using the following command:

   npm install -g aws-cdk

Create a CDK App: Use the CDK CLI to create a new app scaffold:

   cdk init app --language=typescript

Define Infrastructure: Navigate to the newly created app directory and open the lib folder. You'll find a TypeScript file where you can define your infrastructure components using AWS CDK constructs.


// Create an EC2 Instance

import { App, Stack, StackProps } from 'aws-cdk-lib';
import { AmazonLinuxImage, Instance, InstanceType, Vpc } from 'aws-cdk-lib/aws-ec2';

class EC2Stack extends Stack {
  constructor(scope: App, id: string, props?: StackProps) {
    super(scope, id, props);

    const vpc = new Vpc(this, 'MyVPC');

    new Instance(this, 'MyInstance', {
      instanceType: InstanceType.of(InstanceClass.BURSTABLE2, InstanceSize.MICRO),
      machineImage: new AmazonLinuxImage(),
      vpc,
    });
  }
}

const app = new App();
new EC2Stack(app, 'EC2Stack');

// Create an S3 bucket

import { App, Stack, StackProps } from 'aws-cdk-lib';
import { Bucket } from 'aws-cdk-lib/aws-s3';

class S3Stack extends Stack {
  constructor(scope: App, id: string, props?: StackProps) {
    super(scope, id, props);

    new Bucket(this, 'MyBucket', {
      versioned: true,
    });
  }
}

const app = new App();
new S3Stack(app, 'S3Stack');

Deploy: Run the following commands to deploy your infrastructure to AWS:

   cdk synth
   cdk deploy

Pulumi:

Installation: Install the Pulumi CLI by following the instructions for your platform: https://www.pulumi.com/docs/get-started/install/
Create a New Project: Use the Pulumi CLI to create a new project in your desired programming language:

   pulumi new

Define Infrastructure: Navigate to the project directory and open the main program file. You can now define your infrastructure resources using Pulumi's programming constructs.


// Create an EC2 instance

import * as pulumi from '@pulumi/pulumi';
import * as aws from '@pulumi/aws';

const vpc = new aws.ec2.Vpc('my-vpc', {
  cidrBlock: '10.0.0.0/16',
});

const instance = new aws.ec2.Instance('my-instance', {
  instanceType: 't2.micro',
  ami: aws.ec2.getAmi({
    filters: [{
      name: 'name',
      values: ['amazon-linux-2'],
    }],
    mostRecent: true,
  }).id,
  subnetId: vpc.subnetIds[0],
});


// Create an S3 bucket

import * as pulumi from '@pulumi/pulumi';
import * as aws from '@pulumi/aws';

const bucket = new aws.s3.Bucket('my-bucket', {
  versioning: {
    enabled: true,
  },
});

Provision Resources: Run the following command to preview and deploy your resources:

   pulumi up

Terraform:

Installation: Install the Terraform CLI by following the instructions for your platform: https://learn.hashicorp.com/tutorials/terraform/install-cli
Create a Configuration: Create a new directory for your Terraform configuration files. Inside this directory, create a .tf file to define your infrastructure.
Define Resources: In your Terraform configuration file, define the resources you want to create using HashiCorp Configuration Language (HCL).


# Create an EC2 instance.

provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "my_vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_instance" "my_instance" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = aws_vpc.my_vpc.subnet_ids[0]
}


# Craete an S3 bucket

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
  acl    = "private"

  versioning {
    enabled = true
  }
}

Initialize and Apply: Run the following commands to initialize and apply your Terraform configuration:

   terraform init
   terraform apply

Conclusion: Choosing the Right Tool

As you've experienced, AWS CDK, Pulumi, and Terraform each offer distinct approaches to Infrastructure as Code, catering to various preferences and project requirements. AWS CDK stands out for its programming language familiarity and AWS integration. Pulumi excels in multi-cloud support and fine-grained control. Terraform's declarative syntax and thriving community make it a solid choice for many.

To make an informed decision, consider the complexity of your project, your team's expertise, and the cloud providers you intend to work with. Each tool has its strengths and can be a valuable asset in your IAC journey. By mastering the nuances of these tools, you're poised to streamline infrastructure provisioning, enhance collaboration, and create more robust and scalable applications.

If you're eager to delve deeper into the world of AWS CDK and learn about practical insights from real-world experiences, I invite you to subscribe to my newsletter (I won't spam, I promise!). In an upcoming series, I'll unravel how Cogoport has harnessed the power of AWS CDK to sculpt its infrastructure, navigating challenges and triumphs along the way. It's a chance to gain firsthand knowledge and discover the art of shaping digital landscapes.

Originally published at https://aniljaiswal.com.