Loading
Engineering recordCloud & DevOps Engineer
Sushant
Sonbarse
I work on the path from a commit to production, and on what happens the day part of it breaks.
This site is built to be tested more than read. It has six working infrastructure labs, six case files, and a field guide to how I think about these systems.
How to read this site
- Record
- Stated in my work history. These are the only claims about what I did and achieved.
- Reference
- How this class of system is designed. Engineering knowledge, not a claim about a specific engagement.
- Simulation
- Real logic running in your browser. No cloud account or live system sits behind it.
- Live
- A true fact about this site, generated when it was built.
01
On the record
Record
Everything in this section comes from my work history.
- 35+
- microservices in the CRM deployed
- 2h → 30m
- deployment time
- 40%
- CI/CD pipeline efficiency gain
2025 to present● Current
Freelance DevOps Consultant
Self-employed, Remote
- CI/CD pipeline setup and optimization
- Cloud infrastructure design and management
- Kubernetes consulting and implementation
AWS / GCP / Azure
Sep 2024 to May 2025
DevOps Engineer Intern
HisanLabs Pvt Ltd, Pune, Maharashtra
- Deployed a CRM with 35+ microservices
- Automated AWS infrastructure with Terraform
Angular / Spring Boot / AWS EKS / Terraform
02
Start by breaking something
Simulation
Availability is decided by dependencies, and diagrams usually hide them. This one computes them.
Select any component to fail it
03
Case files
Each file marks, section by section, what is on the record and what is reference engineering.
- 01A 35-service CRM on EKSAWS EKS / Terraform / Spring Boot / Angular
- 02Containers and Kubernetes managementDocker / Kubernetes / Terraform / Helm
- 03CI/CD pipeline automationJenkins / GitLab CI / GitHub Actions
- 04AWS infrastructure as codeTerraform / AWS
- 05Monitoring and observabilityPrometheus / Grafana / ELK
- 06On-premises to AWS migrationAWS / Migration
04
The lab
Six questions that come up in real operations, each with a model you can change.
- Blast radiusWhat actually stops working when this component dies?
- Release pathWhere does each kind of bad change get caught, and who sees it?
- SchedulerWhy is this pod Pending?
- Plan readerWhat does this one-line change really do?
- Error budgetShould this incident wake someone up?
- Access traceWhy was this request denied?
05
The atlas
Reference
A position on each domain, in place of a logo wall.
- Cloud architecturePick failure domains first. Services are the easy part of the diagram.
- DevOps and automationA pipeline is a series of arguments that a change is safe. Each stage should catch something the previous one could not.
- Containers and orchestrationMost Kubernetes incidents are about requests, limits and probes. Understand those before adding more platform.
- Infrastructure as codeThe plan is the code review. If nobody reads the plan, the code is only documentation.
- Observability and reliabilityAlert on what users experience. Causes belong on dashboards, and symptoms belong on pagers.
- Security and DevSecOpsPrefer controls that make the unsafe path impossible over checks that report it afterwards.
- AI infrastructure and MLOpsA model is a build artifact with a data dependency. Most delivery discipline carries over, and drift is what is new.
06
Work with me
Available for freelance Cloud and DevOps work, remotely.