Company forgets why they exist after 11-week migration to Kubernetes (2020)

Original Article ↗ Hacker News Discussion ↗

A satirical article about a company “forgetting” its purpose after an 11‑week Kubernetes migration prompts engineers to reflect on real-world overengineering and tech-chasing. Many describe multi‑year platform migrations that stall product roadmaps, driven by resume-driven development, misaligned incentives, and fascination with new tools rather than business needs. Commenters argue for tighter scope, incremental change, and focusing on the actual product instead of complex infrastructure for its own sake.

Satire and tone of the article

  • Many readers quickly recognize it as parody, comparing it to Silicon Valley-style satire.
  • The psychic / material-design joke and the punchline about forgetting the product’s purpose land well.
  • Several note other posts on the same blog hit uncomfortably close to reality, blurring line between satire and truth.

Real-world Kubernetes migration experiences

  • Multiple commenters say an 11‑week migration would actually be a massive success; their companies are 1–3+ years into unfinished K8s/platform migrations.
  • Others argue that if you already run Docker and have simple systems, 11 weeks “should” be enough.
  • This “should” is challenged by people describing messy realities: ancient mainframes, outdated Java, license locks tied to hardware, unknown external dependencies, strict corporate policies, and bureaucracy.
  • Some report partial migrations (e.g., 30% done after 2 years) with product roadmaps paused to focus on platform work.

Tech stack obsession vs business value

  • Core interpretation: teams obsess over Kubernetes / new stacks and forget what the product is for.
  • Several describe companies “cosplaying” big tech, despite being primarily sales or business orgs with modest technical needs.
  • Migrations often lack a clear business problem; sometimes existing setups (e.g., ECS) work fine.

Cloud and Kubernetes strategy debate

  • One camp: if you’re not in the infra business, use off‑the‑shelf cloud and avoid self‑managed K8s; it adds cost, complexity, and headcount.
  • Another camp: managed Kubernetes (EKS, etc.) is often sensible and can reduce lock‑in and enable scalable, geo‑distributed setups.
  • Debate touches on cloud cost surprises (especially egress, NAT, assorted hidden charges) and whether multi‑cloud/portability fears are justified.

Scope creep and migration practices

  • A commonly cited failure pattern: using a K8s migration to simultaneously upgrade libraries, change databases, and re‑architect systems.
  • Advice from practitioners:
    • Learn on small, low‑risk services first.
    • Do one major change at a time.
    • Start with the simplest viable setup; add tools like GitOps automation later.

Industry incentives and behavior

  • Promotions and recognition favor big, shiny projects over quietly maintaining reliable systems.
  • Resume‑driven development and love of proofs of concept push constant rewrites (K8s, GraphQL, React, AI) rather than incremental improvement.
  • Some see devops/platform churn as a form of job security; others blame management for matching incentives to change rather than value.