The latest articles on DEV Community by Nivetha G (@nivetha_g_c66d83c64606851). https://dev.to/nivetha_g_c66d83c64606851 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3724559%2Fb59e6e91-38e7-4058-81fc-684947c03983.png https://dev.to/nivetha_g_c66d83c64606851 en Nivetha G Thu, 22 Jan 2026 04:47:12 +0000 https://dev.to/nivetha_g_c66d83c64606851/rethinking-discovery-for-large-scale-vmware-to-aws-migrations-3lkl https://dev.to/nivetha_g_c66d83c64606851/rethinking-discovery-for-large-scale-vmware-to-aws-migrations-3lkl <p>When I started looking at bigger migrations, I realized something: manual discovery just doesn’t work at scale. Doing a few VMs by hand is fine. Doing thousands? Not even close.</p> <p>I wanted a way to get accurate information about all the workloads without manually opening spreadsheets and notes for every VM. That’s when I started experimenting with automation and AWS tools — not to complete a project for anyone, but just to see what was possible.</p> <h2> Why discovery is hard at scale </h2> <p>The challenge is not collecting the data — it’s understanding it. When you’re looking at thousands of VMs, you want to know things like:</p> <ul> <li>Which VMs are similar and can be grouped together</li> <li>Which workloads are heavy and which are light</li> <li>Dependencies between systems</li> <li>Which VMs are ready to move and which need work</li> </ul> <p>If you try to track all that manually, things get lost. Decisions end up being guesses instead of being based on real data.</p> <h2> Starting with automation </h2> <p>I started with the AWS agentless connector. It lets you gather VM and system info without touching each machine individually. That immediately made the process manageable. Suddenly, I could get a full view of the environment consistently — and without installing agents everywhere.</p> <p>Having clean, structured data is half the battle. Once you have it, you can start thinking about patterns instead of just numbers.</p> <h2> Adding AI to make sense of it </h2> <p>Once the data was collected, the next question was: how do I make sense of thousands of rows? That’s where I tried using AWS AI and Transform services.</p> <p>I didn’t want AI to make decisions for me. What I wanted was help in spotting patterns and outliers:</p> <ul> <li>Grouping similar workloads</li> <li>Highlighting unusual VMs that might need extra work</li> <li>Surfacing clusters of resources that could move together</li> </ul> <p>This let me focus on the architecture instead of drowning in spreadsheets.</p> <h2> What I learned from the experiment </h2> <p>A few things became clear:</p> <ul> <li>Automation is necessary for scale, but insight is still human-driven.</li> <li>AWS-native tools like the agentless connector save a ton of effort.</li> <li>AI is useful for surfacing patterns, not for making final migration choices.</li> <li>Structured discovery early can prevent headaches later in the migration.</li> </ul> <p>Even though this started as just a personal experiment, it completely changed how I approach migration planning.</p> <h2> Wrapping up </h2> <p>For anyone planning large-scale VMware to AWS migrations, the key is to stop thinking of discovery as a checklist. Think of it as building a foundation: structured data, automation to scale, and AI to help interpret it.</p> <p>It doesn’t make decisions for you, but it makes the problem manageable, predictable, and less stressful.</p> <h2> About me </h2> <p>Hi I'm Nivetha Gopi - Sr. Solutions Architect with hands-on experience supporting, automating, and optimizing mission-critical workloads on AWS. I work closely with cloud infrastructure, DevOps, and automation, and strongly believes that growth comes not just from what we know, but from how effectively we figure out what we don’t.</p> aws cloud Nivetha G Thu, 22 Jan 2026 04:32:11 +0000 https://dev.to/nivetha_g_c66d83c64606851/building-a-request-based-pipeline-to-automate-aws-services-setup-3bj6 https://dev.to/nivetha_g_c66d83c64606851/building-a-request-based-pipeline-to-automate-aws-services-setup-3bj6 <p>When I started working more deeply with AWS and DevOps, one thing became very clear to me. A lot of time goes into doing the same setup again and again. Different use cases, different names, but mostly the same services and patterns underneath. Every time, someone had to create repos, write build scripts, and make sure services were created in the right order.</p> <p>I wanted to see if this could be simplified. Instead of starting with infrastructure or code every time, I started thinking — what if everything started with a simple request?</p> <p>That thought pushed me to experiment with a request-driven pipeline that could handle most of the repetitive work on its own. This was not something I built for a client or delivery work. It was something I explored out of curiosity and frustration with manual steps.</p> <h2> What was not working for me </h2> <p>Before automation, the usual flow looked like this:</p> <p>First, we would try to understand what services were needed.<br> Then repositories would be created manually, often by copying an existing one.<br> Build and deployment scripts were written or reused with small changes.<br> Finally, AWS services were deployed, but only after figuring out which one had to come first.</p> <p>This worked, but it was slow. It also depended too much on people remembering the right sequence. If something was missed, the deployment failed and we had to go back and fix it.</p> <h2> Starting from a simple request </h2> <p>Instead of starting from infrastructure, I decided to start from inputs.</p> <p>I created a simple form where someone could enter:</p> <ul> <li>Service names</li> <li>Type of AWS services required</li> <li>Basic configuration details</li> </ul> <p>Once the form was submitted, it triggered a CI/CD pipeline. From that point on, there was no manual setup. The pipeline used the inputs as variables and replaced them dynamically in the code and templates.</p> <p>This alone removed a lot of repeated effort.</p> <h2> How the pipeline behaved </h2> <p>At a high level, the pipeline did the following:</p> <ul> <li>Took the request inputs and validated them</li> <li>Created a repository with a predefined structure</li> <li>Generated build and deployment scripts</li> <li>Triggered resource creation using CloudFormation templates and AWS SDKs</li> </ul> <p>One important thing I learned early was that sequencing mattered a lot. For example, API Gateway needed to exist before Lambda integrations could work properly. So the pipeline had to be very clear about the order in which resources were created.</p> <p>Once I fixed the sequencing logic, deployments became far more predictable.</p> <p>Things I didn’t expect</p> <p>Some of the harder problems were not technical.</p> <p>Input validation was tricky. If one variable was missing or incorrectly mapped, the pipeline would fail in a way that wasn’t always obvious. Debugging those failures forced me to improve error handling and logging.</p> <p>I also had to think more carefully about flexibility. I didn’t want the pipeline to work for just one scenario. I wanted it to be reusable without becoming too complex.</p> <h2> What this taught me </h2> <p>This experiment changed how I look at automation.</p> <p>It’s easy to focus on tools, but the real value came from designing the flow correctly. Once the design was right, the tools became secondary. I also realised how powerful small, well-structured inputs can be when they drive infrastructure through code.</p> <p>Most importantly, it pushed me to think about consistency and guardrails instead of one-off solutions.</p> <h2> Closing thoughts </h2> <p>This started as a learning exercise, but it helped me understand how request-driven automation can simplify DevOps workflows in AWS. It made setups faster, more consistent, and easier to reason about.</p> <p>More than anything, it changed how I approach automation — not as something that replaces people, but as something that removes repetitive work so teams can focus on better decisions.</p> <h2> About me </h2> <p>Hi I'm Nivetha Gopi - Sr. Solutions Architect with hands-on experience supporting, automating, and optimizing mission-critical workloads on AWS. I work closely with cloud infrastructure, DevOps, and automation, and strongly believes that growth comes not just from what we know, but from how effectively we figure out what we don’t.</p> aws devops cloud