Container technologies at Coinbase: Why Kubernetes is not part of our stack

Post by temptemptemp111 » Tue, Jun 09, 2020, 9:11 AM UTC

imtringued wrote: post #252

threeseed wrote: post #90

Earlier quoted context omitted.

I don't understand this comment at all. Kubernetes is designed for a cluster of nodes not a single one. Of course a single VPS is lower cost and easier to use but what happens if you want a second or third. Or any form of redundancy.

You just run scp with the compose file and run docker compose down; docker compose up Bonus points if you just mount the compose file on an NFS share. I've wasted enough man months on kubernetes that unless you tell me to manage 1000 nodes this approach will never cost me more time than the time I spent using and learning kubernetes.

Post by lazzlazzlazz » Tue, Jun 09, 2020, 9:12 AM UTC

jen20 wrote: post #163

flowerlad wrote: post #100

Earlier quoted context omitted.

> Plain old linux is the alternative How do you run an application on a cluster of plain old linux machines? How do you do load balancing? How do you scale up and down? How do you update your app without downtime? How do you roll back easily if something goes wrong? How do you ensure all your servers are running the same version of dependencies? How do you update those dependencies? How do you replicate your environm…

These are commonly raised concerns, all of which have answers much simpler than "install this giant distributed system". I'll go ahead and answer them since I take the questions to be in good faith... > How do you run an application on a cluster of plain old linux machines? Build a package, install it in an image, run that image in an autoscaling group (or whatever equivalent your cloud of choice offers). > How do yo…

Post by lazzlazzlazz » Tue, Jun 09, 2020, 9:16 AM UTC

flowerlad wrote: post #100

zaptheimpaler wrote: post #75

Earlier quoted context omitted.

Plain old linux is the alternative, which is also "learn once, use everywhere" whether its AWS EC2 or GCP Instances or nearly any machine under the sun. I don't see how k8s avoids the need to learn about cloud vendor specific tech. e.g searching "aws RDS k8s" gives me a beta github packages and a bunch of blog posts on how to configure it right. It doesn't sound like much less work than learning how to use RDS withou…

> Plain old linux is the alternative How do you run an application on a cluster of plain old linux machines? How do you do load balancing? How do you scale up and down? How do you update your app without downtime? How do you roll back easily if something goes wrong? How do you ensure all your servers are running the same version of dependencies? How do you update those dependencies? How do you replicate your environm…

Post by jillesvangurp » Tue, Jun 09, 2020, 9:23 AM UTC

santamarias wrote: post #218

jillesvangurp wrote: post #210

Earlier quoted context omitted.

It's a pity that docker swarm did not make it. It wasn't perfect but it was a lot simpler to setup and manage than kubernetes. If you can get away with it, vanilla docker hosts running docker compose provide most of the same benefits with a fraction of the cost. For most startups, that's a great way to avoid getting sucked into a black hole of non value adding devops activity. You lose some flexibility but vanilla ub…

> It's a pity that docker swarm did not make it. Sorry I do not understand that statement, in my naive opinion Docker Swarm seems to be a thing. Care to elaborate, please?

Post by cameronbrown » Tue, Jun 09, 2020, 9:32 AM UTC

spottybanana wrote: post #284

manigandham wrote: post #248

Earlier quoted context omitted.

The "adhoc" part is the problem. K8S is standardized and offers high-availability, failover, logging, monitoring, load balancing, networking, service discovery, deployments, stateful services, storage volumes, batch jobs, etc. And it can run self-contained on a single machine or scale out to 1000 nodes. Why piece all of that functionality together yourself into some fragile framework instead of using a industry stand…

"Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?" Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. I personally would use the word "industry standard" a little bit differently.