标签：#DevOps

Microsoft is placing greater emphasis on controlling disruption in Azure Kubernetes Service (AKS) Node Auto-Provisioning (NAP), publishing new guidance to help platform teams balance the efficiency benefits of automated node consolidation with application availability. By Craig Risi

If you run ClickHouse in production, you're probably on 26.3 LTS. And now 26.8 LTS has been announced, which means the LTS-to-LTS upgrade conversation starts again. Here's the thing most release posts skip: this is not a one-release hop. Going from 26.3 LTS to 26.8 LTS means crossing 26.4, 26.5, 26.6 and 26.7 as well. Every breaking change in those four releases applies to you, and some of the ones most likely to ruin your day aren't in 26.8 at all. So instead of writing another "here are the 26.8 features" post, I wanted to write the thing I'd actually want before scheduling this upgrade: what breaks, what silently changes, what order to do things in, and what you get for the trouble. A note on release timing As of writing (27 August 2026), 26.8 has been announced but is not fully released yet. The release branch is cut and versioned (v26.8.1.1-lts), but the tag and Docker images have not been published yet, and the upstream changelog still marks the 26.8 section as in progress. By the time you read this, the tag has probably landed. Check for yourself: curl -s https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/utils/list-versions/version_date.tsv \ | awk -F '\t' '$1 ~ /^v26\.8\./ {print "26.8 is released - newest: " $1 " (" $2 ")"; f=1; exit} END {if (!f) print "26.8 not released yet"}' version_date.tsv is the list ClickHouse maintains of every released version and its date, so this is the most direct answer available - no auth, no rate limit, nothing to download. As of writing it prints 26.8 not released yet . Worth knowing: the Docker image will lag whatever that command tells you. The Docker Official Images repo trails the GitHub tags by a few patch versions - clickhouse:lts currently resolves to 26.3.20.7 even though 26.3.24.4 has already shipped. So don't treat a missing image as evidence the release hasn't happened. Either way, the timing works in your favour. Historically ClickHouse LTS releases pick up several patch releases quickly - 26.7 had

You shut the VM down to save money, and next month it is still on the bill. This is one of the most common Azure billing surprises, and it comes down to a distinction Azure does not make obvious: there is a difference between a VM that is Stopped and one that is Stopped (deallocated) , and only one of them stops the compute charges. Here is exactly what is happening, and the cost that survives even when you do it right. Stopped vs Stopped (deallocated) Azure has two "off" states, and they bill completely differently. Stopped (from inside the OS). If you run shutdown inside the guest OS, the VM powers off but Azure keeps the compute resources allocated to it. The status shows Stopped . You are still paying full compute price for a VM doing nothing. This is the trap. Stopped (deallocated). If you stop the VM from the Azure Portal, CLI, or PowerShell, Azure deallocates it, releasing the underlying compute. The status shows Stopped (deallocated) , and compute billing stops. So the rule: shutting down from inside the guest does not save you money. You must deallocate, and deallocation only happens when you stop it through Azure, not through the OS. # This deallocates and stops compute billing: az vm deallocate --resource-group my-rg --name my-vm # Inside-the-OS "shutdown" does NOT deallocate. Status stays "Stopped", billing continues. Check which state you are actually in: az vm get-instance-view --resource-group my-rg --name my-vm \ --query "instanceView.statuses[?starts_with(code, 'PowerState')].displayStatus" -o tsv If that returns VM stopped you are still paying. If it returns VM deallocated you are not paying for compute. The disks nobody mentions Here is the part that catches people even after they deallocate correctly: deallocation stops compute billing, not storage billing. The managed disks attached to the VM (the OS disk and any data disks) keep costing money whether the VM is running, stopped, or deallocated. A deallocated VM with a 512 GB Premium SSD is still

Everybody's cloud cost journey has the same first chapter: someone writes a Lambda that stops the dev instances at night and starts them in the morning. It works. It saves real money. And then the environment grows, and one morning the script that ran fine for a year quietly causes an outage. The shutdown script that works on one instance breaks at three hundred, and it breaks in four specific ways. Here is each one, because knowing them is the difference between saving money and writing a postmortem. The script that works on one instance # stop_dev.py, EventBridge at 20:00 import boto3 ec2 = boto3 . client ( " ec2 " ) ids = [ i [ " InstanceId " ] for r in ec2 . describe_instances ( Filters = [{ " Name " : " tag:env " , " Values " :[ " dev " ]}])[ " Reservations " ] for i in r [ " Instances " ]] ec2 . stop_instances ( InstanceIds = ids ) At small scale this is fine. At scale, here is what goes wrong. Break 1: dependency order Your app instance depends on a database. Stop them in a random order and starting back up, the app comes alive before the database is ready and lands in a crash loop. On one box you get away with it. Across an environment with app tiers, databases, and caches, ordering is not optional: databases up before apps, apps up before the things that call them. A flat list of instance IDs has no concept of "start this after that." Real scheduling needs dependency-aware sequencing (storage, then compute, then application), with delays between tiers. Break 2: timezones The script fires at 20:00. Whose 20:00? As you add teams in different regions, a single UTC cron either shuts down someone's environment in the middle of their afternoon or leaves it running all night. At scale, schedules have to be timezone-aware per environment or per team, not one global time that is wrong for most of the world. Break 3: no overrides, so people disable it The night QA needs staging up late for a release, the script kills it at 20:00 anyway. This happens twice, and then s

The review passed. The deployment failed. An engineer moved a code-review agent to a free server. The model answered correctly in every test. Then the server hit its quota at 2:47 PM on day three. Fourteen pull request verdicts vanished with the session. No state. No logs. No retry. This is the reviewer's blind spot. Teams test models obsessively. They rarely test the runtime underneath. This guide covers one decision: refusing a free server for an agent. It lists red flags, better alternatives, and exit criteria. It also names a concrete example: MonkeyCode's free model access and free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. What "free" actually includes MonkeyCode is an open-source agent platform. It offers free model access and a free server option. The free model access includes 10 million tokens per cycle, per the project's published claim. The free server runs the agent without a paid VM. Those offers are real. They are also constraints. Free infrastructure is a budget, not a promise. Treat it like a trial environment, not a production contract. Free tiers exist to convert users, not to run production. That is fine. The mistake is treating them as infrastructure. Three failure modes Free infrastructure fails in predictable ways. Know all three before committing. Mode one: quota exhaustion. Token budgets reset on a schedule. Heavy days burn the whole cycle. The failure is silent. The agent stops mid-task. Mode two: state loss. Free servers restart without warning. In-memory sessions disappear. Long-running agents lose context. Recovery is manual. Mode three: contention. Shared resources mean cold starts. Neighbors consume CPU. Rate limits appear at peak hours. Latency becomes a random variable. Red flags: check before committing Run this checklist before any migration. One red flag means pause. Two mean stop. Hard deadlines. The agent gates CI or on-call responses. A quota reset cannot wait. Daily burn exce

Here is a test from a real, well run Node project: test ( ' server starts ' , async ( t ) => { const app = build () await app . listen ({ port : 0 }) t . assert . ok ( true , ' server started ' ) }) It reads fine in review. It runs green. Now delete the body of build() so the server never comes up. The test is still green, because the only thing it asserts is true . In the same file two more of these caught the error in a catch and asserted true there too, so even the failure path was green. That is not a made up example. I found it in fastify at a pinned commit and opened a PR to fix it. More on that at the end. A whole class of tests cannot fail Once you start looking, the pattern turns up in a few shapes: A literal: assert.ok(true) , expect(1).toBe(1) , a snapshot of a constant. An assertion parked in a catch the happy path never reaches, so nothing is checked when the code works and nothing is checked when it breaks. A status list that accepts both outcomes: assert.ok([200, 500].includes(res.status)) . Each one runs, counts toward coverage and guards nothing. Coverage is the trap. The line executed, so the tool that counts executed lines is happy. Whether the line would go red on a regression is a different question. It is the one that matters. Why review misses it A reviewer reading the diff sees a test called server starts , an await listen and a green tick. The name states intent. The assertion is what actually runs, yet ok(true) does not look like a problem until you stop and ask what would ever turn this test red. A missing check does not show up in a diff the way a wrong line does. Finding them I wrote a small scanner for this. No account, no config file, no network call: npx margyn-scan /path/to/repo One of its checks is cannot-fail : tests whose assertions hold whatever the code does. It also flags tests that assert nothing at all, files the build reads that git never committed, gates declared in package.json that no workflow invokes and linter exclusion

Free Tokens Are Not an SLO: An Ops Cost Drill for AI Batch Queues This week, two numbers trended: a harness at 100%, a model at 30%. For platform teams, a better pair is queue age and deadline slack. This article is a cost drill for the simplest AI batch path: free tokens, free server, non-negotiable deadline. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option. That capacity is real. It is not an SLO. The tokens cost nothing. The queue is patient. Your deadline is not. The missing variable Token cost is easy to measure. Operations cost is easy to ignore. A free endpoint converts a per-token bill into a per-hour bill. The bill becomes your time, your retries, and your queue age. This drill keeps the ledger honest. It answers one question: what does a completed request cost when the token price is zero? Topology # worker.py (minimal, single-threaded) import queue import time import csv work = queue . Queue () for i in range ( 1000 ): work . put ({ " id " : i , " prompt_tokens " : 512 , " max_tokens " : 256 }) def call_model ( payload ): # replace with your free model endpoint return { " ok " : True , " in_tokens " : 512 , " out_tokens " : 180 } completed = 0 retries = 0 started_at = time . time () while not work . empty (): item = work . get () attempt = 0 while attempt < 4 : try : call_model ( item ) completed += 1 break except Exception : retries += 1 attempt += 1 time . sleep ( 2 ** attempt ) The worker is deliberately single-threaded. Free capacity often serializes. Serialization turns a token problem into a time problem. Declared test conditions 1,000 requests. One worker process. One free model endpoint. No client-side rate limiting. Deadline: 30 minutes. Ledger: one CSV row per request. Ledger and report # cost_ledger.py import csv import time HOURLY_OPS_COST = 50.0 # loaded engineering rate, adjust def record ( item , elapsed , retries ): with open ( " ledger.csv " , " a

In my first post, I wrote about why I spent my first week writing zero business logic and instead built rig - our lightweight, POSIX-compliant local provisioning tool. It was my way of rejecting "wiki-ops" and applying Infrastructure-as-Code (IaC) discipline to our local environments so that a hardware failure means minutes of downtime, not a week. But as I transitioned into Week Two, I was hit by a different kind of operational reality check. For years, I had been building a comprehensive repository of system architecture, design decisions, and guidelines on Confluence. It was my digital home. So, knowing I would be creating a startup, I set to work writing my documentation in my spare time in preparation. But during a brief hiatus of inactivity, the space was silently, unceremoniously deleted. It was gone. Late nights of ideas, patterns, templates, and reference materials vanished into the cloud ether. That loss was a violent reminder of a lesson I thought I'd fully mastered: if your documentation doesn't live alongside your code, you don't truly own it. Relying on third-party SaaS wikis to store the soul of your system architecture is just another form of "click-ops". It creates an artificial separation between the craftsmen writing the logic and the documentation that defines it. But rather than mourning my lost Confluence space, I treated it as a catalyst. I decided that our young startup would not have a bloated, detached corporate wiki. Instead, we would treat Documentation as a Contract - a unified, git-backed human-and-machine contract that serves as the precise, zero-maintenance boundary for our AI systems. Here is how losing my documentation led to a new architectural philosophy, and how we built a zero-overhead, "Anti-AI AI Strategy" that uses GitLab CI/CD and Google Workspace to run a secure, managed RAG pipeline. The Anti-AI Strategy: Why We Refuse to Let AI Write Our Code Walk into almost any tech startup today, and you’ll find developers blindly feed

Tuesday, 10:47 AM. Fourteen developers open their IDE extensions at once, and the shared AI server starts returning timeouts. Nobody planned for the morning spike. The free tier was announced on Monday, the team adopted it by Tuesday, and the first capacity incident happened before lunch. This article is a 30-minute load-test workflow for teams that just received access to a free hosted AI server. The goal is not to benchmark model quality. The goal is to find the concurrency ceiling before your team does — the hard way. The Free Server Is a Shared Resource Now MonkeyCode is an open-source AI coding project that offers free models and a free server. The offer is attractive for the same reason it is dangerous: it removes the two usual adoption barriers — API billing and self-hosting operations — and turns the server into a shared team resource overnight. Disclosure: This article was prepared as part of MonkeyCode's product outreach. A shared resource without a measured ceiling behaves like a shared database without connection pooling. It works in the demo, degrades under load, and fails at the worst possible moment: the morning standup, the release freeze, the day before the demo. The failure mode is not what most teams expect. It is not the token quota. It is latency collapse. Requests queue, timeouts cascade, and the IDE extension retries, which adds more load. The server does not die; it just becomes unusable. The Math: Little's Law for AI Requests Before writing any test code, define the model. Little's Law states that the average number of requests in a system equals the arrival rate multiplied by the average service time: L = λ × W L — average requests in the system (concurrency) λ — arrival rate, requests per second W — average service time per request, in seconds For an AI server, W is dominated by model inference time. A single code-generation request can take 10 to 40 seconds on a shared free server, depending on the model and the prompt length. That change

Hey everyone! 👋 Finding reliable, free public APIs for side projects or learning is always a hassle because many listed APIs eventually go down or become paid. To solve this, I created Awesome Free APIs Live — an open-source, curated collection of 50+ free public APIs across AI, developer tools, security, and open data. ⚙️ How It Works Daily Health Checks: Powered by GitHub Actions , an automated script tests endpoints daily and updates live status badges. Zero Dead Links: Broken endpoints are flagged automatically so developers don't waste time debugging dead services. Categorized & Searchable: Clean, categorized UI hosted on GitHub Pages. ### 🔗 Links 🌐 Live Directory: shilpshakti.github.io/awesome-free-apis-live ⭐ GitHub Repository: github.com/ShilpShakti/awesome-free-apis-live Contributions are very welcome! If you know of any great free APIs, feel free to open a PR or check out the open issues on GitHub.

The first OpenClaw deployment is usually straightforward. You provision a machine, configure one agent, connect a few tools, and watch it complete a real task. If something breaks, you inspect the logs, fix the configuration, and restart the process. That is a valid way to prove the use case. It is not yet a production architecture. The category changes when an agency, SaaS company, consultant, or internal platform team needs to run OpenClaw for multiple clients. Every agent now belongs to a tenant, holds state, uses credentials, controls browser sessions, changes files, and can create external side effects. A failure is no longer just a failed process. It can become a missed client task, a duplicated email, a corrupted workspace, or an access-control incident. The right question is therefore not, "How many OpenClaw containers can this server run?" It is, "How many client environments can our team operate safely, recoverably, and without adding one human babysitter for every few agents?" This guide presents a practical architecture and deployment checklist for answering that question. Start with the correct unit of architecture Do not model an OpenClaw fleet as a list of processes. Model it as a list of client cells. A client cell is the complete operating boundary for one tenant or one agent. It includes: the OpenClaw process and its configuration; its resource envelope: reserved and maximum RAM, CPU cores, burst allowance, and priority; the persistent workspace and task artifacts; credentials and integration permissions; browser profiles, cookies, and active sessions; email, phone, or chat identity; logs, events, and audit history; recovery policy and human owner. This distinction matters because a process can be healthy while the client cell is broken. The daemon may still respond, but its CRM credential has expired. The container may be running, but the browser session is stuck behind a login prompt. The agent may have restarted successfully, but its workspace c

You self-host S3-compatible storage on bare metal by installing a single Rust binary on a Linux server and pointing any S3 client at it. RustFS installs with one script, listens on port 9000 (S3 API) and 9001 (console), and is Apache 2.0 licensed. Single-node mode is production-ready today; multi-node clustering is still under testing. Every command below is copied verbatim from the official source cited beside it. This sandbox has no Docker daemon, so none of the commands were executed here; they are marked accordingly. Key Stats Fact Source RustFS installs with one command and runs as a systemd service on x86_64 or aarch64 Linux RustFS docs (Linux quick-start) Default S3 API port is 9000; console port is 9001 RustFS GitHub README Default credentials are rustfsadmin / rustfsadmin and must be changed RustFS README + docs RustFS is Apache 2.0 licensed and S3-compatible RustFS GitHub README Single-node mode is production-ready; distributed mode is still under testing RustFS README Feature & Status What is self-hosted S3-compatible storage? A self-hosted S3-compatible storage server is a program you run on your own hardware that speaks the Amazon S3 API. Applications using AWS SDKs, the aws CLI, or MinIO's mc can talk to it without code changes, because the bucket, object, and credential model matches S3. The difference from a cloud bucket is ownership: the disks, the network path, and the uptime are yours. RustFS is one such server, written in Rust and licensed under Apache 2.0. It exposes the S3 API on port 9000 and a web console on 9001, and it stores objects on the local filesystem. Because it is S3-compatible, the same client code that targets AWS S3 also targets a RustFS node. That compatibility is the whole point of self-hosting here: you get an S3 endpoint without renting one. Why run object storage on bare metal? Running object storage on bare metal means installing the server directly on a Linux machine instead of in a container or a managed cloud. The appeal

Linux server running out of memory? Learn how to diagnose and fix high memory usage with real commands — before it takes down your app. Your app starts slowing down, the OOM killer fires, or your monitoring page turns red — and the culprit is memory. High memory usage on a Linux server is one of the most common production crises for small teams, and it's easy to misread. Linux intentionally uses most of your RAM for caching, so a server showing 95% memory used isn't necessarily in trouble. But one that's exhausting real working memory and swapping is. Here's how to tell the difference and actually fix it. Step 1: Get a Clear Picture of What's Using Memory Start with the basics. Run 'free -h' to see total, used, free, and available memory. Focus on the 'available' column — that's the real number. It accounts for reclaimable cache and is far more useful than 'free'. free -h — quick overview of RAM and swap usage vmstat 1 5 — five one-second snapshots; watch the 'si' and 'so' columns for swap-in and swap-out activity cat /proc/meminfo — full breakdown including Slab, PageTables, and AnonPages If swap is actively being used (si/so values above zero consistently), your server is genuinely memory-constrained. That's different from swap space existing but sitting idle. Step 2: Find the Processes Eating Your RAM Once you know memory is tight, you need to know what's consuming it. Run 'ps aux --sort=-%mem | head -20' to list the top 20 processes by memory percentage. For more detail on actual RSS (resident set size) in human-readable form: ps -eo pid,ppid,cmd,%mem,rss --sort=-%mem | head -20 RSS is the memory a process actually holds in RAM — not virtual memory, which is often misleadingly large. Another useful tool is 'smem', which calculates PSS (proportional set size) and gives a fairer view when processes share memory libraries. Install it with 'apt install smem' or 'yum install smem', then run 'smem -r -k | head -20'. Look for processes with unexpectedly high RSS. A Nod

You have done everything right. You made the economic case for automation and got the investment approved. You distributed quality checks across the SDLC instead of piling them at the end. You replaced pyramid thinking with risk-weighted coverage. You stopped reporting a coverage percentage that was lying to you. Six months later, your engineers have started ignoring test failures. Not because they are careless. Because ignoring test failures became the rational choice. This article is about how that happens, why it happens to teams that know better, and why it is the final form of Test Debt. What is flakiness? A flaky test is a test that fails intermittently without any change to the code it covers. It sometimes passes and sometimes fails, with no consistent pattern. The most common root causes are timing issues in async operations, test-order dependencies, shared mutable state, and coupling to external services. All of these are fixable. The fixable nature of the problem is not what makes it interesting. What makes it interesting is that teams fix very little of it, and teams with strong engineers who care about quality fix very little of it. The reason is not the technical difficulty. The scale The numbers are worth stating clearly, because they establish what is actually at stake here: At Google , approximately 16% of tests show some form of flakiness, and 84% of transitions from passing to failing involve a flaky test rather than a genuine regression. At Microsoft , roughly 25% of test failures in large-scale CI systems are caused by flakiness, not actual code defects. The average time a developer spends per flaky test investigation: 30 minutes, before determining it was not a real failure. Atlassian estimated 150,000 developer hours per year consumed by flaky test investigation before they built automated detection tooling. Slack's mobile test failure rate reached 56.76% before they intervened. More than half of all test failures were noise. These are not team

Disclosure up front: I'm Vitalii, founder of PDFik , a hosted URL/HTML-to-PDF API. It shows up once near the end, clearly marked. The rest of this is the debugging guide I wish existed the last three times someone hit these errors. If you run wkhtmltopdf in containers, you have probably met at least one of these three errors: sh: /usr/local/bin/wkhtmltopdf: not found # Alpine wkhtmltox : Depends: libssl1.1 but it is not installable E: Unable to locate package wkhtmltopdf # Ubuntu 24.04 / Debian 13 All three have the same root cause: the project is archived (January 2023, repository read-only ) and the last official packages were built in May 2023 — release 0.12.6.1-3 , whose newest targets are Debian 12 (bookworm) and Ubuntu 22.04 (jammy). The distros kept moving; the binaries stopped. Here is what each error actually means, the recipe that still works in 2026, and the honest exits. Error 1: not found on Alpine — it's not about PATH The confusing part: the file is there, ls sees it, and the shell still says not found . That message comes from the kernel failing to load the binary's interpreter: official wkhtmltopdf builds link against glibc , Alpine ships musl , and the referenced dynamic loader ( /lib64/ld-linux-x86-64.so.2 ) does not exist on Alpine. ldd /usr/local/bin/wkhtmltopdf shows it immediately. There is no supported way around it on Alpine today: the distro dropped its wkhtmltopdf package years ago (nothing in current stable), and gcompat shims are a lottery with a binary this large. If the container must run wkhtmltopdf, don't build it on Alpine — that fight is not worth the ~50 MB you save. Error 2: Depends: libssl1.1 — you're installing a 2020 build on a 2023+ distro The widely-copied Dockerfiles fetch wkhtmltox_0.12.6-1.*.deb , which links OpenSSL 1.1. Debian 12, Ubuntu 22.04+ and everything after ship OpenSSL 3 and removed libssl1.1 from the archives, so the dependency is unresolvable. (Pinning an EOL base image or hand-installing an EOL libssl to wor

Last month my WhatsApp stack moved 89,479 messages. I got no invoice for any of them. That is not a brag, it is the setup for an honest accounting. Because "self-hosting is cheaper" is the least interesting sentence in infrastructure, and it is usually said by someone who has never been paged at 7am by a bot that went quiet at 2am. I want to put a real number on both sides of that trade: the money Twilio would have charged, and the money self-hosting quietly takes back. All the numbers below were pulled or fetched on August 27, 2026 . The rate cards move quarterly, so check yours. The traffic, measured rather than estimated Five WhatsApp inboxes, bridged from WAHA into a self-hosted Chatwoot. Thirty days: messages Total 89,479 Inbound (from users) 45,563 Outbound (from us) 43,916 Most benchmarks stop here, multiply by a per-message rate, and publish. That answer is wrong, because Meta does not charge per message. It charges per template sent outside an open customer service window. Multiplying my full 89,479 by a template rate overstates the Meta line by about 3x. Multiplying just the outbound half still overstates it by about 1.5x. Since November 1, 2024 non-template messages are free. Since July 1, 2025 utility templates answering a user inside an open 24-hour window are also free. So the only line that costs money is the outbound message that goes out when nobody has written to you in the last day. Which means the number you actually need is not "how many messages," it is "how many outbound messages had no inbound message from that contact in the preceding 24 hours." The query that produces the real bill Here it is against Chatwoot's schema. It uses a window function rather than a correlated NOT EXISTS , because on a messages table of any size the correlated version will happily eat your connection pool. WITH src AS ( SELECT m . conversation_id , m . created_at , m . message_type FROM messages m WHERE m . inbox_id IN ( 27 , 23 , 46 , 50 , 48 ) -- your WhatsApp in

When I first looked at AWS, it felt unnecessarily complicated. EC2 runs something. S3 stores something. RDS manages something. Lambda does something “serverless.” I understood the definitions individually. But I still didn't understand AWS. The breakthrough comes when you stop learning these services separately and ask one simple question: How would I use EC2, S3, RDS and Lambda together to build one real application? That's when AWS starts making sense. So instead of another article explaining AWS services like dictionary definitions, let's build something. Imagine we're creating a simple job portal where users can create accounts, upload resumes and apply for jobs. Nothing extraordinary. But this small application is enough to understand some of the most important ideas in cloud architecture. First, Forget AWS for a Minute Before choosing any AWS service, think about what our application actually needs. Someone visits our website. They create an account. They upload their resume. They browse available jobs. They submit an application. When a resume is uploaded, perhaps we want to automatically process it and extract some basic information. Already, we can identify four different technical problems. We need somewhere to run our application. We need somewhere to store uploaded files. We need somewhere to store structured information such as users and applications. And we need something that can automatically react when certain events happen. Now AWS becomes easier. Because instead of memorizing services, we're matching problems to solutions. Our architecture starts with four pieces: EC2 → Application S3 → Files RDS → Structured Data Lambda → Event-Driven Processing Let's see what that actually means. EC2: Where Our Application Lives Our job portal needs backend code. Maybe we're building it using Python, Node.js, Java or another backend technology. That code needs somewhere to run. This is where Amazon EC2 enters the picture. Think of EC2 as renting a computer insid

Your datacenter needs to talk to Azure. You can send that traffic through an encrypted tunnel over the public internet, or over a private circuit that never touches it. That single choice — shared road or private rail — decides cost, speed, and reliability. Almost every organization moving to Azure keeps something on-premises, and those two worlds have to connect privately. Azure gives you two hybrid-connectivity options, and they take opposite routes to the same destination: VPN Gateway and ExpressRoute . Understanding them is really understanding one question — does your traffic ride the public internet, protected by encryption, or a dedicated line that bypasses it entirely? VPN Gateway: an encrypted tunnel over the internet Microsoft's description is exact: Azure VPN Gateway "can be used to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet." Your traffic still travels the ordinary internet, but inside an IPsec/IKE tunnel, so it is private even though the road is shared. It comes in a few shapes: site-to-site (your datacenter's VPN device to Azure), point-to-site (an individual remote worker to the VNet), and VNet-to-VNet . It is quick to stand up, needs no third party, and is inexpensive — the pragmatic default for dev/test and small-to-medium production links. ExpressRoute: a private, dedicated circuit ExpressRoute takes the other road entirely. It "lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider." The defining fact: because ExpressRoute connections do not go over the public internet , they offer "more reliability, faster speeds, consistent latencies, and higher security than typical connections over the internet." You are not tunnelling through shared roads; you have a private rail line into Microsoft's network, arranged through a connectivity provider. That extra reliability and consistency costs more and takes longer t

The deploy worked. The bill doubled. The blue-green cutover went perfectly. Traffic shifted to green, health checks passed, the team signed off, and moved on. It was one of those rare deployments that goes exactly as planned. Six weeks later, a cost anomaly surfaced in the monthly AWS review. Infrastructure spend had been running at roughly double what it should have been since the deployment date. Every EC2 instance, every RDS node, every load balancer from the blue environment was still running. Serving zero traffic. Billed at full price. For six weeks. Nobody had decommissioned it because nobody owned it after cutover. The team that ran the deployment assumed operations would clean it up. Operations assumed the team that deployed it would tear it down. The blue environment sat in a perfect ownership gap, healthy and idle and expensive, while both teams closed their tickets and moved on. This is the part blue-green deployment guides don't emphasize enough. The strategy is excellent for zero downtime releases and instant rollback capability. The rollback window is the dangerous part. It's open-ended by default, which means the old environment stays alive until someone makes a deliberate decision to shut it down. That decision requires ownership, and ownership requires someone to be responsible for it after the deployment is considered done. The fix is treating decommissioning as part of the deployment itself, not cleanup that happens afterward. Tag every blue environment resource at launch with a TTL: aws ec2 create-tags \ --resources i-1234567890abcdef0 \ --tags Key = DeploymentColor,Value = blue \ Key = CutoverDate,Value = 2026-01-14 \ Key = TTL,Value = 2026-01-21 Then wire Cost Anomaly Detection to alert when a specific environment tag is still generating spend past its TTL. The old environment doesn't get to become invisible just because traffic moved away from it. The deeper issue is that blue-green deployments create a window of parallel infrastructure that m

Today's two tasks are both about a new base. A feature branch that needs to sit on top of a master that has moved. A database instance that needs to come back from a snapshot taken when things were fine. In each case, the interesting question is the same: what carries over, and what do you have to say out loud? One Git task, one AWS task. Rebase a feature branch onto master without creating a merge commit, then snapshot an RDS instance and restore it into a new one. The tasks come from the KodeKloud Engineer platform. Rebase: not moving commits, replaying them The requirement was specific, and the specificity is the lesson. A developer's feature branch was behind master. Bring it up to date without losing any feature work, and without a merge commit. That second clause rules out git merge master . Merge joins two histories and records the join, which is the merge commit. Rebase does something else entirely. cd /usr/src/kodekloudrepos/media git branch git log --oneline --graph --all --decorate git checkout feature git rebase master git log --oneline --graph --decorate Git's own documentation describes what happens under git rebase master : it lists the commits on your branch that are not on master, checks out master, and then replays each of your commits on top of it, one at a time, in a way it compares to running git cherry-pick for each one. Replays. Not moves. Every commit that comes out the other side has a new hash, because a commit's identity includes its parent, and the parent is different now. Your work is preserved, the commits carrying it are not the same objects they were. That is exactly why there is no merge commit. Rebase does not join two histories, it rewrites yours so it looks like it was always based on master's current tip. You get a straight line, at the cost of a history that is no longer a record of what actually happened. Two things I had to be deliberate about. Direction. Rebase applies to the branch you are standing on and takes the branch yo