glueckkanja AG’s Post

My team kept asking why my Claude Code tokens were burning so fast. The answer was sitting in their MCP config the whole time. Last week I asked Claude Code to pull a few Jira tickets via the Atlassian MCP. 50k tokens gone before I got a useful answer. The MCP had to explore first — list projects, fetch issue types, discover field schemas, find the cloud ID, then run the query. By the time I had my tickets, half my window was burned on discovery I didn’t care about. jira-cli would’ve done it in one command. Here’s what most people miss: every MCP you connect loads its full tool schema into context at session start — whether you use it or not. Connect five MCPs, and you’ve burned 50k+ tokens before typing your first prompt. CLI tools work differently. Claude already knows git, gh, kubectl, aws from training. Zero schema to load. Just runs the command, reads stdout, done. My rule now: → Mature CLI exists? Use it. (gh, kubectl, aws, jira-cli, gcloud) → No good CLI? MCP is your friend. (Notion, Linear, Granola) → Audit before each session. Disable MCPs you won’t use. Tokens are the new latency. Treat them like it. What’s your token-saving trick?

“Shuru toh karo, behtar baad mein bana lena.” I heard this somewhere recently, and it stayed with me. In tech, especially as engineers, we often delay starting because we can already see the flaws before writing the first line of code. We overthink: - What if the architecture isn’t scalable? - What if the POC fails? - What if someone already built this? - What if it’s not production-ready? And because of that, a lot of good ideas remain stuck in Jira boards, Notion pages, or just inside our heads. Some of the best things I’ve worked on as a Cloud Engineer started messy: - Scripts that weren’t optimized - CI/CD pipelines patched together initially - Small automation ideas that looked insignificant at first - Side projects with no “perfect” roadmap But once they started, they evolved. I’ve realized momentum solves more problems than overplanning ever will. The same applies outside work too. Starting fitness. Starting content. Starting conversations. Starting a business idea. Starting something that genuinely excites you. Version 1 doesn’t need to impress anyone. It just needs to exist. Because clarity usually comes after action, not before it.

📝 New blog published on AWS Builder Community! Integrating Kiro with the GitLab MCP Server: A Complete Guide Proud to co-author this blog alongside Mark Kriaf 🙌 Your Git workflows — issues, merge requests, pipelines, project data — are now accessible directly from Kiro via GitLab's MCP server. No context switching between your IDE and GitLab UI. GitLab supports MCP as an open standard, exposing a server that gives AI tools secure access to your projects, issues, merge requests, and CI/CD pipelines. When connected to Kiro, you get a natural language interface to your entire GitLab workflow. In this guide, we walk through: 🔹 Setting up the GitLab MCP server — configuration, authentication (PAT or OAuth), and connecting to Kiro via mcp.json 🔹 Key capabilities — browse repos, search issues, review merge requests, check pipeline status, and manage project data from within Kiro 🔹 Real-world developer workflows — code review prep, issue triage, and pipeline debugging without leaving your development environment 🔹 Enterprise considerations — self-managed GitLab instances, access scoping, and security best practices 👉 Read the full guide: https://lnkd.in/g3xvtES8 Patrick McDowell Srinivas Kesanapally Rohan Karmarkar Carmen Puccio Arundeep Nagaraj Dan Kiuna Chris Grusz Mona Chadha #AWS #Kiro #GitLab #MCP #DevOps Kiro Amazon Web Services (AWS) GitLab #AWSPARTNERS

While deploying an application using Docker and AWS, one thing became very clear: The challenge was not the technology itself. It was the structure behind it. Before everything works smoothly, you have to be clear on: • How the application starts? • What each service depends on? • How components connect to each other? • What should happen when something fails? Without that clarity, even simple deployments become difficult to manage. Tools like Docker make it easier to run systems, but they don’t remove the need for structure. If anything, they make gaps more visible. When the structure is clear, deployment becomes straightforward. When it isn’t, every step feels harder than it should.

You wrote Terraform last week. IBM owns it now. Your licensing exposure changed in December 2024 and nobody told your legal team. Despite writing Terraform code just last week, a shocking number of engineers remain entirely asleep at the wheel regarding IBM's $6.4 billion acquisition of HashiCorp and the subsequent shift to a restrictive Business Source License. If your company sells SaaS or managed services and you are still blindly running configurations in production without a legal review, you are actively gambling with your licensing exposure. While the broader engineering community ignores this strategic shift, enterprise giants like Fidelity have already migrated millions of resources to Open Tofu, a CNCF-backed project that offers native state encryption and serves as a trivial, drop-in replacement for existing setups. The hard-earned lesson from managing infrastructure at Conmet where our team ran Terraform and CloudFormation across AWS EKS while initially remaining unaware of these shifting licensing tides is that developers rarely track the ground moving beneath their own tools. Ultimately, the true challenge of migrating isn't rewriting the infrastructure code itself, but rather untangling the surrounding governance and state management workflows; if you cannot explicitly explain to your CTO what this acquisition means for your overall IaC strategy, you aren't actually a senior engineer, but rather just an experienced one relying on inertia dressed up as an architectural decision.

💡 Just wrapped up an advanced deep dive into HashiCorp Terraform. I wanted to level up my Infrastructure as Code (IaC) skills, moving past basic resource provisioning into production-grade architecture. Here is the technical stack and concepts I focused on: State Optimization: Implemented workspace separation and state locking via remote backends. Dynamic Configurations: Utilized advanced expressions, for_each loops, and complex variable validation. Module Architecture: Built reusable, version-controlled modules to scale multi-region deployments. Security & Testing: Integrated automated linting, security scanning, and cost estimation into the pipeline. Ready to apply these automated, scalable workflows to my next cloud project. #Terraform #HashiCorp #IaC #DevOps #CloudArchitecture Check it out: https://lnkd.in/gfgfAVAc #terraform.

𝗜 𝗽𝗮𝘀𝘀𝗲𝗱 𝘁𝗵𝗲 #𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗔𝘀𝘀𝗼𝗰𝗶𝗮𝘁𝗲 (𝟬𝟬𝟰) 𝗲𝘅𝗮𝗺. 𝗛𝗲𝗿𝗲 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗻𝗼𝘁𝗲𝘀 𝗜 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗴𝗲𝘁 𝘁𝗵𝗲𝗿𝗲. 29 days of learning in public. Every objective, written up and shared. This is the full set. A few things that actually showed up on the exam and are worth knowing cold: • The cloud block replaces the backend when using HCP Terraform. You cannot use both. That one catches people off guard. • terraform validate only checks the config structure. It won't catch invalid credentials or missing resources. A config can pass validation and still fail on plan. • sensitive = true masks CLI output. The state file still stores the value in plain text. Those are two different problems. • for_each requires a map or set - not a list. count uses numbers. Know when to use each. • HCP Terraform workspaces and CLI workspaces share the same word and nothing else. HCP workspaces are full collaboration environments. CLI workspaces are just named state files. • Module versions are not tracked in .terraform.lock.hcl - only provider versions are. Git modules pin via ?ref= in the source string, not the version argument. • Terraform taint is deprecated. Use -replace flag instead. • You cannot use variables, locals, or expressions inside a backend block. Everything must be hardcoded or passed via -backend-config. 𝗧𝗵𝗲 𝗳𝘂𝗹𝗹 𝗻𝗼𝘁𝗲𝘀 𝗰𝗼𝘃𝗲𝗿 𝗮𝗹𝗹 𝟴 𝗼𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗲𝘀 - IaC fundamentals, core workflow, configuration, modules, state management, maintaining infrastructure, and HCP Terraform. Dropping them in the comments. I've tried my best to cover almost all the topics that are important for the exam. If you're preparing for the same exam, I hope these save you some time. 𝙊𝙣𝙚 𝙥𝙚𝙧𝙨𝙤𝙣𝙖𝙡 𝙩𝙞𝙥: Take it easy and focus more on fundamentals. All the very best to those preparing for the exam 👍. #Terraform #TerraformAssociate #HashiCorp #DevOps #CloudEngineering #InfrastructureAsCode #BuildInPublic

Passing the Terraform Associate (004) meant 29 days of notes. I am sharing them so you don't have to start from scratch. Full notes - all 8 objectives covered. Please share this post with anyone preparing for the exam. #Terraform #TerraformAssociate #HashiCorp #DevOps #CloudEngineering #InfrastructureAsCode

𝗘𝗖𝗦 𝘃𝘀 𝗘𝗞𝗦 is something I’ve been thinking about more as I work deeper with Kubernetes. From my experience with ECS Fargate, I appreciated how straightforward the operational model can be, with Terraform managing infrastructure and GitHub Actions supporting CI/CD. ECS works well when you want to run containers on AWS without taking on the full complexity of Kubernetes. With EKS, you gain more: • flexibility • portability • control • ecosystem tooling • advanced orchestration But you also take on more: • operational responsibility • platform complexity • troubleshooting depth • security considerations • team knowledge requirements The way I see it: 𝗘𝗖𝗦 is great when simplicity and AWS-native operations are the priority. 𝗘𝗞𝗦 makes more sense when teams need Kubernetes-native workflows, scalability, flexibility, and more advanced orchestration capabilities. Neither is automatically better. It depends on what the application needs and how much operational complexity the team can realistically support.

Your VPC Lattice deployment passes every validation check. IAM auth is configured. Health checks return green. The service is live. And then production traffic times out, and the logs tell you nothing useful. Most teams spend their first week with Lattice debugging the wrong layer. The auth configuration, the listener rules, the IAM policies, all of it looks correct. The actual problem sits somewhere the console does not surface, and the API will not warn you about it at deployment time. There is a specific sequence of misconfigurations that catches almost every team moving to Lattice from ALBs or PrivateLink. None of them produce informative error messages. Two of them are behaviours that the AWS documentation describes correctly but that practically nobody reads before hitting production. One of them means your service can pass all health checks and silently route to unhealthy targets simultaneously, with nothing in your dashboards to indicate anything is wrong. The fixes are not difficult once you know what you are looking for. But you only find them after the debugging sessions unless someone lays them out in the right order first. What is the first place your team looked when Lattice traffic stopped flowing? Full breakdown at the link. https://lnkd.in/er5Pp7wn