Backend Choices Become Frontend Problems

🚀 Day 22/30 – Docker Compose (Environment Variables & Scaling) Today, I focused on making my Docker setup more practical and production-ready. 📊 What I did: • Used a .env file to securely store sensitive data (DB credentials) • Connected application and database using Docker Compose • Avoided hardcoding values inside the code • Scaled the application to run multiple containers 🛠️ Commands I used: • docker-compose up --scale web=3 • docker-compose config • docker-compose down 💡 Key Takeaway: Hardcoding values ❌ Using .env = Secure, flexible, and easy configuration ✅ 📌 Simple Architecture Flow: User → App Containers (web1, web2, web3) → Database ⚡ Step by step, moving closer to real-world DevOps practices. #Docker #DevOps #LearningInPublic #CloudComputing #SoftwareDevelopment

🚨 𝐌𝐲 𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 𝐩𝐨𝐝 𝐤𝐞𝐩𝐭 𝐫𝐞𝐬𝐭𝐚𝐫𝐭𝐢𝐧𝐠 𝐞𝐯𝐞𝐫𝐲 𝐟𝐞𝐰 𝐡𝐨𝐮𝐫𝐬… 𝐚𝐧𝐝 𝐈 𝐡𝐚𝐝 𝐧𝐨 𝐜𝐥𝐮𝐞 𝐰𝐡𝐲. No errors in the logs. No crash messages. Everything looked normal. Still… the pod kept disappearing. 𝐎𝐮𝐭 𝐨𝐟 𝐜𝐮𝐫𝐢𝐨𝐬𝐢𝐭𝐲, 𝐈 𝐫𝐚𝐧: kubectl describe pod <pod-name> And found the real reason: 💥 𝐎𝐎𝐌𝐊𝐢𝐥𝐥𝐞𝐝 (𝐄𝐱𝐢𝐭 𝐂𝐨𝐝𝐞 137) That’s when it hit me, the application wasn’t crashing… Kubernetes was killing it due to memory exhaustion. 𝐇𝐞𝐫𝐞’𝐬 𝐰𝐡𝐚𝐭 𝐈 𝐢𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐝 👇 1️⃣ 𝐍𝐨 𝐦𝐞𝐦𝐨𝐫𝐲 𝐥𝐢𝐦𝐢𝐭𝐬 𝐝𝐞𝐟𝐢𝐧𝐞𝐝 The pod was allowed to consume unlimited memory. Eventually, it exhausted the node’s memory and got terminated. 👉 𝐅𝐢𝐱: 𝐀𝐥𝐰𝐚𝐲𝐬 𝐝𝐞𝐟𝐢𝐧𝐞 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬 𝐚𝐧𝐝 𝐥𝐢𝐦𝐢𝐭𝐬 𝘳𝘦𝘴𝘰𝘶𝘳𝘤𝘦𝘴:  𝘳𝘦𝘲𝘶𝘦𝘴𝘵𝘴:   𝘮𝘦𝘮𝘰𝘳𝘺: "256𝘔𝘪"  𝘭𝘪𝘮𝘪𝘵𝘴:   𝘮𝘦𝘮𝘰𝘳𝘺: "512𝘔𝘪" 2️⃣ 𝐉𝐕𝐌 𝐰𝐚𝐬 𝐧𝐨𝐭 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫-𝐚𝐰𝐚𝐫𝐞 The Java application calculated heap size based on the node’s total memory, not the container limit. 👉 𝐅𝐢𝐱: 𝐓𝐮𝐧𝐞 𝐉𝐕𝐌 𝐟𝐨𝐫 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭𝐬 -𝘟𝘟:+𝘜𝘴𝘦𝘊𝘰𝘯𝘵𝘢𝘪𝘯𝘦𝘳𝘚𝘶𝘱𝘱𝘰𝘳𝘵 -𝘟𝘟:𝘔𝘢𝘹𝘙𝘈𝘔𝘗𝘦𝘳𝘤𝘦𝘯𝘵𝘢𝘨𝘦=75.0 3️⃣ 𝐌𝐞𝐦𝐨𝐫𝐲 𝐥𝐞𝐚𝐤 𝐢𝐧 𝐭𝐡𝐞 𝐚𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 Even after setting limits, memory usage kept increasing over time. Root cause: A background process was holding objects and not releasing them. 👉 Fix: Monitor memory trends using Prometheus and Grafana If memory steadily increases and doesn’t drop, it’s likely a memory leak. 💡 𝑲𝒆𝒚 𝒕𝒂𝒌𝒆𝒂𝒘𝒂𝒚𝒔: • Always define memory requests and limits • Make your application container-aware • Monitor trends, not just logs • OOMKilled = container terminated by the system, not an app crash This is one of the most common (and confusing) issues in Kubernetes. Have you faced something similar? 𝑾𝒐𝒖𝒍𝒅 𝒍𝒐𝒗𝒆 𝒕𝒐 𝒉𝒆𝒂𝒓 𝒉𝒐𝒘 𝒚𝒐𝒖 𝒅𝒆𝒃𝒖𝒈𝒈𝒆𝒅 𝒊𝒕 👇 #Kubernetes #DevOps #K8s #CloudNative #SRE #PlatformEngineering

When I think about the years I spent building microservices in .NET at a few real moments stick with me — not the diagrams or buzzwords, but the times I really learned something hard. Like that week we realized our services were failing because we hadn’t even thought about timeouts… and production was like “hello?” 🤦♂️ Here are a few things I still find myself thinking about, even now: • Clear responsibilities matter — when a service isn’t sure what it owns, you end up rewriting the same logic in multiple places. That gets expensive fast. • Sync vs async isn’t just technical jargon — it’s a choice that decides how your system behaves under pressure. Sometimes REST/gRPC works. Other times, queues and events save the day. • Expect failure — if you don’t build for retries, fallbacks, circuit breakers, it will bite you. That’s not theory, it’s experience. • Automate the mundane — deployments, tests, builds… every bit you automate gives you fewer late nights. • Logs and traces become your best friends — when something goes sideways, you want to see what’s happening, not guess at it. I’m still figuring things out — always will be — but these lessons have stuck with me longer than most documentation. If you’ve done distributed systems too, what’s one thing you learned the hard way? #dotnet #microservices #aspnetcore #softwaredevelopment

Built and published my SimpleTimeService – End-to-End DevOps Challenge 🚀 This project is more than a simple web app — it’s a complete DevOps workflow built to simulate production-style delivery. What’s included: 🔹 Minimal Python web application (FastAPI) 🔹 Secure Docker containerization (non-root, read-only filesystem) 🔹 Kubernetes deployment with probes, limits, and service exposure 🔹 Infrastructure provisioning with Terraform (AWS VPC + EKS) 🔹 CI/CD automation using GitHub Actions 🔹 Security scanning using Trivy 🔹 Automated Kubernetes manifest updates with immutable image tags Tech stack used: 🐳 Docker ☸️ Kubernetes (EKS) 🏗 Terraform ⚙️ GitHub Actions ☁️ AWS 🐍 FastAPI Pipeline flow: Code Push → Lint → Build → Test → Security Scan → Push Image → Update Manifest → Deploy Production practices implemented: ✅ Non-root container execution ✅ Read-only filesystem ✅ Resource requests & limits ✅ Liveness & readiness probes ✅ Vulnerability scanning ✅ Immutable image versioning ✅ Infrastructure as Code GitHub repo live now 💻 https://lnkd.in/gANtZR8V #DevOps #AWS #Kubernetes #Terraform #Docker #GitHubActions #EKS #CloudNative #PlatformEngineering #DevSecOps

Spent the last few weeks heads down building LaunchForge, a SaaS-style project where I focused on applying backend and system design concepts in practice. No tutorials. Just build → break → fix → repeat. Here’s what I actually shipped: 🧠 What I Built Modular backend architecture (routes → services → database layer) Implemented caching + query optimization to reduce unnecessary DB load Added rate limiting to protect APIs from abuse Designed APIs with cleaner request flow to minimize redundant calls ⚙️ Tech Stack → Node.js, Express.js → PostgreSQL + Prisma ORM → React / Next.js → Docker, Prometheus, Grafana ⚡ Performance Work Reduced redundant database queries using caching logic Optimized slow queries using indexing and better schema design Implemented basic rate limiting (middleware-based) Improved API response consistency by removing unnecessary calls 📊 Monitoring & Observability Integrated Prometheus for metrics collection Built Grafana dashboards to track request rate, latency, and system health 🚧 Next Focus → Redis for distributed caching → Advanced rate limiting (production-level) → Better scaling strategies 💡 Key Realization There’s a big difference between knowing tools and building systems that can survive real-world load. This project pushed me from theory into that gap, and I’m actively closing it. Build like it’s going to production. Even if it never does. #Backend #FullStack #DevOps #SystemDesign #BuildInPublic #SaaS #LearningByBuilding

🚀 Building a 3-Tier Kubernetes App I just deployed a full-stack application on Kubernetes to master containerization, orchestration, and real-world troubleshooting. What I Built: - Frontend (React + Nginx) - Backend (Node.js + Express) - Database (PostgreSQL) Users submit messages → stored in the database → displayed in the UI. Simple but powerful! 💪 The Tech Stack: Docker → Docker Hub → Kubernetes (Minikube) Key Learnings: ✅ Containerized each tier independently ✅ Configured Nginx reverse proxy for service-to-service communication ✅ Deployed with Kubernetes manifests for reproducibility ✅ Debugged real issues: service discovery, build errors, data persistence Want to try it? git clone https://lnkd.in/gxK49hKm cd project kubectl apply -f k8s/ minikube service frontend-service This project shows how DevOps practices bring multiple technologies together into a working system. Each challenge taught me something new about how containers and orchestration work in production. 🎯 Ready to build the next one! 🚀 #DevOps #Kubernetes #Docker #ContainerOrchestration #CloudNative #FullStack #Learning

🐳 Docker doesn't have to be confusing- here's the smart way to build Node.js images that actually work everywhere. You know that "works on my laptop, breaks on server" nightmare? This Dockerfile fixes it with pro tricks I've used in real deploys. What makes this gold: Starts super lean with node:20-alpine (way smaller than full Node images) Copies package*.json first—Docker caches your npm ci forever unless deps change. Game-changer for CI/CD speed! Runs as appuser (not root)—security teams love this, blocks container breakouts Only prod deps with --only=production. No dev bloat in your final image. Real talk: Most copy-paste Dockerfiles from StackOverflow. This one's optimized—cuts image size 70-80%, builds 3x faster. Perfect for your K8s journey. DevOps folks, what's your Docker hack? Still doing docker run roulette? 😅 "Quick Beginner Breakdown" Docker = same app environment everywhere. Here's what this nails: Image size: Alpine base + no dev deps = tiny containers Build speed: Layer caching (package.json first) = fast rebuilds Security: Non-root user = safer in production Portability: One Dockerfile, zero "my machine" excuses Try it: docker build -t my-node-app . Pro tip—push to registry, deploy to K8s, sleep easy. 🚀 #Docker #DevOps #NodeJS #Containers #CI_CD

Earlier today, we had a pre-demo session with Samkeliso Dube and co-mentor Onuche Paul, where Samkeliso Dube walked us through a clean and production-focused implementation of a Multi-Stage Docker Build for a React App (Builder → Nginx Runtime). Here’s a quick look at what we built and validated: Topic: Multi-Stage Docker Build for React Application Focus: Optimizing container images for production This wasn’t just theory. We worked through a practical, real-world containerization workflow: Built a single-stage Docker image as a baseline Designed a multi-stage Dockerfile: Used Node.js as the builder stage Used NGINX as a lightweight runtime Served the React app as static files in a production-ready container Verified application access via browser (:3000 / :80) Compared image sizes and observed clear reduction in footprint. More importantly, we broke down the why behind this approach: Eliminating build tools from the final image reduces attack surface. Smaller images improve deployment speed in CI/CD pipelines. Layer caching strategy improves build efficiency. Using Docker properly aligns with production best practices. Thanks to Pravin Mishra and our lead mentor Praveen Pandey for the continuous guidance and support. If you're working in DevOps, cloud engineering, or modern application deployment, this is a foundational pattern you need to master. Let’s build. Let’s ship. Let’s optimize. #DevOps #Docker #NGINX #CloudEngineering #CI_CD #ReactJS #Containerization #TechLearning #DMI

 Docker changed how I think about software. Here are the 5 commands I use every single day. When I started using Docker 3 years ago, I spent 2 hours Googling commands for every task. Now I have a mental shortlist I use daily. Here it is: 1. docker compose up -d   Spin up your entire stack in the background. Database, backend, frontend — all at once. 2. docker logs -f [container]   Follow logs in real time. Essential for debugging running containers. 3. docker exec -it [container] bash   SSH into a running container. Life-saving when you need to debug inside. 4. docker system prune -a   Clear all unused images, containers, volumes. Frees up gigabytes fast. 5. docker build --no-cache -t myapp .   Force a clean rebuild. Use this when cached layers are causing mysterious bugs. Bonus tip: Always use .dockerignore. Just like .gitignore but for Docker builds. Skipping it makes your images unnecessarily large. Save this. Your future self will appreciate it. What Docker command should be on this list? Add it below. #Docker #DevOps #SoftwareEngineering #BackendDevelopment #OpenToWork

Every new project or team member used to trigger the same groan-inducing ritual: manually running ten distinct commands to set up their local development environment. Clone repos, install Node.js dependencies, configure Docker Compose for PostgreSQL, Redis, Kafka, set environment variables, run migrations – it was a repetitive, error-prone gauntlet. This wasn't just tedious; it bottlenecked onboarding, introduced inconsistencies across machines, and wasted precious engineering hours. My solution was a dedicated `init.sh` bash script. Leveraging AI, I rapidly scaffolded the initial script and refined complex logic for different environment permutations. This master script now orchestrates the entire process: from checking prerequisites and cloning all necessary repositories to installing `npm` dependencies for our Next.js and Node.js services, spinning up critical backend services like PostgreSQL and Redis via Docker Compose, applying `Prisma` migrations, and even seeding local databases. What was once an hour-long, multi-step manual process is now a single `chmod +x init.sh && ./init.sh` command. We've slashed onboarding time for new engineers from half a day of tedious setup to under 15 minutes. This isn't just about saving time; it ensures consistency, reduces "it works on my machine" issues, and frees up senior engineers from basic setup support tasks. Investing in robust internal automation, even for seemingly mundane tasks like dev setup, is a force multiplier for productivity. It accelerates team velocity, improves developer experience, and allows engineers to focus on building features, not fighting environments. #ShellScripting #BashScript #Automation #DevOps #DeveloperExperience #EngineeringProductivity #TechLeadership #CTO #Founders #SoftwareDevelopment #NodeJS #Docker #DockerCompose #AWS #Backend #SystemDesign #InternalTools #AIAutomation #ProductivityHacks #EngineeringCulture #Scalability #TechStrategy #CodingBestPractices #MERNStack #NextJS