DEV Community: Inzamam Virk

Modern Engineers Can’t Afford to Be “Just Developers” Anymore.

Inzamam Virk — Sat, 13 Dec 2025 07:16:55 +0000

There was a time when being a solid frontend or backend developer was enough.

Write code → ship a feature → done.

That era is fading.

Today, the engineers who truly stand out aren’t just good at writing code — they understand how their code survives in the real world.

That means thinking beyond the editor and into questions like:

How does this app get deployed?
What happens when traffic spikes?
How do services communicate with each other?
How do we keep things reliable under load?
How do we secure systems properly?

You don’t need to become a full-time DevOps engineer —
but ignoring DevOps thinking is no longer an option.

🥷 A real example from my recent work

I recently set up n8n in a full production environment — not on a single VPS, but on Kubernetes.

That immediately pushed me far beyond “just running a server.”

I had to think about:

Configuring Redis queues
Using a managed PostgreSQL database
Setting up domains & SSL
Handling Ingress routing
Deploying workers
Performing load testing
Making sure everything stayed stable under real traffic

And here’s the interesting part:

👉 The biggest breakthroughs weren’t about code at all.

They came from understanding:

system design
reliability
operational trade-offs
and how things fail in production

🧠 That’s the real shift

Modern engineering isn’t just about writing clean logic.

It’s about building systems that scale, survive, and keep running — even when reality gets messy.

The more we understand the full lifecycle of what we build, the more valuable we become.

Because companies don’t just need features.

They need systems that don’t fall apart.

Why Infrastructure-as-Code Isn’t Optional Anymore

Inzamam Virk — Sun, 23 Nov 2025 14:20:37 +0000

🚀 Why Infrastructure-as-Code Isn’t Optional Anymore
We’re past the era where clicking around the AWS console counts as “building infrastructure.” It might work for a demo or a one-off experiment, but when you’re dealing with real systems—whether microservices or even monolithic architectures—
👉 manually setting up infrastructure is simply not a good practice anymore.
Here’s why 👇
1️⃣ Terraform (IaC tool) gives you something the console never will: predictability.
Infrastructure defined as code is versioned, reviewable, testable, and reproducible.
You always know what you are deploying and why something changed.
No surprises.
No drift.
No “who created this IAM role?” moments.
2️⃣ Manual infra breaks the moment you need a second environment.
Staging? QA? Dev?
Manually recreating environments is a recipe for inconsistencies and late-night debugging.
With Terraform:
terraform apply → identical environments, anywhere, anytime.
3️⃣** IaC is the foundation of real DevOps.**
CI/CD pipelines become cleaner.
Teams deploy faster.
Rollback becomes safer.
Changes become auditable.
Infra becomes part of the development workflow, not a set of hidden configurations no one wants to touch.
4️⃣ Modern architectures demand automation.
When your system involves:
ECS Fargate workloads
Next.js frontend containers
Backend APIs
Workers
MongoDB Atlas, S3, SES
CloudFront, Route53, ALB, CloudWatch
GitHub Actions → ECR → CodeDeploy
…you simply can’t afford manual configuration.
There are too many moving pieces. Automation becomes survival.
5️⃣ Terraform future-proofs your engineering team.
People come and go.
Terraform stays.
It becomes a source of truth that outlives team changes, memory gaps, and undocumented console clicks.
6️⃣ If the architecture grows, your IaC grows with it.
Scaling the system I designed would be painful without Terraform:
auto-scaling policies, ALB rules, ECS task definitions, IAM boundaries—
all must evolve together.
Terraform gives you the confidence to scale without fear.

Would love to hear your thoughts?

Make your application loosely coupled-Abstraction-PolyMorphism

Inzamam Virk — Tue, 16 Jul 2024 02:35:58 +0000

While developing an application it's mandatory to keep components independent from each other, this is what loose coupling is. It provides standardization, consolidation, normalization, and governance over your application. A loosely coupled application is easy to scale up.

In this article: You will learn with an example, how to make your application loosely coupled and get the maximum out of it.

Need of Loose Coupling:

Let's say you are fetching something from your UserDatabase database, here is the data-layer defined function to fetch database records:


public class UserDatabase {
    public String getUserDetails(){
        return "User Deatils ";
    }
}

In our service layer, let's create a function to talk to our data layer in order to fetch records:


public class UserDatabase {
    public String getUserDetails(){
        return "User Details in DB1";
    }
}

In our application layer or main function we will talk to our service layer:

public static void main(String[] args) {
        //Tight Coupling
        UserManager userManager = new UserManager();
        System.out.println(userManager.getUserInfo());
    }

In this application, when we try to scale up our application, tight coupling will make it redundant and hard to expand.
That's why a loosely coupled application is so important, In spring boot we achieve it using interfaces. Let's make the above app loosely coupled.

Loose Coupling:

Let's define an interface that will give us an overall structure for the data layer:

public interface UserDataProvider {
    String getUserDetails();
}

Now fetch database records while implementing this interface:

public class UserDatabase implements UserDataProvider{
    @Override
    public String getUserDetails(){
        return "User Details in DB1";
    }
}

Now define the service layer to communicate with the data layer:

public class UserManager {
    private UserDataProvider userDataProviderr;
    public UserManager(UserDataProvider userDataProvider) {
        this.userDataProviderr = userDataProvider;
    }

    public String getUserInfo(){
        return userDataProviderr.getUserDetails();
    }
}

Here while injecting a UserDataProvider reference object into UserManager we will be able to access the UserDatabase function which implements that interface so it will provide us abstraction at the level of the data layer.

Now we can access records through UserManager :

    UserDataProvider userDataProvider = new UserDatabase();
        UserManager userManager = new UserManager(userDataProvider);
        System.out.println(userManager.getUserInfo());

We can easily scale up our application and integrate as many database connections as we want like if we need to configure another database for example WebServerDatabase, we only need to create its instance assigned to the implemented interface, and then through UserManager we can access that too. Using an interface provides us Abstraction, loose coupling, and PolyMorphism(implementing the same interface by different classes provides us polymorphism).

Happy Coding :)

Running Python script with aws lambdas

Inzamam Virk — Sun, 14 Jul 2024 18:42:40 +0000

As a software engineer sometimes you have to write a script to add or update some records which you don't want to handle in your codebase. For a few records, you can run your script locally even for hundreds of records you can use multithreading but when you have to deal with thousands of records these methods are not enough. So here comes AWS lambdas or GCP function to streamline your whole script where you don't need to worry about rerunning your script if there is any network or machine interruption.

In this article: You will learn how to efficiently handle large record updates using AWS Lambdas, with a driver function and a target function.

Set up your Lambdas:

Set up two AWS lambda functions, one driver function and the other target function. The driver function handles source(Record location) authentication and data processing before invoking the target function asynchronously.

For example, if you need to modify data stored in S3 bucket, here is a simple driver/iterator function:


import boto3

client = boto3.client('lambda')

def lambda_handler(event, context):
    index = event['iterator']['index'] + 1

    # update payload according to your requirements
    response = client.invoke(
        FunctionName='LAMBDA_TO_INVOKE',
        InvocationType='Event',
        Payload=json.dumps({
            'bucket_name': 'YOUR_BUCKET_NAME',
            'file_key': 'YOUR_FILE_KEY'
        })
    )

    return {
        'index': index,
        'continue': index < event['iterator']['count'],
        'count': event['iterator']['count']
    }

The target function fulfills the purpose and performs read-write operations or other modifications at the source.

Here is a simple example of a target/invoked function :


import boto3
s3_client = boto3.client('s3')

def lambda_handler(event, context):
    # Extracting necessary information from the event
    bucket_name = event['bucket_name']
    file_key = event['file_key']

    # Get file from S3
    s3_response = s3_client.get_object(Bucket=bucket_name, Key=file_key)
    file_content = s3_response['Body'].read()

    # Perform modification on the file content (example: convert to uppercase)
    modified_content = file_content.upper()

    # Upload the modified file back to S3
    s3_client.put_object(Bucket=bucket_name, Key=file_key, Body=modified_content)

    return {
        'statusCode': 200,
        'body': 'File modified successfully'
    }

Below are some valuable tips for automation:
Before you run your script, ensure these things for better results:

Add proper logging to track your modified and remaining records and overall progress.
Keep your OAuth credentials in your credentials manager or any safe place.
Structure your program so that in any case if you have to rerun your program it shouldn't re-modify your data.

When we use any package outside of python environment like pandas we will probably face issue related to "package not resolved" or something like that so you have to create python environment install all required dependencies and then package them all to upload lambdas.

If you are facing a packaging issue, I have discussed that in the below article:
Will write it soon :)