Why Automation Scripts Still Matter in the Age of Kubernetes

All writing business, no one should look down on anyone

I worked for two years as an operations developer at Tencent Games, writing scripts for opening game zones, merging zones, and automatically replacing faulty machines. I wondered whether this counts as game development and how it differs from writing backend services.

In the past year I have been building WeChat mini‑programs and found that many business features blur the line between traditional backend development and operations automation. For example, a one‑click button that uploads code to the WeChat third‑party platform, submits for review, and triggers deployment is a user‑facing feature but essentially an automated operation.

People often distinguish backend code from ops scripts by whether a new process is started or new code is deployed. In networking, the control‑plane vs data‑plane distinction is similar, with ops scripts aligning more with the control plane.

Regardless of whether the UI is prettier, the database operations are idempotent, or a new process is deployed, these are all business logic performed by code and should not be looked down upon.

Casual deployment cannot be stable

The purpose of deployment is to "replicate an environment" for different customers, regions, or stages (development, production). Consistency is required while accommodating necessary differences. Common techniques include:

Ops scripts that modify existing hardware/software configuration.

Maintaining the state of images, such as a CMDB.

Infrastructure as Code (IaC) – managing scattered scripts in a Git repository.

Immutable servers/infrastructure – shortening the lifecycle of a state to avoid drift, often by provisioning a fresh VM each time.

Combining image state, IaC, and immutability – a YAML‑driven model like Kubernetes.

In my experience, no matter how advanced the technology, you cannot arbitrarily deploy a brand‑new environment. Do not idolize Kubernetes, nor despise ops scripts.

Immutable is an illusion: Not all states (e.g., databases, S3 buckets) can be cheaply recreated; most APIs are mutable.

All abstraction leaks: When a YAML apply fails, you still need to understand each resource and how the engine works.

Unstable dependencies: Scripts rely on npm, Ubuntu repositories, etc.; full reproducibility is unrealistic.

State + version explosion: Mutable state combined with new code versions creates countless possible combinations, making guarantees impossible.

State transition process: Upgrading a WeChat mini‑program from version 1 to version 2 still requires scripted steps despite immutable declarations.

These factors mean a single automation script cannot guarantee that any user can click a button and obtain a new, identical environment. Scripts must be continuously maintained, and larger‑scale environments require dedicated upkeep.

Multi‑tenant is the ultimate solution

Automation is necessary for rapid recovery and cross‑region deployments, but relying solely on scripts is fragile. A balanced approach is to have a dedicated team maintain both the deployment scripts and the resulting environments, then expose those environments as multi‑tenant instances. New customers or developers can rent a tenant on an existing environment.

This multi‑tenant system resembles an operating system; script writers become its developers.

Source: https://zhuanlan.zhihu.com/p/366859735