Hacker News new | ask | show | jobs
by 0xbadcafebee 2679 days ago
Step 1: implement Kubernetes

Step 2: completely transform your existing organization to be a matrix of agile teams with chargeback budgets aligned to resource use of shared services and collaborating on product lifecycles in scrum and kanban using full test coverage on both legacy and modern apps stored in asset-managed Docker containers in ci/cd pipelines triggered by Jira tickets deploying declarative immutable infrastructure and integrating an array of site reliability services that don't ship with k8s while adding policy and compliance enforcement with secret management and process auditing including in-line content filters using redundant services in multiple data centers without wasting resources or money

Step 3: document it

(I haven't read the book yet, so ymmv)

6 comments

You're joking but it's almost too accurate to be humorous. This is being foisted on us right now and it's giving me nearly crippling anxiety.
I absolutely loved the concept of containerization when I started working with it a few years ago. Docker provided such a perfect way to ensure my application would build and run correctly when I pushed things up to my servers.

Then came orchestration. Swarm was a bit slow to get out the door and is still buggy. K8s on the other hand shot past like a lightning bolt. While it evolved quickly, k8s has to be the one piece of software that I dread to work with the most. Setting up a cluster seems nearly impossible without compromising important features. Configuration is overly complex and difficult to discover. None of the (many) tools seem to do what I want.

In the end, I begrudgingly chose Docker Swarm because I was actually able to create a cluster that worked. Mind you, there are still truckloads of bugs that have sat gathering dust for years that I continue to run into. At least with this solution I'm somewhat productive.

May the heavens have mercy on your soul should you attempt any amount of networking in a cluster.

Kubernetes is hard because its trying to solve a hard problem. Agreed that cluster management itself is hard but GKE has been somewhat nicer to use.

If you can convince your organization to use GKE (Google Kubernetes Engine), your life will become simpler. Power of Kubernetes with none (almost!) of the pain.

> Kubernetes is hard because its trying to solve a hard problem.

Yeah, and for most of us it's a problem we don't actually have.

Use of these technologies seems aspirational to me. It's a kind of cargo-culting: as if using the methods of the software giants, will make your company into a software giant.

That's the problem I have with it. I'm supposed to fight with all this extra infrastructure and configuration...to deploy a standard php web app with 600 users.
If you have very simple use cases, you definitely do not need an orchestrator, or a cluster. The hype is too loud and pretends to be good for everyone when it's clearly not.

I want to coin a new term "SimpleOps": operations infrastructure which does not include complex components such as cluster orchestrators, service meshes, secret management, IAM, policy enforcement, telemetry processing engines, app tracing, and so on. If your app is simple, only use simple components and managed services.

You can still have DevOps best practices with very simple components, and it'll be easier to reason about, build, and run.

I generally use k8s. The updates come like a torrent, and it's impossible to stay on top of things unless it's your full time job. Every upgrade involves a lot of finger-crossing and hope that things won't break (the good news is, that generally it's fine).
Step 2 in your comment reads like poetry.

The sheer length of the sentence and the variety in vocabulary creates a rising, racing energy that forces you to stop and smile before you get to the end.

Beautifully written! I’m going to save a copy for myself.

He must be a PR/marketing guy
Nah, he did not use "leverage" or "synergy".
More like someone burned well and truly..
"It takes well over a million dollars just in engineer salary to get k8s up and running from scratch. And you still might not get there." - Cindy Sridharan[1](https://twitter.com/copyconstruct/status/1020880388464377856...)

That said, I'm running a few GKE clusters now with an 18-month old production codebase, and its kind of been a pleasure. That's a good portion of a million dollars in my pocket, no matter how the start-up fares after its done ;-)

[1][https://twitter.com/copyconstruct/status/1020880388464377856...

Step 4: audit controls against FFIEC and NIST

Step 5: begin remediation to remove suspiciously hands-off automations that a few dozen humans could do and check manually instead

Step 6: lift and shift another past due application into your old hyperconverged private cloud because ITIL is looking pretty good right now

Step 7: git pull upgraded K8s, go to Step 1

/s (typical enterprise IT allergic reaction)

You forgot the new and interesting bugs that come with k8s / docker
Bad Bus Ride on the K8S