Paarth Mahajan

One concept candidates often confuse is that microservices can't be used with Event-Driven Architecture. In today's edition, let's look at Synchronous Vs Event Driven Architecture. 1. Traditional microservice is synchronous i.e. the request and response happens with the same invocation. Whereas with Event Driven, User gets a confirmation that message is inserted into SQS. But he doesn't get the response from the actual message processing by the Lambda in the same invocation. Instead the backend Lambda needs to send response out, in this case, using websocket APIs, to the user. Or the user can query the status afterwards 2. Note on the diagram on the right, the EDA flow is also working with microservice. The microservice hosted by API Gateway is inserting the message into the SQS! 3. With EDA, API Gateway, and Lambda/Database can scale independently. Lambda can consume messages at a rate not to overwhelm the database 4. With EDA retries are built in. With synchronous microservices, if Lambda fails, user need to send the request again. With EDA, once the message is in SQS, even if Lambda fails, SQS will automatically retry Question to readers - have you used EDA in your project? --- Download this and other popular cloud interview questions and answers (FREE): https://lnkd.in/egg_rVWH #systemdesign #aws

274

30 Comments

🚀 Introducing Azure Subnet Peering! A brand-new feature that lets you peer selective subnets between two Virtual Networks (Vnets) instead of peering entire Vnets. Achieve granular connectivity while keeping unwanted traffic at bay. 🔍 Pre-requisites for Subnet Peering: 🔹Both Vnets must have non-overlapping IP address ranges. 🔹Ensure proper network security groups (NSGs) and routing configurations are in place. 🔹Familiarity with Azure CLI/Portal for configuration. 🔹Validate that your subscription and region support the feature. 👍 Advantages of Subnet Peering 🔹 Selective Connectivity: Connect only the required subnets, enhancing security and performance. 🔹Granular Control: Define peering relationships at a micro level. 🔹Cost Efficiency: Lower data transfer costs by limiting exposure to only critical network segments. 🔹Enhanced Isolation: Improved security by isolating non-essential workloads. 🚫 Limitations to Consider: 🔹 Currently, the peering is limited to the specific subnets you choose — you can’t dynamically expand this without reconfiguration. 🔹 Apart from the peered subnets all the other subnets will have the routes to the remote subnets, although the packets would get dropped. 🔹 Potential complexity in managing multiple selective peerings compared to full Vnet peering. 🔹 Must plan for routing adjustments to ensure proper traffic flow between peered subnets. 💡 Industry Use Cases: 🔹 Multi-Tier Applications: Peer only the application and database subnets across environments for controlled access. 🔹 Microservices Architectures: Enable secure communication between microservice clusters while isolating non-critical components. 🔹 Hybrid Deployments: Seamlessly connect on-premises or other cloud segments with only essential subnets in Azure. 🔹 Dev/Test Environments: Allow developers to interact with production-like subnets without exposing the entire network. Are you ready to transform your Azure networking strategy? Let’s discuss how this feature can power your next project! #Azure #Networking #CloudComputing #SubnetPeering #AzureCLI #TechInnovation #microsoft Microsoft OpsTree Solutions Azure Developer Community Sandeep Rawat Shankar Prasad Jha Yogesh Batish Arpit Jain

35

4 Comments

Isn’t running VMs on OpenShift just reinventing OpenStack?” Not even close. This one misconception is stopping teams from building a true hybrid cloud — and it’s slowing down careers in platform engineering. 🟦 OpenStack Admin • Strong foundation in infra: compute, storage, networking • Perfect for managing massive VM workloads • Powers private cloud at scale ✅ 🟧 OpenShift Virtualization Admin • Runs VMs and containers side by side • Unified management for pods + VMs • Developers keep a Kubernetes-native workflow • Less siloing, more collaboration ⚡ 🔴 OpenShift on OpenStack (The Hybrid Cloud Pick) • Enterprise-grade stack for VM + container coexistence • OpenStack = infra backbone, OpenShift = platform brain • Consistent automation, GitOps, RBAC, and monitoring out of the box • Fortune 500s are betting on it for modernization 🌍 💡 So if OpenStack is the foundation, and OpenShift Virtualization is the bridge… OpenShift on OpenStack is the skyscraper. You don’t just manage VMs — you design a platform. You don’t just deploy containers — you define the enterprise operating model. 👇 Comment “Hybrid Roadmap” and I’ll DM you a free guide comparing OpenStack vs OpenShift Virtualization vs OpenShift-on-OpenStack — tailored to your career path. #OpenShift #OpenStack #HybridCloud #PlatformEngineering #VMs #Kubernetes #CloudNative #DevOps #TechCareers #Cloud2025 #vivekyoganand #vyog

37

2 Comments

My run-mcp-servers-with-aws-lambda library now supports Bedrock AgentCore Gateway! Run your existing stdio-based MCP server in a Lambda function, and let the Gateway take care of implementing the MCP HTTP transport protocol https://lnkd.in/g-Q67G3N

376

8 Comments

Many teams lock down their clusters with RBAC and call it secure. But in production-grade Kubernetes, security is multi-dimensional. Here are 4 core mechanisms every team should understand and implement in depth: 1️⃣ Secure Network Channels Every control-plane ↔️ node ↔️ pod communication must travel over encrypted channels. TLS everywhere: API Server, etcd, kubelet, and admission plugins should all run with strict TLS configs. mTLS for service-to-service (via service mesh like Istio/Linkerd) ensures zero-trust at pod level. Misconfigured certs or plaintext channels aren’t just risky, they're an open invitation. 2️⃣ Authentication, Authorization & Admission Controllers Authentication: who are you? (certs, OIDC, service accounts). Authorization (RBAC): what can you do? (granular verbs like get, list, delete). Admission Controllers: policy gatekeepers. They validate and mutate objects before they hit etcd. Example: PodSecurityAdmission can deny privileged containers or enforce restricted profiles. Think of them as the border guards at your cluster’s API boundary. 3️⃣ Network Policies By default, pods talk to any pod, anywhere. That’s great for dev, but a nightmare for prod. NetworkPolicies let you whitelist ingress/egress at the namespace or pod selector level. Combine with CNI providers (Calico, Cilium) to enforce L3/L4 isolation. Integrate with service mesh for L7 (HTTP/GRPC) policies. In short: NetworkPolicies are your firewall in a microservices world. 4️⃣ Container & Pod Security Even with strong perimeters, the container runtime is the last line of defense. Use SecurityContext to enforce non-root, drop Linux capabilities, read-only filesystems. Apply PodSecurity Standards (baseline/restricted) across namespaces. Enforce Seccomp/AppArmor profiles to minimize syscall surface. For sensitive workloads: run in sandboxed runtimes (gVisor, Kata). If you wouldn’t give a developer root on your VM, don’t let your pod run as root. ✅ Kubernetes security is not a single feature, it’s a pipeline of checks and enforcements. Each layer, from encrypted traffic to workload isolation reduces the attack surface. Miss one, and you’ve left a door wide open. Which of these 4 layers do you see most often overlooked in real-world clusters? Feel free to slide into my DMs for collaborations and partnerships! I’m passionate about simplifying technical content creation and driving community engagement—always open to connecting! 🔁 Repost to help others find it, sharing is caring 👨‍💻 Tag someone learning anything and everything Cloud-Native, Kubernetes & AIOps 💾 Save this post for future reference #CloudComputing #CloudNative #DevOps #Kubernetes #K8sSecurity #TechTips #hellodeolu #technicalmarketing #devrel

45

8 Comments

Back to Basics: Node Autoscaling in Kubernetes on AWS As your Kubernetes workloads grow, scaling your EC2 compute infrastructure becomes critical to maintaining performance and optimizing cost. In AWS EKS, you have two primary node autoscaling options both sponsored by SIG Autoscaling: Cluster Autoscaler (CA) Karpenter Both tools aim to provision new nodes for unschedulable pods and consolidate underutilized ones but their approaches differ significantly. Cluster Autoscaler (CA) A mature, Kubernetes-native component that scales pre-configured node groups (ASGs) based on workload needs. What CA does: Adds nodes when pods can’t be scheduled due to resource shortage. Removes nodes when workloads are consolidated elsewhere. Works well with AWS Auto Scaling Groups (ASGs). Best for: Environments needing predictable scaling using existing node groups. Karpenter An open-source project designed for faster, smarter, and more flexible autoscaling. What Karpenter does: Detects unschedulable pods instantly. Launches right-sized nodes in seconds (not minutes). Handles the entire node lifecycle: provisioning, upgrading, and refreshing. Key benefits: Doesn’t rely on ASGs or pre-configured node groups. Allows auto-provisioning of compute capacity based on workload constraints. Best for: Teams prioritizing agility, flexibility, and cost efficiency. Combine Node & Workload Autoscaling To scale effectively, combine: Horizontal Pod Autoscaling (HPA): Adjusts the number of replicas based on real-time load. Node Autoscaling (CA/Karpenter): Provisions compute to support those replicas. Together, they ensure your app: Scales on demand during spikes. Shrinks cost-efficiently during idle times. Final Thoughts: Whether you're scaling for reliability or optimizing for cost, Cluster Autoscaler offers stability, while Karpenter delivers speed and flexibility. Choose based on your workload patterns, team maturity, and cloud architecture. Follow me for more such content. I write on real world experiences related to AWS, Kubernetes, Serverless, System Design, Migration/Modernization, Security, Compliance, Generative AI.

46

6 Comments