Key DevOps Career Lessons from an Industry Session at NetSol

M. Ibtsam — Mon, 05 Jan 2026 16:59:19 +0000

Today, I attended a highly insightful DevOps career guidance session hosted by Sir Muhammad Awais, with Sir Faran Tariq, a DevOps Team Lead at NetSol, as the chief guest.

The session was focused on helping students and freshers understand the current DevOps and Cloud job market, realistic career paths, and the skills that truly matter in the industry.

Will AI Replace DevOps Jobs?

The session started with a common fear many of us have today:

“AI will take over IT jobs.”

Sir Faran cleared this misconception very clearly.

AI will not replace problem solvers.
If you are learning only to perform repetitive or labor-based tasks, AI may replace that role.
But if you focus on problem-solving, critical thinking, and understanding systems deeply, AI will actually secure and enhance your career.

DevOps engineers are expected to think, analyze, optimize, and improve systems—not just run commands.

Learn the “WHY” Before the “HOW”

One of the most important lessons from the session was about learning effectively.

Before learning any tool or technology, you should always ask:

Why am I learning this?
What problem does it solve?
How does it solve that problem?
Which tools are used and why?
How does it improve efficiency, security, and reliability?

For example, if you are learning DevOps, don’t start directly with tools. First, understand the problems DevOps was created to solve, and then move toward tools and implementations.

Interviews Are Learning Opportunities

After technical skills, the session focused on interpersonal skills and interview mindset.

Most interviewers look for:

Clear communication skills
Genuine interest in the company
Passion and a positive learning attitude

An interview should not feel like a "jail". It should be treated as a learning center.

If you fail to answer a question in an interview, that’s okay.
But if you don’t learn it afterward and fail again later, that’s not okay. A good habit is to write down interview questions after every interview and review them regularly.

Degrees vs Certificates vs Real Skills

Sir Faran also shared clarity on degrees and certifications:

In service-based companies, degrees and certifications can help you get shortlisted.

In product-based companies, your concepts, hands-on work, and problem-solving skills matter more than certificates.

Your real value comes from how well you understand systems and solve real-world problems.

Final Thoughts

This session provided practical industry insights that every DevOps or Cloud aspirant should know. It helped clarify expectations, required skills, and the mindset needed to grow in this field.

Special thanks to Sir Muhammad Awais for hosting this session and Sir Faran for sharing real-world DevOps experience and guidance.

If you’re planning a career in DevOps or Cloud, sessions like these can give you clarity and direction.

From Zero to ECS: My Journey of Deploying a Micro-service with AWS CodePipeline, CodeBuild & ECS

M. Ibtsam — Fri, 02 Jan 2026 08:45:32 +0000

“Some projects don’t start with confidence. Some start with chaos… and slowly teach you who you really are.”

Yesterday, I built a fully automated CI/CD pipeline on AWS, a project that initially seemed simple but turned into a challenging endeavor filled with valuable lessons, broken builds, IAM nightmares, and ultimately, the sweetest green deployment. This wasn’t just about deploying a template website. This was about building a micro-service pipeline, learning to trust automation, and fighting with AWS until it finally smiled back.
Let me take you through the journey

The Beginning: A Dockerfile, a Template, and a Dream

It all started with a simple static website template from Templatemo. Beautiful. Minimal. Lightweight.
I wrote a small Dockerfile on top of Ubuntu + Apache:

FROM ubuntu:latest

# Install Apache and tools
RUN apt-get update && \
    apt-get install -y apache2 apache2-utils wget unzip && \
    apt-get clean

# Set working directory
WORKDIR /var/www/html

# Download the template and name the downloaded file
RUN wget https://templatemo.com/download/templatemo_597_neural_glass -O template.zip

# Extract and copy files
RUN unzip template.zip && \
    cp -rvf templatemo_597_neural_glass/* . && \
    rm -rvf template.zip templatemo_597_neural_glass

EXPOSE 80

CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

One container.
One decision.
One microservice.
This service would not live inside a monolith. It would be independent, deployable on its own, and scalable on its own. And AWS would handle the rest.

Building the Pipeline That Would Change Everything

AWS CodeCommit became my Git server — a quiet place where everything begins.

Each commit in my Dockerfile triggered a pipeline.

Step 1 — CodePipeline picks up the commit
Step 2 — CodeBuild builds the image
Step 3 — Pushes to ECR
Step 4 — Updates ECS test cluster
Step 5 — Manual approval
Step 6 — Production deployment behind an ALB
The heart of the build was my buildspec.yml:

version: 0.2
phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws --version
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - REPOSITORY_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME

  build:
    commands:
      - echo Build started on $(date)
      - echo Building the Docker image...
      - docker build -t "$REPOSITORY_URI:$IMAGE_TAG" .

  post_build:
    commands:
      - echo Build completed on $(date)
      - echo Pushing the Docker image...
      - docker push "$REPOSITORY_URI:$IMAGE_TAG"
      - echo Writing image definitions file...
      - printf '[{"name":"%s","imageUri":"%s"}]' "$CONTAINER_NAME" "$REPOSITORY_URI:$IMAGE_TAG" > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

The moment I saw my first image appear in ECR, I knew I was getting somewhere.

The War With IAM Roles, Policies, & Security Groups

Let me be honest.
This was not a project.
This was a battlefield.
The biggest enemy?

IAM Roles
Security Groups
Trust Policies
Missing Permissions
SNS Publish Denied Errors

At one point, CodePipeline screamed:
“sns:Publish is not allowed for this role.”
And I just sat there… staring at it like:
“AWS, yaar, ki problem hai teri?”
I fixed it by adding its policy.

Creating Test & Production Clusters

I separated environments:
Test Cluster (Dev environment)

Every commit goes here first
Behind an ALB
Quick validation
No manual approvals

Production Cluster

Behind an ALB
Scalable
Auto-recovery
Requires manual approval through SNS

This is where the pipeline became… real.

The Sweetness of Manual Approval

Before deploying to production, CodePipeline sends me:
An SNS Email

The email asks:
“Do you approve this deployment?”

This made the deployment feel like signing off on a release in a real company.

Once I click “Approve”, the production ECS service pulls the new image and updates behind ALB without downtime.

Why This Project Mattered More Than I Expected

This project wasn’t just CI/CD.
It taught me:

Microservices give freedom One service, one task definition, one pipeline, independent scaling.
Cloud architecture humbles you Security groups and IAM remind you that the cloud is powerful, but not forgiving.
Automation is addictive One commit → full deployment Zero manual server management.
CI/CD is not a luxury - it’s a survival Modern development = pipelines + containers.

The Final Deployment, The Moment I Trusted the Cloud

When the ALB finally showed my website live and healthy…
It felt magical.

I didn’t open any EC2 machine.
I didn’t configure any OS manually.
I didn’t copy-paste files.

Just:

Write code
Commit
Approve
Deploy

That’s the real confidence CI/CD gives you.

If You’re Moving to Cloud, Move With Courage

If you’re shifting from monolithic apps to microservices…
If you want to understand real AWS DevOps…
If you want to feel the thrill of automation…
Then build a pipeline like this.

Break it.
Fix it.
Fear it.
Love it.

Because every green checkmark on AWS teaches you something about yourself.
And that’s why this project matters.

DEV Community: M. Ibtsam