What does Nisarg Pendal specialize in?

Nisarg Pendal specializes in DevOps engineering and cloud solutions architecture, with expertise in AWS, Azure, Kubernetes, Docker, Terraform, and CI/CD automation. He has delivered 14+ major projects including cloud infrastructure optimization, microservices migration, and deployment automation.

What cloud platforms does Nisarg Pendal work with?

Nisarg works with both AWS (Amazon Web Services) and Azure (Microsoft Azure). His AWS expertise includes CloudFront, Lambda, EC2, S3, and Image Builder. For Azure, he specializes in AKS (Azure Kubernetes Service), infrastructure as code, and microservices architecture.

What are Nisarg Pendal's most notable projects?

Notable projects include: AWS CloudFront Cache Automation (95% reduction in manual effort), Azure Microservices Migration (80% scalability improvement), Jenkins to GitLab CI/CD Migration (50+ pipelines, 60% faster builds), AWS Cost Optimization (30% monthly savings), and Industrial IoT Environmental Monitoring system.

How can I hire Nisarg Pendal for DevOps consulting?

You can contact Nisarg Pendal via email at nisargpendal@gmail.com or through the contact form on his portfolio website at https://nisargpendal-portfolio.vercel.app/contact. He is available for cloud infrastructure consulting, DevOps automation projects, CI/CD implementation, and full-time DevOps Engineer roles.

Where is Nisarg Pendal located?

Nisarg Pendal is based in Ahmedabad, Gujarat, India, and provides DevOps and cloud consulting services worldwide.

What DevOps tools does Nisarg Pendal use?

Nisarg uses a comprehensive DevOps toolset including Docker, Kubernetes, Terraform for infrastructure as code, Jenkins and GitLab CI/CD for continuous integration and deployment, Python and Bash for automation scripting, and various AWS and Azure native tools.

What results has Nisarg Pendal achieved in cloud cost optimization?

Nisarg has achieved significant cost savings through cloud optimization, including 30% reduction in monthly AWS costs through optimization and drift detection, 95% reduction in manual effort through automation, and 60% faster build times through CI/CD pipeline optimization.

Does Nisarg Pendal have experience with Kubernetes?

Yes, Nisarg has extensive Kubernetes experience, including migrating monolithic applications to microservices architecture on Azure Kubernetes Service (AKS), container orchestration, and managing production Kubernetes clusters for enterprise applications.

Feb 2021 - Oct 2021 • Technical Deep Dive

Azure Microservices Migration

Deep technical implementation details and lessons learned.

Technical Implementation

Technical details coming soon...

Frequently Asked Questions

How did you handle zero-downtime migration for critical services?

" We used a technique called blue-green deployment with traffic shifting. Basically, we'd spin up the new service in Azure, run both versions in parallel, gradually shift traffic over, and only decommission the old version after everything was verified. For Tier 1 services, this process sometimes took weeks of careful monitoring. "What was your rollback strategy?" Every migration had a detailed rollback plan. We maintained the old infrastructure in read-only mode for at least 30 days after migration. Database replications ran both directions initially. If anything went wrong, we could switch back in minutes, not hours. "How did you manage dependencies between 250+ services?" We created a dependency map that looked like spaghetti at first. But we used tools to visualize service communications and identify migration groups. Services were migrated in waves based on their dependency chains. No service was migrated before its dependencies. "What monitoring and observability did you implement?" Application Insights everywhere. Custom dashboards for each service tier. Distributed tracing to follow requests across services. Real-time alerting with PagerDuty integration. During migration, we actually had better visibility than the old system ever provided. "How did you handle the database migrations?" Databases were the trickiest part. We used Azure Database Migration Service for the initial sync, but the real work was in maintaining consistency during the transition. We implemented event sourcing patterns where possible and used change data capture to keep systems in sync during the migration period. "What about testing? How do you test 250+ services?" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.

What was your rollback strategy?

" Every migration had a detailed rollback plan. We maintained the old infrastructure in read-only mode for at least 30 days after migration. Database replications ran both directions initially. If anything went wrong, we could switch back in minutes, not hours. "How did you manage dependencies between 250+ services?" We created a dependency map that looked like spaghetti at first. But we used tools to visualize service communications and identify migration groups. Services were migrated in waves based on their dependency chains. No service was migrated before its dependencies. "What monitoring and observability did you implement?" Application Insights everywhere. Custom dashboards for each service tier. Distributed tracing to follow requests across services. Real-time alerting with PagerDuty integration. During migration, we actually had better visibility than the old system ever provided. "How did you handle the database migrations?" Databases were the trickiest part. We used Azure Database Migration Service for the initial sync, but the real work was in maintaining consistency during the transition. We implemented event sourcing patterns where possible and used change data capture to keep systems in sync during the migration period. "What about testing? How do you test 250+ services?" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.

How did you manage dependencies between 250+ services?

" We created a dependency map that looked like spaghetti at first. But we used tools to visualize service communications and identify migration groups. Services were migrated in waves based on their dependency chains. No service was migrated before its dependencies. "What monitoring and observability did you implement?" Application Insights everywhere. Custom dashboards for each service tier. Distributed tracing to follow requests across services. Real-time alerting with PagerDuty integration. During migration, we actually had better visibility than the old system ever provided. "How did you handle the database migrations?" Databases were the trickiest part. We used Azure Database Migration Service for the initial sync, but the real work was in maintaining consistency during the transition. We implemented event sourcing patterns where possible and used change data capture to keep systems in sync during the migration period. "What about testing? How do you test 250+ services?" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.

What monitoring and observability did you implement?

" Application Insights everywhere. Custom dashboards for each service tier. Distributed tracing to follow requests across services. Real-time alerting with PagerDuty integration. During migration, we actually had better visibility than the old system ever provided. "How did you handle the database migrations?" Databases were the trickiest part. We used Azure Database Migration Service for the initial sync, but the real work was in maintaining consistency during the transition. We implemented event sourcing patterns where possible and used change data capture to keep systems in sync during the migration period. "What about testing? How do you test 250+ services?" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.

How did you handle the database migrations?

" Databases were the trickiest part. We used Azure Database Migration Service for the initial sync, but the real work was in maintaining consistency during the transition. We implemented event sourcing patterns where possible and used change data capture to keep systems in sync during the migration period. "What about testing? How do you test 250+ services?" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.

What about testing? How do you test 250+ services?

" Automated testing was non-negotiable. Every service had unit tests, integration tests, and contract tests. We built a staging environment that mirrored production and ran full end-to-end tests daily. Load testing happened every weekend to ensure we could handle expected traffic patterns. Why This Project Changed Everything You know what's wild? Just as I was leaving for another opportunity, they decided to move everything to Kubernetes. Part of me wishes I could have stayed for that next chapter. There's something special about being part of a complete infrastructure transformation at this scale. But here's what this project really taught me - infrastructure at scale isn't just about technology. It's about people, processes, and planning. It's about building systems that can evolve, teams that can collaborate across continents, and foundations that enable business growth. We didn't just migrate 250+ microservices. We proved that with the right approach, you can transform the technical foundation of a major logistics company without disrupting the millions of packages flowing through their systems every day. That's the kind of engineering that actually matters. Looking back, this project set the bar for everything I've done since. When you've successfully migrated infrastructure that processes millions in transactions daily, with zero downtime, hitting a deadline that absolutely couldn't slip - well, other challenges start to feel a lot more manageable. That's what enterprise-scale engineering teaches you. It's not just about making things work. It's about making things work reliably, at scale, under pressure, with real business consequences. And honestly? There's nothing quite like it.