Paradigm-Shift

"Paradigm-Shift"

2026-06-16 從 Firestore 遷往自建 relational：撞牆驅動的 Type E 重建模、存取模型反轉與並行期 Firestore → 自建後端 + relational 不是匯資料而是反轉存取模型：client 直連變 API 中介、Security Rules 授權變後端授權、document 反正規化變正規 schema、realtime listener 與 offline 同步要重建；本文走 Type E paradigm shift 結構、展開為何字面遷移不成立、哪些該遷哪些先留、dual-write + shadow read 階段化與遷出代價判讀
2026-05-19 Docker Swarm → Kubernetes：5 個 Swarm production cluster 撞牆數據 Docker Swarm → Kubernetes 是 Type E paradigm shift — Swarm「simpler container orchestration」設計上限在 100-200 service 規模、跨 application 服務治理時 paradigm 不足；本文用 5 個 production cluster 量化數據開頭、5 個 production 踩雷
2026-05-19 Sentry → Honeycomb：trace 不是 error、是不同 observability paradigm Sentry → Honeycomb 是 paradigm shift — Sentry 主軸是 error tracking + transaction trace、Honeycomb 主軸是 high-cardinality wide-event observability；本文釐清 paradigm 邊界、5 個 production 踩雷（event schema 對位 / sampling 行為 / error grouping 失效 / cost 模型差 / alert paradigm shift）
2026-05-19 etcd → Consul：KV + N 個 extras feature matrix etcd → Consul 是 Type E paradigm shift expansion — 從 pure KV store 升到 service mesh / discovery / health check / multi-DC；本文用對照表 + paradigm expansion 路線、5 個 production 踩雷（API 對位 / lock semantics / watch event model / multi-DC topology / ACL system）
2026-05-19 Redis → Memcached：Memcached 不是 simpler Redis、是 cache paradigm Redis → Memcached 是 Type E paradigm reduction migration — 從 multi-paradigm（KV + 資料結構 + pub/sub + Lua + streams）退到 pure cache；不是「remove Redis features」、是「重新分配 Redis-specific feature 到對應 specialized 服務」；5 個 production 踩雷 + paradigm reduction 路線
2026-05-19 MySQL 5.7 → 8.0 Major Version Upgrade：character set / authentication / atomic DDL 三條 paradigm 同時換軌 MySQL 5.7 → 8.0 三條 default 同時改：charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。
2026-05-19 MySQL → PlanetScale：managed Vitess + branch-based schema workflow 的 hybrid shift 自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit（Paradigm + Operational + Schema 多軸）、4-phase migration、5 production 踩雷、何時不要遷。
2026-06-02 從 RDS / MongoDB 遷移到 DynamoDB：access-pattern-first 重建模、混合架構與 cost crossover RDS / MongoDB → DynamoDB 不是搬 schema 而是換 paradigm；本文走 Type E paradigm shift 結構，展開為何字面遷移不成立、access pattern 重建模、哪些 workload 該遷哪些該留的混合架構、dual-write + shadow read 階段化，以及 Zomato cost crossover 的長期成本判讀
2026-05-19 PostgreSQL → CockroachDB：三維皆 High 的多重歸類 migration PostgreSQL → CockroachDB 是 Schema / Operational / Paradigm 三維皆 High 的 multi-axis migration、實證 [#127](/report/content-structure-by-max-diff-dimension/) 的「多重歸類跟 tie-breaking」規則；主結構走 Type E paradigm shift、Schema 差 + Operational redesign 抽出獨立段；涵蓋 transaction model 重設計、SQL dialect gap、5 個 production 踩雷
2026-05-19 JMeter → k6：k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit（Schema High / Paradigm High / Operational Medium）、釐清反向定義、4-phase partial migration（多數 org 停 Phase 2-3 hybrid）、5 production 踩雷（thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做）、protocol gap（JDBC / JMS / LDAP 在 k6 沒原生對應）、何時不要切
2026-05-19 PagerDuty → incident.io：「On-call」是個 retconned word、同名不同 contract PagerDuty → incident.io 不是 schema translation — 兩家的「on-call」字面相同、contract 不同（alert routing vs IR coordination + Slack-native + retrospective）。本文走 Type E paradigm shift、6 維 audit 顯示 paradigm / schema / operational 三軸 High、用 4-phase partial migration（不收斂、Phase 1-2 多數 org 停留）、5 個 production 踩雷（雙系統 state drift / severity 翻譯失真 / schedule layer 漏 / Slack channel 過載 / retrospective 斷層）、跟 PagerDuty Process Automation / AIOps 沒對應的 capability gap