Live data from Hacker News

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

blog.coinbase.com

241–250 of 414 posts

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

#241
post #163

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…

Thank you. I use most of this, I've been using it for years and I just don't talk about it because it's hard to argue when people just want to force an idea that k8s is "really the best way of doing things".

Also, haproxy is one of the most reliable software I've ever used.

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

#242

Earlier quoted context omitted.

For those missing Heroku: there exists Dokku [1], a small Heroku-like implementation for container management. It uses the same underlying buildpacks and you get the same comfort as with Heroku. And it's free to use. You can't deploy to multiple host machines though. But for small projects that fit on a single host, it's very nice to use. [1] http://dokku.viewdocs.io/dokku/

Tried Dokku, but found CapRover [1] to be a much better / easier option [1] https://caprover.com/

Looks great! considering migrating from dokku. I also came across exoframe recently which looks lower level but works with your existing docker projects https://github.com/exoframejs/exoframe

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

#243
post #72

Earlier quoted context omitted.

Firstly tell me more about your 1-person full-stack venture, but second how comes you, with barely any time for sitting down can use k8s happily but it falls over for others. I am struggling to see truth amount the comments here :-(

Not the GP, but I honestly couldn't tell you. A lot probably comes down to tooling, the applications you are deploying, security requirements, etc., as well as how familiar you are with k8s itself. I migrated PCGamingWiki from running on some Hetzner boxes to DigitalOcean Kubernetes in a few days of work creating Dockerfiles and k8s manifests. I run a Kubernetes cluster at work fairly hands-free that hosts applicatio…

I can totally agree with this. Most of my customers that I see struggling with K8s are those that haven't internalized 12-factor principles: not just heard, read or understood, but really internalized. It is unfortunate that K8s talks / blob posts / articles do not focus enough on this pre-requisite.

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

#244
post #239

Earlier quoted context omitted.

if you can run everything on a $10 vm...do you really need k8 ?

most people probably want the following: - no downtime deployments - distributed jobs - as managed infra as possible without k8s some things would be hard.

no downtime deployments? happened before k8s; used to do that several times with some haproxy.

distributed jobs? same; nothing prevents from spawning runners with adhoc libraries and queues.

managed infra? not specific to k8s

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

#245
post #182

Earlier quoted context omitted.

I feel like I’m witnessing two co-founding colleagues - who sit by each other day in and day out - discover the other’s persona on HackerNews. Sure, maybe you two (@dvcrn and @arcticfox) don’t work together and don’t know each other, but it’s definitely more entertaining imagining the scenario above.

“If you like pina coladas...”

https://en.wikipedia.org/wiki/Escape_(The_Piña_Colada_Song)

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

#246

I work for a mid size company with 30-40 engineers managing 20-30 very diverse apps in terms of scale requirements and architectural complexity. It took our devops team (4-5 people) probably 18 months to learn and fully migrate all our apps to Kubernetes. The upfront cost was massive, but nowadays the app teams own their deployments, configurations, SLA's, monitors, and cost metrics. Introducing Kubernetes into our o…

Do you have any intuition as to what percentage of the benefits your company has seen come from kubernetes specifically, and how much just from the exercise of spending 18 months working on a modern, coherent, efficient infrastructure?

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

#247
Pinnacle of devops effort to deliver apps before Kubernetes was AWS Beanstalk, which their setup replicates in great detail.

I'd take k8s over Beanstalk any time.

Kubernetes is not about scale, it is about defining primitives, everybody can use to describe their setup. It is a DSL everyone converges to and as a result of this unification products from different vendors can be packaged and deployed in the uniform way.

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

#248
post #239

Earlier quoted context omitted.

most people probably want the following: - no downtime deployments - distributed jobs - as managed infra as possible without k8s some things would be hard.

no downtime deployments? happened before k8s; used to do that several times with some haproxy. distributed jobs? same; nothing prevents from spawning runners with adhoc libraries and queues. managed infra? not specific to k8s

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 standard?

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

#249
I'm a big fan of this - to me containers is another hype train like cloud and serverless. There absolutely are good use-cases (we run a number of K8s clusters with great success at work) but it's absolutely not the solution to all (app deployment) problems. As said in the article, I think complex systems like K8s can often have a detrimental effect on productivity. KISS.

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

#250

It puzzles me a bit that they don't want to invest on.k8s expertise (at their scale, especially security-wise can be though, I guess) but at the same time they develop their own deploy system which sounds a lot like Spinnaker and they have their own secrets/config management system (Hashicorp's stack is pretty neat and battle tested).

Coinbase hasn't scaled very well IMO, probably because of people like this. Once you try out Kraken it is like night and day difference in terms of features and supported currencies.

Kraken had so many issues at the beginning.

Trading during high-volume hours was next to impossible: orders were not getting filled (sometimes they didn't even reach the order book!), the UI wasn't loading, etc.

Then they shut down for a while and rebuilt everything starting from the matching engine. I guess they also reworked their architecture because after that, it was smooth sailing ever since.

Post reply on HN