I used Alibaba Cloud’s CDN and object storage for roughly ten years. My blog images, videos, and music accumulated over the years all lived in that storage bucket — over eighty thousand objects, more than 60 GB.
This April, I interviewed for a CDN-related position at Alibaba Cloud. The reason they ultimately gave for turning me down: age.
Put those two things together, and I migrated everything I’d been using for a decade: all domains switched away from their CDN, object storage is being cleared out, and when the servers expire next year I won’t renew.
1. Any Other Reason I Could Accept, Except “Age”
An interview is a two-way street by nature. You can absolutely say my tech stack doesn’t match, that the role’s direction changed, that my credentials aren’t impressive, or even just tell me straight “we’ve already decided internally” — all of that I can take, because those are judgments.
But “you’re too old” isn’t a judgment, it’s a filter. It has absolutely nothing to do with whether I can do the job well.
What made me even more uncomfortable was the gap: I’d been paying real money for years, renewing CDN and object storage every year — by any measure a long-standing customer — and all that earned me was that one reason. I’m not asking anyone to apologize; what I can do is adjust my own technical choices — and that’s the sole motivation behind this post.
2. A 2019 Blog Post Got Flagged by Content Moderation
Besides people, there are also rules.
An article I wrote in 2019 was flagged as problematic by their content-safety system, and the page became inaccessible. The post was about my own life, involved no technical risk whatsoever, sat there quietly for years, and then one day it suddenly didn’t pass.
I understand that platforms need to comply with regulations, and I never tried to circumvent a single rule. But when the cost of normal writing becomes “file repeated appeals, rewrite, and still not know when it’ll get flagged again,” the platform’s utility to me becomes extremely limited. I can’t change the rules; what I can change is where my stuff lives.
3. Migrating Wasn’t Actually Hard — Here’s What I Did
The real migration took only a few evenings. The prerequisite: you need a machine that stays on, and a network tunnel back home. My approach breaks into four layers.
Two separate storage sets. One for music, one for images, videos, and documents — physically separated so they don’t affect each other. During migration I first pulled all objects back locally by prefix, compared key lists item by item, confirmed the local copy was a complete mirror (nothing missing, nothing extra), and only then deleted objects from the cloud. You can’t rush this step — object storage didn’t have versioning enabled, so a mistaken delete is permanent. In fact, the first comparison round caught over two hundred files that existed “only in the cloud, not locally.” Had I deleted right away, those would have been lost.
File access requires signed URLs. Static files are served by an unprivileged nginx instance; only URLs carrying a valid time-limited signature can fetch a file. The signature is issued by a tiny Python service. Both run under user-level systemd, starting on boot. This way, even if a link gets forwarded, it expires.
Reuse existing public server as the entry point. No new machine on the public-network side; the existing one serves as a reverse proxy, tunneling back to the home machine over a private-network link. All DNS is managed by Cloudflare. The full chain: domain → Cloudflare → public entry → tunnel → home machine.
The math. The biggest expense used to be outbound traffic from object storage, billed per GB, and the peak-hour rate wasn’t cheap. After migration, that becomes the fixed monthly cost of home broadband; storage is on my own drives, signing rules are mine to define. The only unavoidable cost was the one-time egress during migration — tens of GB amounts to a few yuan to maybe ten-something yuan, negligible compared to the long-term bill.
4. The Costs of Self-Hosting, and Who I’d Advise Against It
Migration doesn’t mean everything’s rosy. What I really want to talk about is the cost.
If the internet goes down at home, or that machine shuts off, my blog images and music become inaccessible. That’s the hardest price of self-hosting. If you can’t accept it, don’t self-host.
Maintenance responsibility also shifts entirely to me: certificates, signatures, backups, monitoring — all of that used to be part of the cloud vendor’s “service,” and now it’s all my job. So I wrote a daily health-check script that verifies DNS resolution, reverse-proxy upstream resolution, whether certificate files exist, and whether nginx config syntax passes — and alerts me if anything’s wrong.
The motivation was very concrete: one upstream domain’s DNS record had been deleted long ago, but nginx config still referenced it, causing config checks to fail continuously. That machine hadn’t been able to reload properly for nine days — the kind of pitfall a cloud vendor won’t catch for you. You have to watch it yourself.
So when would I not recommend self-hosting: if you’re just hosting a few images with occasional access, the cloud really is more hassle-free — don’t do ops work out of spite. Self-hosting only makes sense when you already have a machine that stays on, and you’re genuinely blocked by platform rules.
5. Next Year, I Won’t Renew the Servers Either
Migration isn’t a one-time action; it’s a choice: taking back the part I can control.
Right now the CDN has been fully switched over, object storage is being cleared, the file library has been completely synced to my own machine; next year when the servers expire, I won’t renew.
At the end of the day it boils down to one sentence: you can always change your tech stack, but being treated with respect isn’t optional.
评论
0 条评论