Azure Cloud Engineer · 5+ Years Enterprise Experience
MetaSol · On-site, Pakistan
As a Cloud Engineer my primary focus was designing and building Azure cloud infrastructure from the ground up using Terraform as the foundation for everything. Rather than clicking through the Azure portal to create resources, every environment I built was defined in code, versioned, reviewed and deployed through a structured and repeatable process. This approach meant that spinning up a new environment or replicating an existing one was a controlled operation rather than a manual effort prone to inconsistency. Most of my work involved greenfield environments, meaning I was handed a blank slate and responsible for architecting the full infrastructure from scratch. This included everything from virtual networks and subnets to compute resources, databases, data pipelines, serverless functions and secret management. Getting this right from the start mattered because the application teams building on top of that infrastructure depended on it being secure, stable and structured correctly before they wrote a single line of application code. Managing infrastructure across DEV, TEST and PROD environments was a continuous responsibility. Each environment needed to mirror the others closely enough to catch issues early but also maintain its own boundaries around access, configuration and data. Keeping that parity consistent as infrastructure evolved across multiple projects required disciplined Terraform module design and careful state management. A significant part of the role was operational. When deployments failed, configurations drifted or runtime errors surfaced I was the person diagnosing and resolving them. This meant reading through Terraform plan outputs, Azure activity logs and resource diagnostics to find the root cause and apply a fix without destabilizing what was already running. Infrastructure issues rarely arrive at convenient times and fast accurate diagnosis was something I developed a strong habit around. Security ran through everything I built. Access management, secret handling through Azure Key Vault and network isolation were not afterthoughts. They were built into the Terraform configurations from day one so that every resource provisioned followed consistent security baselines without relying on manual checks after the fact.
Terraform · Azure Cloud · Azure Virtual Machines · Azure Virtual Networks · Azure SQL · Azure Data Factory · Azure Function Apps · Azure Logic Apps · Azure Key Vault · Greenfield Infrastructure · Multi-Environment Management · Terraform Modules · Terraform State Management · Secret Management · NSG Configuration · Cloud Architecture · Infrastructure Troubleshooting · DevOps Engineering · Platform Reliability
MetaSol · On-site, Pakistan
As a Senior DevOps Engineer my core responsibility was taking Java Spring Boot applications from source code all the way to running containers on Azure Kubernetes Service. This covered everything from writing the Dockerfile to configuring the pipeline that built, tested, packaged and deployed the application across multiple environments without manual steps in between. The containerization side of the work started at the application level. I built JARs locally using Maven before image creation, wrote Dockerfiles tailored to each application's runtime requirements and pushed the resulting images to Azure Container Registry. From there the CI/CD pipeline picked up the image and handled the deployment to AKS. I managed this flow for over 10 enterprise Java applications covering both UI and API services, each with their own pipeline configurations, environment variables and deployment strategies. The Kubernetes side required constant attention. After every deployment I verified pod health, checked rollout status and confirmed service stability through Azure Portal and Lens. When something wasn't right whether it was a failing pod, a misconfigured service or an image pull issue I diagnosed it through logs and kubectl commands and either applied a fix or triggered a rollback. Keeping workloads healthy across Dev, IST, UAT, Stage and Production was a continuous responsibility not a one time setup. A significant part of the role was also working directly with development teams. I created repositories, defined branch strategies, helped developers understand how their code integrated into the pipeline and made sure every team was following consistent practices around commits, pull requests and environment promotion. This kept the overall CI/CD ecosystem clean and predictable as more applications were onboarded. Security and pipeline hygiene were also priorities. I introduced structured approaches to secret handling, artifact management and pipeline approval gates to make sure sensitive values were never exposed and every production deployment had the appropriate controls in place.
Azure Kubernetes Service · Docker · Kubernetes · CI/CD Pipelines · YAML Pipelines · Azure DevOps · Azure Container Registry · Java · Spring Boot · Maven · Multi-Environment Deployment · Container Orchestration · Pod Management · Rollback Management · Secret Management · Azure Key Vault · Git Branch Policies · Pipeline Approval Gates · Artifact Management · Kubernetes Observability
MetaSol · On-site, Pakistan
As a member of the Platform Provisioning team my primary responsibility was building and maintaining the cloud infrastructure that application teams across the organization depended on to function. The team's core purpose was simple but critical. Every environment that developers, QA engineers and business stakeholders relied on had to be provisioned correctly, stay available and scale without issues. That accountability sat with us. My day to day work centered around two things. Keeping existing infrastructure healthy and automating the processes that would have otherwise required manual intervention every time a new environment or resource was needed. I worked heavily with Terraform to write and maintain infrastructure as code, which meant that spinning up a new environment was not a manual clicking exercise in the Azure portal but a versioned, reviewed and repeatable pipeline execution. Any change to infrastructure went through code, which gave us consistency across DevTest, Pre-Prod and Production without configuration drift. On the automation side I built and maintained GitHub Actions workflows that handled deployments and infrastructure provisioning tasks end to end. This included writing reusable workflow templates, managing secrets through secure integrations and making sure pipeline logic aligned with how each application team expected their environments to behave. Linux system administration was also a core part of the role. I handled patching cycles, system updates and compliance checks on production Linux servers to keep them secure and performing correctly. This required understanding not just how to apply patches but how to do it safely without impacting running services or causing downtime. Beyond automation and infrastructure code I also handled manual provisioning and live debugging directly in Azure when situations required it. Whether it was a misconfigured resource, an unexpected connectivity issue or a new environment request that needed hands on attention, I was comfortable working directly in the platform to diagnose and resolve it quickly.
GitHub Actions · Terraform · Azure Cloud · Linux Administration · System Patching · CI/CD Pipelines · Azure Resource Provisioning · Multi-Environment Management · Secret Management · Pipeline Automation · Azure Networking · NSG Configuration · Terraform State Management · Platform Reliability · Reusable Workflows
MetaSol · On-site, Pakistan
In this role, I functioned as the central owner of the CI/CD pipeline ecosystem across more than 10 enterprise-grade C# .NET applications. My day-to-day responsibilities revolved around making sure that every code change, from a minor bug fix to a major feature release, could travel safely and predictably from a developer's branch all the way to production without manual hand-holding. Every morning typically started with a review of overnight pipeline runs and Azure DevOps build logs. If something had failed in a nightly deployment or a scheduled integration job, I was the first point of contact. I'd trace failures through YAML stage outputs, identify whether the issue was infrastructure-related, a broken script, a misconfigured variable group, or an actual code problem, and either resolve it directly or route it to the right team with a clear diagnosis. Speed mattered here because blocked pipelines meant blocked developers. A core part of my work was building and continuously improving the YAML pipelines themselves. I structured pipelines as modular templates rather than monolithic scripts, which meant individual application teams could inherit shared deployment logic without duplicating it. Each pipeline was broken into stages corresponding to our environment chain: DEV, QAT, UAT, Pre-Prod, and Production. Each stage had its own variable groups, environment-specific configurations, and where required, manual approval gates before promotion. This wasn't just about automation. It was about making the release process auditable and controlled, so that nothing reached production without passing through every checkpoint. Multi-region production deployments were one of the more technically demanding parts of the role. Our production setup ran across two Azure VM clusters, one in Virginia and one in Texas. I designed the deployment sequencing directly within the YAML pipeline so that the Virginia environment would be deployed and validated first, and the Texas environment would follow only if the prior stage succeeded. I also embedded health check steps and rollback triggers, so if a post-deployment validation failed, the pipeline would automatically revert the service to its last known stable state rather than leaving production in a broken condition. PowerShell scripting was something I used constantly. Before any deployment, automated scripts would stop the relevant Windows services on the target VMs, clear caches, and prepare the environment. After deployment, the scripts would restart services, run smoke tests against key endpoints, and report status back into the pipeline. This made the entire deployment process hands-off and repeatable. No one needed to RDP into a server during a release window. Code quality was enforced upstream through SonarQube integration built directly into the CI stage. I configured quality gate thresholds covering code coverage percentages, critical and blocker vulnerability counts, duplicated code ratios, and maintainability ratings. Any build that didn't meet the defined thresholds would fail the pipeline at the CI stage and never reach deployment. This meant security and quality issues were caught early, not discovered after a production incident. Beyond the technical work, a significant part of the role was coordination. I worked closely with developers to onboard new applications into the pipeline framework, help them understand what a pipeline failure actually meant, and adjust deployment configurations when new infrastructure was provisioned. During sprint cycles I tracked deployment tasks on Azure Boards, participated in sprint planning to estimate release effort, and reported deployment health during retrospectives. When something went wrong during a live release, I was the person on the call, walking through the pipeline logs in real time and making the call on whether to proceed, roll back, or hold. The overall goal every day was simple in principle but complex in practice: make sure that when a developer merges code, they can trust the system to take it the rest of the way, safely, correctly, and without surprises.
Azure DevOps · YAML Pipelines · CI/CD Automation · PowerShell Scripting · SonarQube · Virtual Machines · Windows Services · Multi-Stage Pipelines · Release Governance · Self-Hosted Agent Pools · Git Branch Policies · Multi-Region Deployment · Failover Automation · Environment Promotion · Secret Management · Pipeline Diagnostics · C# .NET · Azure Boards · Deployment Automation
MetaSol · Remote · United States
As a freelance Flutter developer I worked with US based clients to build and ship production grade cross platform applications targeting Android, iOS and web from a single codebase. The nature of freelance work meant I owned the entire development lifecycle on most projects. There was no separate team handling architecture, state management or backend integration. I made those decisions, implemented them and delivered working applications that clients could put in front of real users. The apps I built spanned social and community platforms, business enterprise tools and health and fitness applications. Each category came with its own set of UI and functional demands. Social apps required real time data, dynamic feeds and user interaction flows. Enterprise tools needed structured navigation, role based access and reliable data handling. Health and fitness apps demanded clean interfaces, progress tracking and often notification driven engagement to keep users coming back. Flutter's widget system gave me the flexibility to build all of these without compromising on the native feel across platforms. Firebase was my primary backend stack for most projects covering authentication, Firestore for real time data, Firebase Storage for media and Cloud Functions for server side logic where needed. For projects with more complex backend requirements I integrated with Node.js APIs, handling REST based communication, token based authentication and structured data flows between the app and the server. Working with US based clients also shaped how I worked beyond just the code. Expectations around delivery quality, communication clarity and production readiness were high. Apps had to be stable, well structured and maintainable, not just functional. That standard pushed me to write clean, scalable Flutter code and think carefully about architecture from the start of every project rather than patching things together as requirements grew.
Flutter · Dart · Cross Platform Development · Android · iOS · Flutter Web · Firebase · Firestore · Firebase Authentication · Firebase Storage · Firebase Cloud Messaging · Cloud Functions · Node.js · REST API Integration · Real Time Data · State Management · GetX · BLoC
B.S. Information Technology
UIIT · 2020–2024