Atul Vishwakarma

Thank you, that means a lot. I really like the way you put it — giving back to the community what the community has given you is exactly the kind of mindset I respect. I can also relate to the “love towards tech” part. That’s honestly what keeps me going as well. I’ve been spending more time learning and sharing around DevOps and Cloud Engineering, and it’s always encouraging to connect with people who are building with the same spirit. I’d definitely be open to catching up sometime. I’m not sure if I’ll be able to do it immediately, but I’ll keep Topmate in mind and reach out when I can. Thanks again for the invite and for being so open.

Really enjoyed this guide. AWS Community Builder is one of those programs that looks straightforward from the outside, but once you actually think about the effort behind consistently creating useful technical content, engaging with the community, and staying active in the ecosystem, you realize it’s a serious commitment. I like that this post explains the journey in a practical way instead of making it sound overly glamorous. From my own experience in DevOps and Cloud Engineering, building in public has been one of the most valuable habits. It helps sharpen your understanding, forces you to document what you learn clearly, and naturally connects you with people working on similar problems. That combination of learning, sharing, and community feedback is what makes programs like this so meaningful. Solid write-up overall — especially for people who want to move beyond just consuming content and actually contribute back to the AWS community.

Really enjoyed this post. Event-driven systems always look elegant on paper, but in practice the interesting part is how they behave under load, especially when multiple services, queues, and async steps all start interacting at once. I like that you focused on the load testing angle instead of only talking about the architecture itself, because that’s where real confidence in a system actually comes from. In my own DevOps and cloud work, I’ve seen how important it is to test not just the happy path but also throughput, backpressure, retries, and failure handling in distributed systems. Once you move into event-driven designs, observability and timing become just as important as the code itself. A setup can look clean in the diagram, but the real story shows up when you push it under realistic traffic. This was a solid write-up and a good reminder that performance testing is not just about finding bottlenecks — it’s about understanding the behavior of the whole system under stress.

This was a very clear explanation of public vs private IPs. It’s one of those topics that looks “basic” on paper, but in real cloud environments it becomes critical for getting networking and security right. I like how you kept the examples simple enough for beginners while still explaining why we use each type of address. In my own DevOps and cloud work (mostly on AWS with things like VPCs, subnets, ECS Fargate, etc.), this distinction shows up everywhere — from deciding which services need a public endpoint behind a load balancer, to keeping application containers and databases safely isolated on private IPs. Understanding that mental model early makes it much easier later when you start dealing with routing, NAT gateways, and security groups. Really nice job breaking this down in an approachable way. Posts like this are super helpful for people building their foundations before diving deeper into cloud networking and infrastructure.

This is a really solid beginner-friendly guide to a topic that a lot of teams treat as an afterthought until something goes wrong. I like how you didn’t just say “don’t hardcode secrets” but actually walked through why AWS Secrets Manager is a better long‑term option than .env files or raw environment variables. In my own DevOps and cloud work (mostly on AWS with ECS Fargate and friends), I’ve seen exactly how quickly secrets start to sprawl when you rely on server‑side env files and copy‑pasted configs. Centralizing them in a managed service with IAM‑based access and rotation support makes a huge difference, both for security and for day‑to‑day operations. It also forces you to think more clearly about which service should be allowed to read what. Really appreciate how you kept the explanations approachable without skipping the important security angle. This is the kind of foundation more people need before they start wiring CI/CD pipelines and production workloads. Looking forward to more posts like this.

Really liked this comparison. Containers vs virtual machines is one of those topics that seems simple at first, but once you start working with real deployments, the practical differences become much more important. I think you explained the tradeoff very clearly without overcomplicating it. What I especially liked is how the post focuses on the mindset shift as much as the technology itself. VMs and containers both solve different problems, and understanding when to use each one is what actually matters in real projects. I’ve been spending more time learning Docker, AWS, and DevOps workflows lately, so posts like this help reinforce the fundamentals in a way that feels practical. Great write-up overall.

Thanks for taking the time to reply, really appreciate it. I’ll keep an eye out for your upcoming posts – I’m trying to build a habit of reading and learning from practical content like this regularly. I’ve also started writing weekly technical posts myself around Docker, AWS, and DevOps, mainly to document my own learning journey, so it’s always great to come across writers who explain fundamentals this clearly.

This was a really clear breakdown of the Docker container lifecycle. I like how you kept it focused on the actual commands we use day to day instead of getting lost in too much theory. For someone trying to get comfortable with Docker beyond just docker run, this kind of structured walkthrough is super helpful. What I appreciated most is that you grouped the commands by stage (create, start, stop, inspect, clean up) — it makes it much easier to build a mental model instead of memorizing a random list of flags. That’s exactly the kind of foundation that pays off later when you start working with orchestration tools and CI/CD pipelines. I’ve been spending more time on containers and DevOps lately, and posts like this really help solidify the basics. Great work, looking forward to more content like this.

Really enjoyed this one. Running 8 microservices locally with a single command is exactly the kind of practical setup that saves a lot of friction when you’re actually building and debugging. What I liked most is that this doesn’t just talk about microservices in theory — it shows how to make the developer experience smoother in a real project. The part I appreciate most is the simplicity of the workflow. When local setup is clean, people can focus more on the code and less on spending half the day wiring services together. That’s usually where a lot of teams struggle, so this kind of approach is genuinely useful. I’m also learning more about cloud and DevOps workflows these days, so posts like this are helpful because they connect local development with production thinking in a very practical way. Solid write-up overall.

Thanks for sharing that perspective, really appreciate it. I like how you framed Docker Compose and Kubernetes as a progression instead of competing approaches – that matches how I’ve been thinking about it too. Start with Compose to understand dependencies and behavior, then move to K8s/EKS once you’re ready to harden things for production. I’m currently deep-diving into AWS, containers, and DevOps, so seeing real stories like yours definitely helps shape how I plan my own projects. I’ll keep experimenting and sharing what I learn along the way. Thanks again for taking the time to respond.