标签：#Cloud

We serve customers primarily in Australia, but we are now expanding to the USA. The timeline for launch is less than 2 months. This is now a race against time to design a multi-region routing system that fits all of our needs. Here is the story. Background Almost all of our customers were based in Oceania. We run our Kubernetes Cluster on GCP in Australia. Go microservices, federated GraphQL, gRPC services. 2 products - Tutoring and Schools. All designed for Australia. Then we expanded to the USA, which meant a new Kubernetes Cluster in US Central. The latency for serving US customers from Australia is an extra 200ms-300ms depending on network conditions - unacceptable. This would mean sharding the data by region, or does it? There are definitely ways to keep a unified dataset even across regions - though we did not need to do so. More on this later. What are the requirements If the only requirements were "Americans get served from America", we wouldn't be here discussing this, would we? Logged in users are served from their own region, wherever they happen to be in the world. Logged out users are routed geographically, as we have no other information to infer their actual region. Account Managers and Admins should be able to access both regions from one button, with a single account. Teaching materials opened via links from the Schools product must be shareable across both regions. Geography takes care of the logged out user, but nothing else. Using geography for a logged in user can be actively wrong. They might be travelling or simply using a VPN. Then comes the Admin; we have a lot of admin operations regarding curricula, which will be entirely separate for both clusters. Account Managers need to be able to see and modify information on both clusters. One admin should be able to access both clusters with a single account. We considered showing data of both clusters on one screen, but ruled it out as it may become too ambiguous or confusing, not worth the technic

Cyber Security and Cloud Computing are consistently named among the top-paying, highest-demand IT career tracks for 2026 — and they’re also deeply connected, which is exactly what makes choosing between them confusing for freshers. Most cloud roles require security awareness, and most modern security roles require solid cloud knowledge. So the real question isn’t “which field is better” — it’s which one should be your primary specialization, with the other as a supporting skill. Here’s a practical roadmap to help you decide. What Each Field Actually Involves Day to Day Cloud Computing professionals design, deploy, and manage infrastructure on platforms like AWS, Azure, or Google Cloud. Day-to-day work includes provisioning servers, managing storage and networking, setting up CI/CD pipelines, and optimizing costs and performance. It’s closely tied to DevOps practices — automation, containers (Docker, Kubernetes), and infrastructure-as-code. Cyber Security professionals protect systems, networks, and data from unauthorized access and attacks. Entry-level work often starts in a Security Operations Center (SOC), monitoring alerts, investigating incidents, and managing tools like firewalls, SIEM platforms, and vulnerability scanners. It branches later into specializations like penetration testing, cloud security, or governance and compliance. Skill Overlap vs Skill Divergence They share a foundation: networking fundamentals, operating systems (especially Linux), and increasingly, cloud platform basics — since most organizations now run infrastructure on AWS, Azure, or GCP rather than fully on-premises. Where they diverge: Cloud Computing leans toward building and automating — you’re constructing and scaling systems. Cyber Security leans toward defending and investigating — you’re protecting what’s already built and reacting to threats against it. If you enjoy building things and seeing systems run efficiently, cloud tends to be the more natural fit. If you enjoy problem-

Cloudflare has added optional OAuth scopes, letting client owners mark which permissions users may deselect at consent. The company names MCP servers as the motivating case, since agents request the union of everything they might do. Partial consent exists elsewhere, but developer control over which scopes are droppable does not. By Steef-Jan Wiggers

AWS has announced revisions to two of its most popular certifications: Solutions Architect – Professional (SAP-C02 → SAP-C03) and Developer – Associate (DVA-C02 → DVA-C03) . This article collects what is publicly known right now, from the official blog post and the certification pages. Neither exam guide is published yet. The official blog states that the full exam guide, including detailed task statements, will be released on October 27, 2026, when registration opens. Everything below is based solely on the official blog (English and Japanese editions) and the certification pages. I'll update this article once the guides are out. 1. SAP-C03 (Solutions Architect – Professional) Dates and format Item Detail Registration opens October 27, 2026 (all languages) Last day to take SAP-C02 November 16 — see note below SAP-C03 available November 17 Duration 180 minutes Questions 75 Price 300 USD The format is unchanged from the current exam. Why the revision The blog states that today's architects "don't just design highly available, cost-effective systems — they integrate generative AI and agentic architectures and implement post-quantum cryptography." What's being added Area New skills Content Generative AI and agentic AI 11 Generative AI integration design with Amazon Bedrock, AI agent architectures with Amazon Bedrock AgentCore , RAG architectures, content filtering with Bedrock Guardrails , human-oversight workflows for AI operations Resilience engineering — AWS Fault Injection Service, AWS Resilience Hub, Application Recovery Controller, automated runbooks with Systems Manager Cloud-native patterns 7 Serverless data pipelines, durable workflows with Step Functions, service mesh with VPC Lattice and ECS Service Connect , container image security, multi-tenant architectures, real-time data architectures DevSecOps and observability 6 Pipeline vulnerability scanning, multi-account deployment pipelines, container monitoring, AI/ML metrics monitoring, synthetic monitoring an

While building HarvestIQ , I started paying much more attention to how backend architecture affects the way a product can be built, deployed, and scaled. HarvestIQ is an agriculture platform designed to help smallholder farmers access post-harvest intelligence, including market prices and buyer opportunities. One of the interesting parts of the project is that a farmer can interact with the system through USSD , without requiring a smartphone or an internet connection. The backend is built around a serverless architecture using AWS services. This article breaks down how that architecture works and what I have learned from building it. What does "serverless" actually mean? The name can be misleading. Serverless does not mean that there are no servers. The servers still exist. AWS manages the underlying infrastructure, while I focus on writing and deploying the application code. Instead of maintaining an always-running backend server, different parts of the application can run when they are needed. For HarvestIQ, this works particularly well because many operations are event-driven. A farmer makes a request. A function executes. Data is retrieved or updated. The function finishes. Another event can trigger another function later. HarvestIQ's Serverless Architecture The simplified architecture looks like this: Farmer | USSD | v Africa's Talking | v AWS Lambda / \ / \ v v DynamoDB Response EventBridge | v AWS Lambda | v Price / Alert Logic | v SNS | v SMS | v Farmer Each AWS service has a specific responsibility. AWS Lambda handles application logic. DynamoDB stores application data. EventBridge triggers scheduled operations. SNS handles notifications. Africa's Talking provides the USSD and SMS connectivity layer. Let's look at each part. 1. USSD as the Entry Point One of the design goals of HarvestIQ is accessibility. A farmer should not necessarily need: A smartphone A mobile application Mobile data A web browser A basic mobile phone with cellular connectivity can be

Originally published on indiecore.net . I moved this site off a hosted blogging platform onto Cloudflare, with GitHub Actions doing the building and Cloudflare doing the serving. It costs nothing, deploys in about two and a half minutes, and refuses to publish anything that fails its checks. Getting there took longer than it should have. Here is the setup, and the five things that tripped me up — none of which are obvious from the documentation. The shape of it git push └─ GitHub Actions ├─ build generate the site ├─ verify dead links, missing images, bad metadata, broken redirects ├─ Lighthouse fail if performance/accessibility/SEO drop below budget └─ deploy upload to Cloudflare The important part is that deploy depends on the checks . A broken build never reaches the internet. Pull requests get a preview URL; merges to main go live. The triggers and permissions that make that safe: ci-cd.yml — triggers and permissions name : CI/CD # Build and verify every change; deploy previews for PRs and production from main. # Deploy jobs depend on the quality gates, so nothing ships unverified. on : push : branches : [ main ] # The SEO watch ledger is machine-written, is never part of dist/, and is # committed daily. Deploying the site again for it would be pure noise — and # would re-trigger the SEO ping through workflow_run every single day. paths-ignore : - ' _source/seo-watch.json' pull_request : branches : [ main ] workflow_dispatch : # Least privilege by default; individual jobs elevate only what they need. permissions : contents : read # Supersede in-flight runs for a branch, but never interrupt a production deploy. concurrency : group : ci-cd-${{ github.ref }} cancel-in-progress : ${{ github.ref != 'refs/heads/main' }} env : # wrangler ships as a pinned devDependency; never phone home from CI WRANGLER_SEND_METRICS : " false" permissions: contents: read at the top means every job starts with the minimum, and only the one that comments on pull requests gets more. The c

Claude Fable 5.1 is officially available in the Model Garden on Agent Platform. Built for long-running, high-stakes work, Fable 5.1 puts frontier intelligence into production across your code, documents, and research. 👉 Try it today and let us know what you're building: Claude Fable 5.1

AWS Lambda vs. Traditional Servers : When Serverless Actually Makes Sense "Serverless" is one of the more misleading names in cloud computing — there are still servers, you just don't manage them directly. AWS Lambda lets you run code in response to events without provisioning or maintaining a server yourself, and it genuinely changes how certain kinds of applications get built. But it's not a universal replacement for traditional servers, and understanding exactly where each one wins is more useful than treating this as "the new way vs. the old way." What Actually Changes With Lambda A traditional server — whether it's a physical machine, a VM, or a container running continuously — is always on, always consuming resources, and always your responsibility to patch, scale, and monitor, whether or not it's actively doing anything useful at a given moment. AWS Lambda flips this model: your code runs only in response to a specific trigger (an HTTP request, a file upload, a scheduled event), runs for as long as it takes to complete, and then stops. You're not paying for idle time, and you're not managing an operating system, patching, or server-level scaling — AWS handles all of that underneath the function itself. Where Lambda Genuinely Wins Event-driven, intermittent workloads — a function that runs occasionally in response to specific events (a file upload triggering image processing, a scheduled nightly job) is often dramatically cheaper on Lambda than paying for a server that sits idle most of the time Automatic scaling with zero configuration — Lambda scales from zero to many concurrent executions automatically, without you provisioning capacity in advance Reduced operational overhead — no patching an operating system, no managing server-level security updates, no capacity planning for a specific function Fast setup for simple, isolated tasks — a single-purpose function can go from idea to deployed in a genuinely short amount of time Where Traditional Servers Still

Most teams don't notice their CI/CD pipeline is broken — they just notice that deploys "feel slow" and shrug it off as normal. It isn't. A pipeline that takes 25 minutes to ship a one-line copy change isn't a fact of life, it's a symptom. Here are the mistakes we see most often when reviewing pipelines — roughly in order of how much time they silently burn. 1. Running the full test suite on every single change If a developer fixes a typo in a README and the pipeline still runs the entire integration suite, database migrations, and end-to-end tests, you're paying full price for a change that touched nothing critical. Fix: split your pipeline into stages based on what actually changed. Path-based triggers (only run frontend tests if frontend files changed) and a fast "smoke test" tier before the full suite can cut average pipeline time dramatically without sacrificing safety. 2. No caching between builds Reinstalling every dependency from scratch on every run is one of the most common — and most fixable — sources of wasted time. Package managers, build artifacts, and Docker layers are all cacheable, and most CI platforms support this natively. Fix: cache dependency directories keyed by lockfile hash, and structure Dockerfiles so rarely-changing layers (base image, dependencies) come before frequently-changing ones (application code). 3. Sequential steps that don't need to be sequential Linting, unit tests, and security scans are often run one after another when they have no dependency on each other. That's pure wasted wall-clock time. Fix: parallelize independent jobs. Most CI systems support fan-out/fan-in patterns — run lint, test, and scan simultaneously, then gate the deploy on all three passing. 4. Environments that drift from production A pipeline that passes in staging and fails in production usually means the environments aren't actually equivalent — different env vars, different resource limits, different service versions. Teams respond by adding more manual

Every company knows when it revoked access. None knows when access stopped. I built this for the All Things Agentic Hackathon , and I wrote this post for the purposes of entering that hackathon. Code: github.com/NexuChat/parallax The chore I was actually trying to kill I maintain a web application with two roles, two languages, one of them right-to-left, a dark theme, and three viewport sizes. Every release, I would open it as the owner, click through, sign out, sign in as a member, click through again, switch to Arabic, reload, shrink the window, reload — and try to remember what a page had looked like ten minutes earlier. The worst defects never survived that process, because they are not visible in any single session. A member opening a page they should have been denied sees nothing wrong. Nothing on the page says "you should not be here." The information is not in their session at all. It is in the difference between their session and the owner's. So I stopped testing sessions and started comparing them. Seven witnesses, one axis apart Parallax opens seven isolated browser contexts at the same instant against the same application. One is a baseline — owner, English, light, desktop. The other six each change exactly one axis from it: privilege, locale, theme, viewport. The full product of those axes is thirty-six combinations. Seven one-axis derivations is not just cheaper; it is the only version that can attribute a cause. When the Arabic witness disagrees with the baseline and locale is the only thing that changed, locale is the reason. With thirty-six combinations you get a bigger table and less knowledge. Each axis carries a contract about what must change and what must not: Axis Contract A finding is Privilege access must differ sameness — an escalation Locale access constant, layout mirrors access drift, or geometry that did not mirror Theme access constant, layout does not move any positional shift Viewport access constant, reflow allowed access drift That

In mission-critical infrastructure, latency isn't just a metric—it's the difference between a resolved incident and a catastrophic outage. Whether you are managing an SRE team handling cluster failures or a teleassistance platform routing domestic SOS alerts, the core engineering challenge remains identical: getting a human's attention in milliseconds without administrative friction. This technical breakdown explores how we architected a high-availability voice routing engine using Cloudflare Workers and Twilio, bridging the gap between hardware teleassistance and DevOps incident workflows. The Dual-Use Architecture: From Teleassistance to SRE Paging Our platform core serves two distinct but structurally identical needs: Senior Safe: A Chilean domestic teleassistance product where an SOS trigger must reach a family guardian instantly. DevOps On-Call: An infrastructure alert triggered via Grafana or UptimeRobot webhooks that must wake up an engineer at 3 a.m. The blast radius differs (a household vs. a production database), but the technical path is identical. To solve this at scale without charging steep "per-seat" licensing models that penalize growing squads, we built the entire pipeline on serverless isolates. Bypassing Cold Starts with Edge Ingest When an emergency happens, you cannot afford to wait for a virtual machine or container to boot. The public ingest pipeline lives directly on Cloudflare Workers ( api.wakeupdev.com ). Because V8 isolates are kept warm globally across the edge network, there is zero Lambda-style cold start penalty on the first page. The ingest contract is minimal: Authentication: Handled via an x-api-key header. Payload: Raw text or JSON (capped at 4,000 characters). Execution: Credits are consumed atomically in a global Postgres layer before the voice cascade is scheduled. An HTTP 202 Accepted status code guarantees that the credit is validated and the call flow is in flight. Solving the Voicemail Problem: True Human Acknowledgement A

I wrote this post for my entry to the All Things Agentic Hackathon. TLDR: I built a five-agent design team on Gemini (Including Gemini Flash 3.7 and Gemma 4) that takes a brief and a folder of photographs and returns finished, editable pages. The interesting engineering was not the prompts. It was deciding wh ere the run's progress lives. Code: github.com/minhthanhdang/vibes-ai . What it does Vibes AI is a design co-pilot. Upload photographs, describe what the thing is for, and it designs the pages: real crops, generated backgrounds, type in any Google Fonts family, all written as geometry that can be dragged afterwards. There are five agents. An orchestrator holds the other four as tools, so every hop is request and response, and the user reads one reply instead of a transcript of agents talking to each other. A property analyzer reads each upload in six design dimensions. An image editor cuts. An image generator draws the picture the gallery does not have. A design assistant does the actual designing. The part I want to write about is the unattended run. One form (purpose, page count, palette, vibe, size) and then no further human input until the pages are done. One long request was the wrong shape Designing six pages is minutes of model calls, not milliseconds. My first instinct was one request that loops over the pages and returns when it is finished. That shape gives nothing back. No honest progress, no Stop button that means anything, and a failure at page four throws away pages one to three. So a page became the unit of work. One job designs one page. The job is a row in an AgentRun table, a worker claims it under a lease, and when it settles it enqueues the next page inside the same transaction that marks the current one done: const chained = await db . $transaction ( async ( tx ) => { const won = await tx . agentRun . updateMany ({ where : { id : run . id , status : RunStatus . RUNNING , startedAt : run . claimedAt }, data : { status : RunStatus . SUCCEEDED

James Hall discusses the strategic and technical imperative of moving AI workloads from cloud providers to local edge devices. He shares practical approaches using WebGPU, Transformers.js, and DuckDB to achieve near-native performance in JavaScript. Through real-world case studies, he explains how to minimize data privacy risks, optimize browser inference, and build rigorous evaluation suites. By James Hall

Long-lived GCP service account keys are secrets that must be managed forever, are hard to rotate, and are easy to leak. Scaling Workload Identity Federation to 120+ production projects shows why it changes how machine identity is approached entirely: keys are secrets to manage, federated identities are trust relationships configured once, gated by attribute conditions. By Shijin Nair

Microsoft expanded Foundry's model router from two regions to 28 for global standard and 21 for data zone deployments, while adding Claude Opus 4.8 and GPT-5.6 and removing four deprecated models. Default deployments receive pool changes automatically; configured subsets exclude new models until added. The effective context window equals the smallest model in the pool. By Steef-Jan Wiggers

If you ask most people where to start in DevOps or cloud engineering, you'll get answers like "learn Docker" or "get AWS certified." Almost nobody says "learn networking first," and that's a mistake — because every one of those tools sits directly on top of networking concepts, and skipping it means you're memorizing commands without understanding what they actually do. I hit this wall myself. I could docker run things and get a VPC "working" by copy-pasting a tutorial, but the moment something broke — a container that couldn't reach another container, a service that was unreachable from outside a cluster, a security group that silently ate my traffic — I had no mental model to debug with. So I went back and actually built one, layer by layer, from a single IP address up to how Kubernetes routes traffic across a cluster. This post is that mental model, written the way I wish someone had explained it to me first. Start With the Absolute Basics IP Address — the identifier for a device or server on a network. Every machine that wants to send or receive data needs one, the same way every house needs an address for mail to find it. DNS (Domain Name System) — the system that maps human-readable domain names to IP addresses. You type google.com , your machine asks a DNS server "what's the IP for this," and gets back something like 142.250.183.14 . Nobody memorizes IP addresses; DNS is the reason you don't have to. Ports — numbered channels on a server. A single machine can run many applications at once, and ports are how traffic knows which application it's meant for. A handful worth knowing cold: Port Service 22 SSH 53 DNS 80 HTTP (web servers) 443 HTTPS 3306 MySQL 5432 PostgreSQL 6379 Redis 27017 MongoDB If DNS gets you to the right server and the IP address gets you to the right machine, the port gets you to the right application on that machine. Subnets, Routing, and Firewalls Subnets let you divide one network into smaller, isolated segments — instead of every device

I work at a B2B telecom consultancy. I'm not the one auditing the bills, but every month I watch how it's done: open the invoice PDF, check every line against the signed contract, compare it with what the account used in earlier cycles, and write up whatever doesn't add up. It's slow, it doesn't scale, and it's the first task dropped when the month gets busy — which is exactly when the money leaks. And outside a consultancy it's worse: most companies just pay the bill because it arrived. So I built an agent that does the whole job. One invoice PDF in; a dispute letter for the carrier and an executive summary for the customer out, with nobody in the loop. It runs on Gemini 3.5 Flash and the Google ADK, on Cloud Run and Firestore, and it's open source: github.com/Bren0-lz/invoice-sentinel . This post is about the one decision that shaped everything else, and about the four defects that only showed up when I stopped reading my own code and started attacking the running service. The decision: no money figure ever comes out of the LLM An agent that writes a dispute letter is writing a document addressed to a third party and signed by the customer. If a figure in it is invented, the customer doesn't lose a feature — they lose credibility with their own supplier, and they lose it in writing. So the rule is absolute, and it isn't a line in a prompt. It's enforced in three layers, each of which would have to fail independently: Structurally. The rule engine is pure Python with Decimal . No module under rules/ imports an LLM client. Five rules across three families, running concurrently under a ParallelAgent . In the tool signatures. No auditor tool accepts a monetary value as an argument. flag_anomaly(finding_id, rationale) cannot be talked into disputing four thousand reais that nobody computed, because there is no parameter to put it in. A test asserts this with inspect.signature , so the guarantee survives someone adding a tool later. In the generated prose. amount_guard

Cloudflare AI Search is a built-in search and retrieval service designed to give AI agents and applications a ready-to-use search engine over custom data. It supports agent integration, multimodal search, and seamless integration with other Cloudflare tools. By Sergio De Simone

​ Managing academic records , student enrollments and staff communication across educational institutions requires speed, reliability, and security. Legacy school management systems are often slow, difficult to navigate, and bogged down by bloated software architectures. ​At SkyBuild Technologies, we designed and developed EduSky (edusky.skybuildtechnologies.com)—a modern, cloud-native and multi-tenant school management platform engineered to streamline administrative workflows and deliver instant access to institutional data. ​Here is an insider breakdown of how we architected and deployed EduSky using a modern tech stack centered on React, Tailwind CSS, and Supabase. ​1. Core Platform Architecture & Key Features ​EduSky was engineered to solve the most pressing pain points faced by school administrators, teachers, students and guardians/parents: ​ Centralized Student & Staff Portals : Secure management of student profiles, academic histories, staff credentials, and class assignments. ​ Real-Time Academic & Report Management : Streamlined record-keeping for grades, subject performance, and automated term report generation. ​ Administrative Controls & Access Levels : Granular Role-Based Access Control (RBAC) ensuring administrative staff, teachers, and parents access only authorized operational data. ​Fast, Mobile-First User Interface: Built with a responsive layout optimized for desktop administration and mobile access on smartphone screens. ​2. The Technical Stack : High Speed, Zero Bloat ​Rather than relying on legacy web setups, we built EduSky using a modern, decoupled architecture designed for sub-second load times and high availability: ​ Frontend : React + Tailwind CSS ​Dynamic Component Architecture: Built using React for modular, maintainable UI components (data tables, form inputs, dynamic dashboards). ​ Utility-First Styling : Styled with Tailwind CSS to maintain a light footprint, rapid UI iteration, and responsive mobile-first views. ​ Optimized State

After development comes deployment - whether on-premise or on a cloud based environment. And then we face a simple question: how much resource should I assign to this system? What is the ideal numbers? If we get this wrong, we often need to go back time and again to fine tune - either to ensure our application is capable of handling the targeted load, or to avoid paying for resources we are not using. This article explains the approach step by step. So that we spend just enough time upfront to avoid spending exponentially more time and money at later stages. Who Is This For? This article is written primarily for developers. But if you are a manager or a CTO, there are sections written specifically for you. Feel free to jump straight there. 👉 If you are a Manager or Project Manager 👉 If you are a CTO or Architect For everyone else - the full article is worth reading top to bottom at least once. But if you are revisiting a specific topic, jump to whatever is relevant. Table of Contents Local is the Starting Point When Should You Start Thinking About Right Sizing? How Long Will This Actually Take? Start With What You Have - Your Local Setup Setting Up Your Load Generation - The Hammer The Cost of Testing - This Is Not Free Sizing Your Pod More Resources Per Pod or More Pods? Scaling - Easy to Set Up, Hard to Get Right Periodic Right-Sizing - You Are Not Done Yet Local is the Starting Point Local system is always where we start. To try things out, to check if things work. But 99% of what we test locally is the sunny day scenario. Does the MVP work? Does the happy path hold? Even if you're diligent enough to test negative scenarios, you're almost certainly not testing production-level load on your laptop. Which means you have no idea what resources your app actually needs when it matters . This is where the problem starts. On local, we routinely kill the heavy IDE, close browser tabs, shut down background processes -without ever stopping to ask: how much memory and CPU d