<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cloud Computing on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/cloud-computing/</link><description>Recent content in Cloud Computing on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 09 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/cloud-computing/index.xml" rel="self" type="application/rss+xml"/><item><title>Alibaba Cloud Full Stack (12): End-to-End — One Terraform Apply for Everything</title><link>https://www.chenk.top/en/aliyun-fullstack/12-terraform-e2e/</link><pubDate>Sat, 09 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/12-terraform-e2e/</guid><description>&lt;p>Eleven articles. Dozens of CLI commands. Hundreds of manual steps. Now we throw all of that away and rebuild the entire stack with a single &lt;code>terraform apply&lt;/code>. This is why infrastructure-as-code exists.&lt;/p>
&lt;p>Over the past eleven parts of this series, we have clicked through consoles, typed &lt;code>aliyun&lt;/code> CLI commands, and manually configured everything from VPCs to Function Compute triggers. It worked. We learned every resource intimately because we built each one by hand. But if I asked you right now to recreate that entire stack in a new region — the VPC with its three tiers and two availability zones, the ECS instance with its cloud-init script, the RDS MySQL HA setup, the OSS bucket with lifecycle rules, the RAM policies, the SLS log pipeline, the Function Compute event processing — you would need at least a full day of careful work. And you would inevitably miss something. A security group rule. A backup policy. A CORS configuration.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (11): PAI — The ML Platform</title><link>https://www.chenk.top/en/aliyun-fullstack/11-pai-ml-platform/</link><pubDate>Fri, 08 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/11-pai-ml-platform/</guid><description>&lt;p>Training a model on a single GPU is fun. Deploying it to handle 1,000 requests per second without failing is what separates experiments from products. PAI handles both.&lt;/p>
&lt;p>PAI (Platform for AI) is Alibaba Cloud&amp;rsquo;s managed ML platform. It&amp;rsquo;s not just one product; it&amp;rsquo;s five products in a trench coat, sharing a console. These include a notebook environment for exploration, a distributed training service for scale, a model serving platform for production, a visual pipeline designer for those who prefer dragging boxes, and a model gallery for one-click deployment of open-source models. After eighteen months of running real LLM workloads on it, I can say that the individual components range from excellent (EAS) to good enough (Designer). The whole platform is genuinely greater than the sum of its parts once you understand how they connect.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (10): Bailian and DashScope — The LLM Layer</title><link>https://www.chenk.top/en/aliyun-fullstack/10-bailian-llm/</link><pubDate>Thu, 07 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/10-bailian-llm/</guid><description>&lt;p>When I first needed an LLM API for a production app in China, my options were limited and expensive. Most international providers had no mainland endpoint, billing required a foreign credit card, and latency from calling US-based APIs was 800ms+ before a single token came back. Then Qwen showed up on DashScope with an OpenAI-compatible endpoint, and suddenly building AI products in China became as straightforward as anywhere else. Same SDK, same request shape, same streaming protocol — just a different &lt;code>base_url&lt;/code> and a key from the Bailian console. I have been running production workloads against it for over a year now, and this article is the comprehensive walkthrough I wish I had on day one.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (9): OpenSearch and AI Search</title><link>https://www.chenk.top/en/aliyun-fullstack/09-opensearch/</link><pubDate>Wed, 06 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/09-opensearch/</guid><description>&lt;p>I built my first search engine with Elasticsearch and a pile of synonyms. It took six months to get decent results. Every week, users complained about missing results, so I added more synonyms, broke something else, and added exception rules. The relevance tuning spreadsheet grew to 400 rows. I had custom analyzers for three languages, a boosting config that no one understood (including me), and a reindexing job that took four hours. Then I tried hybrid vector+keyword search on a side project and got better results on day one. Not marginally better — &amp;ldquo;users stopped complaining&amp;rdquo; better. That experience completely changed how I think about search, and it&amp;rsquo;s the reason this article exists.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (8): Serverless — Function Compute and EventBridge</title><link>https://www.chenk.top/en/aliyun-fullstack/08-serverless/</link><pubDate>Tue, 05 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/08-serverless/</guid><description>&lt;p>The first time I saw a Function Compute bill that was 0.03 CNY for handling 10,000 requests, I started rethinking my entire architecture. I had been running a 2-vCPU ECS instance 24/7 to serve an API that processed maybe 200 requests per hour, paying around 490 CNY/month. The same workload on Function Compute cost under 5 CNY/month. Not 5 CNY per day — 5 CNY per month. The math was so lopsided that I spent the next weekend migrating everything that did not need a persistent process off ECS and onto functions.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (7): SLS, CloudMonitor, and Observability</title><link>https://www.chenk.top/en/aliyun-fullstack/07-observability/</link><pubDate>Mon, 04 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/07-observability/</guid><description>&lt;p>The worst production outage I ever caused took three hours to diagnose. A Node.js service was returning 502s intermittently — maybe 5% of requests — and I had nothing. No centralized logs (each ECS instance had its own &lt;code>/var/log/&lt;/code> and I was SSH-ing into them one at a time). No metrics dashboards (I was running &lt;code>top&lt;/code> and &lt;code>df -h&lt;/code> in terminals). No tracing (I was adding &lt;code>console.log&lt;/code> timestamps to try to figure out which downstream call was hanging). Three hours later, I found the issue: a connection pool to RDS was exhausting under load because a forgotten cron job was holding connections open. The fix was two lines of code. The diagnosis took three hours of misery because I had zero observability.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (6): RAM, KMS, and Cloud Security</title><link>https://www.chenk.top/en/aliyun-fullstack/06-ram-security/</link><pubDate>Sun, 03 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/06-ram-security/</guid><description>&lt;p>I once found a DashScope API key hardcoded in a public GitHub repo. It was mine. Someone had forked a demo I pushed months earlier, and the key was sitting in a config file I forgot to gitignore. By the time I noticed, the key had been used to generate 14,000 Qwen API calls in a single weekend. The bill was not catastrophic — DashScope per-token pricing is forgiving — but the lesson was. I had treated cloud security as something I would figure out later. &amp;ldquo;Later&amp;rdquo; arrived as a billing alert at 2 AM on a Sunday.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (5): RDS and PolarDB — The Database Layer</title><link>https://www.chenk.top/en/aliyun-fullstack/05-rds-database/</link><pubDate>Sat, 02 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/05-rds-database/</guid><description>&lt;p>My self-managed MySQL on ECS lasted exactly four months before a disk I/O spike during peak traffic brought the whole thing down. The InnoDB buffer pool was fighting the OS page cache for memory, the binary log was filling the system disk faster than my cron job could rotate it, and the single-threaded replication to my &amp;ldquo;backup&amp;rdquo; instance was nine hours behind. I fixed it at 3 AM by throwing more disk at it. Then it happened again two weeks later. That is the day I learned why managed databases exist — not because I cannot run MySQL, but because I do not want to be the person paged at 3 AM when MySQL decides the relay log is corrupted and the only fix is to rebuild the replica from a cold backup that may or may not be consistent.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (4): OSS — Object Storage Done Right</title><link>https://www.chenk.top/en/aliyun-fullstack/04-oss-storage/</link><pubDate>Fri, 01 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/04-oss-storage/</guid><description>&lt;p>I used to store user uploads on the ECS disk. Profile pictures, PDF invoices, CSV exports — all dumped into &lt;code>/var/data/uploads/&lt;/code> on a single &lt;code>ecs.g7.large&lt;/code> running my Flask app. I had a cron job that rsynced the directory to a second ECS instance every six hours as a &amp;ldquo;backup.&amp;rdquo; Then one Friday at 3am, the system disk hit 100% because a batch job generated 40GB of reports nobody ever downloaded, the instance went read-only, the app crashed, and the rsync hadn&amp;rsquo;t run since the previous evening. I lost six hours of user uploads and spent the weekend apologizing to customers. That was the week I learned that object storage is not a nice-to-have — it is the foundation of everything you build in the cloud. Your application server is ephemeral. Your data is not.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (3): VPC, SLB, and the Network Layer</title><link>https://www.chenk.top/en/aliyun-fullstack/03-vpc-networking/</link><pubDate>Thu, 30 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/03-vpc-networking/</guid><description>&lt;p>Every outage I have debugged in the cloud ultimately traced back to networking. Bad CIDR planning that ran out of IPs six months in. Missing routes that silently dropped traffic between tiers. Security groups that were either wide open (hello, port 22 to &lt;code>0.0.0.0/0&lt;/code>) or so locked down that health checks failed and the load balancer kept draining healthy instances. Getting the network layer right is the single most important thing you can do before deploying anything else, and it is the single most painful thing to fix retroactively because changing a VPC CIDR means recreating everything inside it.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (2): ECS — Compute That Actually Makes Sense</title><link>https://www.chenk.top/en/aliyun-fullstack/02-ecs-compute/</link><pubDate>Wed, 29 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/02-ecs-compute/</guid><description>&lt;p>The first ECS instance I ever launched was wildly over-provisioned. I picked the biggest instance I could find — an &lt;code>ecs.r6.8xlarge&lt;/code> with 32 vCPUs and 256 GiB RAM — to run a Flask app that served maybe 20 requests per minute. I burned through credits in a week, panicked, learned how to downsize online, and discovered my app ran perfectly on a 2-vCPU box costing 94% less. Right-sizing matters more than raw power, and understanding the compute layer is the single most useful thing you can learn about any cloud platform.&lt;/p></description></item><item><title>Alibaba Cloud Full Stack (1): The Ecosystem Map — What Alibaba Cloud Actually Is</title><link>https://www.chenk.top/en/aliyun-fullstack/01-ecosystem-map/</link><pubDate>Tue, 28 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/01-ecosystem-map/</guid><description>&lt;p>I spent my first week on Alibaba Cloud completely lost in a sea of product names. ECS, SLB, SLS, RDS, OSS, NAS, PAI, ARMS, ACK, FC, CDN, WAF, RAM, KMS, ROS, CloudMonitor, EventBridge, PolarDB, Lindorm, AnalyticDB, MaxCompute, DataWorks, Flink, DashScope, Bailian, OpenSearch&amp;hellip; Every console page links to three more products I haven&amp;rsquo;t heard of. The documentation assumes you already know what everything is. The English translations are sometimes literal, sometimes creative, and occasionally missing. This is the guide I wish someone had handed me before I burned my first weekend clicking through consoles and reading translated docs that explained feature flags without ever explaining what the product does.&lt;/p></description></item><item><title>LAMP Stack on Alibaba Cloud ECS: From Fresh Instance to Production-Ready Web Server</title><link>https://www.chenk.top/en/standalone/lamp-on-ecs/</link><pubDate>Wed, 28 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/standalone/lamp-on-ecs/</guid><description>&lt;p>You have a fresh ECS instance and SSH access. Your goal is to run a public website with Apache, PHP, and MySQL. Three common issues often trip up beginners:&lt;/p>
&lt;ol>
&lt;li>&lt;strong>Network reachability&lt;/strong> — packets are silently dropped by the cloud security group, the OS firewall, or the listening socket, and the symptom is always the same: nothing happens.&lt;/li>
&lt;li>&lt;strong>Service wiring&lt;/strong> — Apache, PHP, and MySQL are separate processes that need to find each other through file extensions, Unix sockets, and TCP ports. Each interface has its own way to fail.&lt;/li>
&lt;li>&lt;strong>Identity and permissions&lt;/strong> — Apache runs as &lt;code>www-data&lt;/code>, MySQL runs as &lt;code>mysql&lt;/code>, files are owned by &lt;code>root&lt;/code> after &lt;code>wget&lt;/code>. The wrong combination produces 403, &amp;ldquo;Access denied&amp;rdquo;, or &lt;code>chmod 777&lt;/code> desperation.&lt;/li>
&lt;/ol>
&lt;p>This guide covers these issues in the order you&amp;rsquo;ll encounter them on day one and continues with topics that arise later, such as TLS, virtual hosts, backups, source compilation, and when to stop running everything on a single box.&lt;/p></description></item><item><title>Cloud Computing (8): Multi-Cloud and Hybrid Architecture</title><link>https://www.chenk.top/en/cloud-computing/multi-cloud-hybrid/</link><pubDate>Wed, 14 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/multi-cloud-hybrid/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/multi-cloud-hybrid/illustration_1.png" alt="Cloud Computing (8): Multi-Cloud and Hybrid Architecture — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>The first article in this series asked, &amp;ldquo;What is the cloud, and why does it matter?&amp;rdquo; Eight articles later, the question has evolved into something more practical: &lt;strong>Which clouds, in what combination, and how do you manage them without losing your mind?&lt;/strong> Multi-cloud and hybrid architectures are how serious organizations answer that question. They distribute workloads across providers and on-premises infrastructure for resilience, cost optimization, and strategic flexibility — but they introduce a new class of problems that single-cloud architectures never face.&lt;/p></description></item><item><title>Cloud Computing (7): Cloud Operations and DevOps Practices</title><link>https://www.chenk.top/en/cloud-computing/operations-devops/</link><pubDate>Fri, 26 May 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/operations-devops/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/operations-devops/illustration_1.png" alt="Cloud Computing (7): Cloud Operations and DevOps Practices — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>In 2017 GitLab lost six hours of database state. An engineer, exhausted, ran &lt;code>rm -rf&lt;/code> on the wrong server during an incident. The backup procedures had silently been broken for months; nobody noticed because no one was restoring from backups. The lesson is not &amp;ldquo;be careful with rm&amp;rdquo;. The lesson is that operations is a &lt;em>system&lt;/em> — tools, runbooks, monitoring, automation, and the rituals around them. When the system is healthy, no single tired engineer can take down production. When the system is rotten, every late-night fix is one keystroke from disaster.&lt;/p></description></item><item><title>Cloud Computing (6): Cloud Security and Privacy Protection</title><link>https://www.chenk.top/en/cloud-computing/security-privacy/</link><pubDate>Sun, 07 May 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/security-privacy/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/security-privacy/illustration_1.png" alt="Cloud Computing (6): Cloud Security and Privacy Protection — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>In 2019 Capital One lost a hundred million customer records. The exploit chain was small: a misconfigured WAF allowed server-side request forgery against the EC2 metadata endpoint, that endpoint handed back IAM credentials, and the IAM role those credentials belonged to had wildcard &lt;code>s3:*&lt;/code> on every bucket in the account. One misconfiguration, one over-broad role, one rule the security team had not written. The bill, before legal: more than 80 million dollars.&lt;/p></description></item><item><title>Cloud Computing (5): Cloud Network Architecture and SDN</title><link>https://www.chenk.top/en/cloud-computing/networking-sdn/</link><pubDate>Tue, 18 Apr 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/networking-sdn/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/networking-sdn/illustration_1.png" alt="Cloud Computing (5): Cloud Network Architecture and SDN — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>A cloud platform is essentially a network with attached computers. The compute layer scales by adding servers; the storage layer scales by adding disks; the &lt;em>network&lt;/em> layer integrates these into a single, coherent system. Get the network right, and the rest of the stack feels effortless. Get it wrong — a missing route, a 5-tuple mismatch in a security group, or an under-provisioned load balancer — and the whole platform goes dark.&lt;/p></description></item><item><title>Cloud Computing (4): Cloud Storage Systems and Distributed Architecture</title><link>https://www.chenk.top/en/cloud-computing/storage-systems/</link><pubDate>Thu, 30 Mar 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/storage-systems/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/storage-systems/illustration_1.png" alt="Cloud Computing (4): Cloud Storage Systems and Distributed Architecture — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>When Netflix stores petabytes of video, when Instagram serves billions of photos, when a quant fund replays a year of market data in minutes — behind every one of these workloads is a &lt;em>distributed storage system&lt;/em>. Storage looks deceptively simple from a developer&amp;rsquo;s window (&lt;code>PUT key&lt;/code>, &lt;code>GET key&lt;/code>), but the moment you cross the boundary of a single machine, you inherit a stack of problems that has driven decades of research: how to survive disk failures, how to scale linearly, how to provide a consistency model that does not surprise the application, and how to do all of this while paying cents per gigabyte rather than dollars.&lt;/p></description></item><item><title>Cloud Computing (3): Cloud-Native and Container Technologies</title><link>https://www.chenk.top/en/cloud-computing/cloud-native-containers/</link><pubDate>Sat, 11 Mar 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/cloud-native-containers/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/cloud-native-containers/illustration_1.png" alt="Cloud Computing (3): Cloud-Native and Container Technologies — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>The shift from monolithic applications to cloud-native architectures is one of the most consequential changes in software engineering this decade. The headline — containers and Kubernetes — is well known. The interesting story is &lt;em>why&lt;/em> this stack won, what each layer actually does, and where the seams are that determine whether your platform feels effortless or feels like a maze.&lt;/p></description></item><item><title>Cloud Computing (2): Virtualization Technology Deep Dive</title><link>https://www.chenk.top/en/cloud-computing/virtualization/</link><pubDate>Mon, 20 Feb 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/virtualization/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/virtualization/illustration_1.png" alt="Cloud Computing (2): Virtualization Technology Deep Dive — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>Without virtualization, there is no cloud. Every EC2 instance, every Lambda invocation, every Kubernetes pod ultimately stands on the same trick: lying convincingly to an operating system about the hardware underneath it. This article walks the full stack — from the CPU instructions that make the trick cheap, through the four hypervisors that dominate the market, to the production-grade tuning knobs that decide whether your VMs run at 70 % or 99 % of bare metal.&lt;/p></description></item><item><title>Cloud Computing (1): Fundamentals and Architecture</title><link>https://www.chenk.top/en/cloud-computing/fundamentals/</link><pubDate>Wed, 01 Feb 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/fundamentals/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/fundamentals/illustration_1.png" alt="Cloud Computing (1): Fundamentals and Architecture — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>Every team building software in 2025 inherits the same buy-or-rent question their predecessors faced — only the answer has flipped. Twenty years ago you put hardware in a closet; today you describe the hardware in YAML and a global provider conjures it up in seconds, bills it by the second, and tears it down when you stop paying. Cloud computing is not just &amp;ldquo;someone else&amp;rsquo;s computer&amp;rdquo;. It is a programmable, metered, multi-tenant abstraction over compute, storage and networking that has fundamentally changed how businesses are built and how engineers spend their day.&lt;/p></description></item></channel></rss>