Thread by @Adam_Hansrod

Let's talk about #Kubernetes and how you probably don't really need it, and how you should be tackling some hard problems for your org and your customers, not the k8s problems.
1/x

Let's start with use case no. 1:
You're dev team (in a scrappy startup, or big boy enterprise) and you've got a few devs but need to host your code/service somewhere, and you want to use k8s (assuming GKE/EKS/AKS being used and not rolling your own)
2/x

Pros:
+ Step up from current/recent deployment methods out there in the industry
+ GKE/EKS/AKS aren't horrendous!
+ Cost reductions are possible compared to many previous solutions
3/x

Cons:
- No natural cfg management for k8s resources, moving backwards on the whole immutable infrastructure thing (see gitops as the reactive solution to this)
- Yaml errrrywhere, taking step backwards terms of defining infrastructure as code and testing it
4/x

(please tell me if your using code + the client libraries for k8s resource creation, you might be my favourite people ever)
5/x

More cons:
- Upskilling dev team of how k8s works is non-trivial, means they’re not focusing on their users in that time (increasing your time to market)
- Non-trivial operational overhead of k8s clusters (reduces some with saas, e.g. upgrading the cluster)
6/x

Shout out to the serverless/faas pov: Dev teams shouldn't have to care where their work runs, they should be focusing on their users - with k8s they have to care about so much infra stuff

7/x

Use case no.2: Infra/DevOps/Ops team needs to host their org's dev teams software somewhere

8/x

Pros:
+ Great control plane for infrastructure
+ Can force a paradigm shift in thinking if coming from traditional on-prem infra worlds

9/x

Cons:
-K8s doesn’t tackle these really hard problems, it does offer a ton of configurability for you to go tackle them with
* Single Sign On
* Multi-tenancy/Resource Isolation (esp. security - go look at @jessfraz posts for that)
* Permission Management
* Config Management
10/x

More Cons:
- Having to rebuild/or create new platform functionalities, depending on your context:
* Build & Deploy
* Telemetry stack (metrics/logs/tracing/etc)
* Alerting
* DNS
* TLS
11/x

Which means it’ll take at least 1mill in engineer salary & a year to get close to a nice k8s platform for the dev teams & getting a team that is sufficiently skilled in that platform to deal with operational issues

Doesn’t this sound familiar (openstack i’m looking at you)

12/x

Use case no.3: You're a CTO/Tech Lead/Architect, you've got some legacy apps, but you're building some fancy new apps soon
13/x

Pros:
+ Everyone's doing it! Easier to find people who know it! Yay!
+ It's does the containers right? Awesome, we can just container the old stuff and then it can go on the k8s!
14/x

Cons:
- Migration takes time and resources, way more than you think if you want to avoid kicking cans down the road
- The learning curve is real.
15/x

More cons:
- The operational knowledge cost of k8s is significant, it's a big configurable complex beast (don't worry it will move to just being complicated as you learn it)
16/x

So where does this leave us?

Kubernetes isn't the panacea you think it is, stop thinking you need it specifically, go tackle your org's hard problems. Give your dev team less to think about, so they can think about the customers more
17/x

But if not k8s, then what?
18/x

Go look at the PaaS options (GAE/Beanstalk/AppService), and head down the serverless rabbit hole

Or go look at the FaaS options and make @swardley happier (AWS lambda is best atm, hopefully GCP functions catches up fast or it'll become a 1 horse race)

19/x