Cloud & Kubernetes
Build the foundation. Keep it dependable.
SENIOR DEVOPS ENGINEER · HYDERABAD, INDIA
Hi, I’m Vardhan.
Srivardhan Reddy Kolan
Senior DevOps Engineer
Senior DevOps &
Platform Engineer.
AWS · Kubernetes · Terraform · Linux · Cloud Infrastructure
Building reliable cloud platforms, automating infrastructure, and solving production engineering challenges.
Currently at Nemetschek Group · BluebeamCloud infrastructure. Real production problems.
PLATFORM OVERVIEWillustrative architecture
git pushmain
Build. Validate. Approve.CI/CD · production controls
AWS CLOUD managed infrastructure
Kubernetes / EKS
Workload 01
Workload 02
Workload 03
Metrics. Alerts. Understanding.
infrastructure as codehuman judgment included ↗
01 / THE WAY I THINKDesign → automate → observe → improve
BUILT ON EXPERIENCE
Linux & production operations
Cloud & platform engineering
AWS · CKA
01 / THE APPROACHGood infrastructure
Good infrastructure
makes room for good work.
I’m Srivardhan Reddy Kolan, a Senior DevOps Engineer based in Hyderabad. My path started in Linux and application support, then grew into cloud infrastructure, Kubernetes, and platform engineering.
I like the work between a system working once and a system working reliably: repeatable infrastructure, thoughtful release controls, useful monitoring, and a clear understanding of what went wrong.
More about my journeyInfrastructure as Code
Repeatable infrastructure, reviewed as code.
Delivery & GitOps
Make the path to production safer.
Observability & Operations
Understand the system. Find the cause.
Linux & Networking
Operational foundations for troubleshooting systems.
Exploring AI Infrastructure
Personal learning, separate from production experience.
02 / THE JOURNEYBuilt through
Built through
hands-on experience.
From Linux fundamentals to production platforms.
A career spent close to the systems.
2025 — PresentCURRENT
Nemetschek Group · Bluebeam
01Technical Analyst - DevOps
Supporting the infrastructure behind Bluebeam products, from AWS and EKS operations to production deployment governance.
Contributions
- Designed and validated GitLab Protected Environment approval controls before downstream Terraform pipelines execute.
- Built and maintained Terraform/Terragrunt workflows for AWS networking, environment configuration, and reusable modules.
- Investigated production incidents involving Redis health, pod evictions, HPA sizing, and EC2 hardware failures.
- Improved operational readiness through dashboards, alerts, RCA documentation, and cross-team production reviews.
2024 — 2025
MKS Vision Pvt Ltd.
02Senior DevOps Engineer
Worked on AWS migration, Kubernetes operations, and delivery automation, with a focus on reliable production platforms.
Contributions
- Led migration work for business applications moving from on-premises infrastructure to AWS.
- Designed and managed CI/CD pipelines for microservices and implemented Kubernetes configurations for production workloads.
- Established monitoring with Prometheus and Grafana and conducted root cause analysis for production incidents.
2018 — 2024
AVYA IT Pvt Ltd.
03DevOps Engineer
Helped move applications from on-premises environments to AWS and made delivery and operations more repeatable.
Contributions
- Developed Jenkins CI/CD pipelines for monolithic and microservice applications.
- Managed Docker and Kubernetes workloads across development, test, and production.
- Automated Linux provisioning and deployments with Ansible; implemented Prometheus and Grafana monitoring.
2017 — 2018
CDK Global
04Sr. Process Associate
Administered Red Hat Linux servers and supported critical environments around the clock.
Contributions
- Handled server builds, patching, users, LVM, cron, service checks, and network troubleshooting.
- Provided production incident response and operational documentation.
2013 — 2015
Tech Mahindra
05Linux L2 Production Support Engineer
Built a foundation in Linux operations and L2 application support within an ITIL environment.
Contributions
- Handled incidents, change requests, Linux deployments, and shell scripting documentation.
03 / SELECTED WORKReal systems.
Real systems.
Considered decisions.
A closer look at problems I’ve worked on.
Based on my professional experience.
DEPLOYMENT GOVERNANCE/01
Parent pipeline
→Approval gate
→Terraform
Illustrative Command Demo
Example command: terraform plan. Example output: Configuration validated. Plan ready for review. Production approval required. This is an illustration, not a live system.
Completed · Professional · public-safe
GitLab approval controls for Terraform delivery
GitLab approval controls that protect infrastructure changes before a downstream pipeline starts.
Explore the work +
The context
Production infrastructure changes need an explicit approval boundary, including when a parent pipeline triggers downstream Terraform jobs.
My contribution
Designed and validated Protected Environment controls and parent trigger-job behavior using environment action:start before downstream execution.
Engineering obstacle
A parent trigger job introduces a second pipeline boundary. Approval had to be checked before downstream infrastructure execution, rather than assuming a downstream job would enforce it.
Result and evidence boundary
Validated approval controls and trigger-job behavior. This summary describes the control design; it does not claim measured incident reduction or deployment-speed gains.
Constraints
Employer configuration and logs are private. The diagram is a sanitized conceptual flow, not an employer infrastructure map.
Future improvements
Future improvement: maintain regression scenarios for approved, rejected, and unapproved parent-to-child runs as pipeline configuration evolves.
The takeaway
Approval behavior needs to be validated across pipeline boundaries, alongside the infrastructure plan itself.
PRODUCTION RELIABILITY/02
Signals
→Cluster analysis
→Root cause
Illustrative Command Demo
Example command: kubectl get pods. Example output: api-server 1/1 Running. worker 1/1 Running. Workloads ready for inspection. This is an illustration, not a live system.
Completed · Professional · public-safe
Investigating EKS workload and node failures
Incident analysis across applications, Kubernetes, and the underlying EC2 infrastructure.
Explore the work +
The context
Kubernetes symptoms can originate in workload sizing, application health, or the nodes hosting the cluster.
My contribution
Investigated Redis degradation, memory-driven pod evictions, HPA/request mismatches, and NodeNotReady events caused by EC2 hardware issues. Documented findings for follow-up.
Engineering obstacle
Similar Kubernetes symptoms required investigation at different layers: application health, workload resource requests, and underlying EC2 node health.
Result and evidence boundary
Documented investigation findings and root causes for operational follow-up. No response-time or availability metrics are claimed.
Constraints
This summarizes separate investigations; it is not a single incident or a published employer architecture.
Future improvements
Future improvement: use sanitized investigation checklists to make recurring diagnostic steps easier to repeat.
The takeaway
Useful incident response connects workload signals to infrastructure evidence and leaves a clear RCA for the next engineer.
PLATFORM VISIBILITY/03
Metrics
→Cost allocation
→Visibility
Illustrative Command Demo
Example command: kubectl get svc opencost. Example output: Service: opencost. Cluster metrics available. Ready to explore allocation. This is an illustration, not a live system.
Completed evaluation · Professional · public-safe
Evaluating Kubernetes cost visibility
Evaluating Kubernetes cost visibility to support better showback and chargeback conversations.
Explore the work +
The context
Cluster-level cost visibility helps teams understand resource ownership and discuss infrastructure spend.
My contribution
Evaluated OpenCost with VictoriaMetrics and compared cluster-level insights against existing SaaS cost tooling.
Engineering obstacle
The evaluation compared cluster-level cost signals with existing SaaS tooling; visibility alone does not establish realized cost savings.
Result and evidence boundary
Evaluated OpenCost with VictoriaMetrics for cost visibility. This was an evaluation, not a claim of completed chargeback rollout or savings.
Constraints
Internal cost data, configuration, and comparisons are not public.
Future improvements
Future improvement: define acceptance criteria for data coverage and allocation accuracy before any rollout decision.
The takeaway
The focus was evaluating cost visibility patterns and the information available to teams.
04 / ALWAYS EXPERIMENTINGProduction mindset.
Production mindset.
Home lab curiosity.
A Proxmox-based playground for learning by doing. I explore Kubernetes, self-hosted tools, automation, and local LLMs—then bring that practical understanding back to platform engineering.
Find me on GitHubvardhan@homelab ~
Illustrative Command Demo
Example command: cat learning.md. Example output: Proxmox: Virtualization & Self-hosting. Kubernetes: Containers & Orchestration. Observability: Metrics & Dashboards. Local LLMs: Exploring AI Infrastructure. This is an illustration, not a live system.
05 / THE FOUNDATIONS
Learning, validated.
CKA
Certified Kubernetes Administrator
Cloud Native Computing Foundation
Active
Verify credential
AWS
AWS Certified Solutions Architect – Associate
Amazon Web Services
Active
Verify credential
RHCE
Red Hat Certified Engineer (v7)
Red Hat
Previously earned · expired
EDUCATION
Bachelor’s in Computer Science and Mathematics · Osmania University, Hyderabad
06 / WHAT’S NEXT?
Let’s build something
that holds up.
Cloud platforms, delivery workflows, or a good infrastructure problem.
I’m happy to compare notes.