,
5 tweets,
2 min read
Read on Twitter
Some thoughts on Tinder’s 2 year effort to move to Kubernetes - medium.com/@tinder.engine…
Engineers - most of us - are often terrible at evaluating the opportunity cost of the engineering efforts and the concomitant work it’d take to prop up this infrastructure in the long term.
Engineers - most of us - are often terrible at evaluating the opportunity cost of the engineering efforts and the concomitant work it’d take to prop up this infrastructure in the long term.
EC2 startup times alone isn’t very convincing to justify a 2 year effort to make this move.
As for the cost savings - see my point about the opportunity cost here.
Third, you probably don’t need Kubernetes and the attendant complexity to get to “infrastructure as code” ideal
As for the cost savings - see my point about the opportunity cost here.
Third, you probably don’t need Kubernetes and the attendant complexity to get to “infrastructure as code” ideal
there exist compute paradigms today that are more lightweight than even containers - FaaS, FaaS on edge etc.
In about 2 years, it’s possible that these paradigms might’ve matured enough to support running important parts of one’s workloads on them.
In about 2 years, it’s possible that these paradigms might’ve matured enough to support running important parts of one’s workloads on them.
Given this, at this point embarking on a multi year effort to move to Kubernetes a workload that is currently running on thousands of VMs (that’s not *that* many to wheel out the justification of “scale”) seems ... not exactly “forward looking”, as it were.
Not saying Kubernetes on the whole is bad. It’s definitely a nice abstraction and is a perfectly valid use case for many organizations. :)
But somehow, citing “we now have a very strong infrastructure team” as one of the “wins” of moving to k8s doesn’t seem one of them.
But somehow, citing “we now have a very strong infrastructure team” as one of the “wins” of moving to k8s doesn’t seem one of them.
