Live data from Hacker News

Do I Need Kubernetes?

mbird.biz

21–30 of 180 posts

Re: Do I Need Kubernetes?

#21
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.

Re: Do I Need Kubernetes?

#22
post #9
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?

Immutable infrastructure using Nix/NixOS.

Re: Do I Need Kubernetes?

#23
I work for a startup whose product is small (half a dozen servers, if relatively beefy ones) clusters that will be run on-prem by customers, at least sometimes in a low-to-no-touch capacity. Most of our application components are micro-ish services that are run on all hosts in the cluster for either extra capacity or fault tolerance.

We currently run everything on mesos/marathon, but are looking to switch away from it. K8s is kinda the “default” option, and is potentially appealing to some potential acquirers and investors.

But I never really see k8s being talked about in that context of “physical hardware that’s on prem, but not on MY prem.” Is there a reason for that? If we go with k8s is it going to bite us? Does anyone have experience with something like that they could share?

Re: Do I Need Kubernetes?

#24
post #3

I only have one tiny detail: Bursty traffic means that your cluster needs to be able to deal with the peaks. If you running an on prem Kubernetes cluster, then there is no savings, unless you can use the capacity for something else during non peak periods. The scaling, and potential savings is a cloud feature, not a feature of Kubernetes.

It also enables you to achieve app density. Many of the companies I've been working with lately have large batch processes on nightly / weekly / monthly basis. For some reason, each job previously was setup on on-prem hardware dedicated per workload. Using Kubernetes and scheduling jobs to manage capacity has enabled us to reduce the number of on-prem servers substantially as part of the migration plan for the cloud.

Re: Do I Need Kubernetes?

#25
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

> people were amazed by the productivity gains Yeah, docker compose is great for running distributed apps locally when everything “just works”. The problem is that it also impedes development when the compose setup isn’t fully optimized. I work on dockerized rails apps, and whenever a new dependency is added, it can take 15 minutes to rebuild the image, which completely breaks my flow. Docker also creates a ton of da…

At my current company, since I'm using gRPC, the build contexts for my containers are annoyingly large and I'm definitely feeling this. It's a massive pain and really annoys me but If I had to choose between 40 minutes of stressful debugging of someone else's config files vs 40 minutes of waiting for a command to finish, I'd take the latter.

Long term I'm planning on moving these builds to bazel and taking advantage of incremental builds for my entire monorepo. I'm in the final stages and just validating some stuff is in place before I do that. In the short term I've mitigated this by adding in heavy unit test coverage. Backend devs can basically run the unit tests for most services and are confident the service is working as expected and also enforces any/all security/auth checks. When developing I don't even start up the containers. I boot them up once at the end just to check my work.

Re: Do I Need Kubernetes?

#26
post #9
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?

[deleted]

Re: Do I Need Kubernetes?

#27
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.

Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset.

Re: Do I Need Kubernetes?

#28
post #9
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?

I use a git repo and pull in the changes to an ec2 instance. We also use git repos for our lambda functions.

Re: Do I Need Kubernetes?

#29
post #9

Earlier quoted context omitted.

Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?

I use a git repo and pull in the changes to an ec2 instance. We also use git repos for our lambda functions.

Also our lambda functions are managed by bash scripts we created to interact with aws cli.

Re: Do I Need Kubernetes?

#30

Earlier quoted context omitted.

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.

Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'…

Dont these issues also apply to the docker-compose alternative? I'm recommending make as "the one tool" to use for all of your teams apps. No matter what app they work on, everything is setup with `make bootstrap` and everything is run with `make up`. Everything is deployed with `make deploy`. They dont need to understand the _how_, only the _what_.
Post reply on HN