Live data from Hacker News

Kubernetes is a red flag signalling premature optimisation

jeremybrown.tech

111–120 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#111

Guys Kubernetes is a container platform for multiple nodes. I know it seems hard to understand from the outside, but its really not. You would naturally come up with ALL the same componets if you were to take your container strategy onto multiple computers. What if you dont need multiple servers? Well go the single node approach and have a flexible, true and tested way to spin up containers, which can and should be a…

> Using Containers is pre mature optimization too? maybe I should get my typewriter

More like grab a damn pen and scrawl out what you actually need. It's flexible and fast, which in many cases suits the situation best.

Re: Kubernetes is a red flag signalling premature optimisation

#112
post #80

Earlier quoted context omitted.

This is a common misconception. k8s isn't about scale, multi-node or even reliability/resiliency. We had solutions for all of that before it came along. It's about having a standard API for deployment artifacts. The k8s manifests are trivial (if verbose) the complexity comes from running the underlying layer which when you are small you simply outsource to AWS or GCP. There is some k8s know-how that is table stakes f…

> Overall it's a lot less required knowledge than it takes to manipulate lower level primitives like GCP/AWS directly or be capable of setting up standalone boxes. I do not agree with this. I have tried to start Kubernetes and it's far more confusing to set up than just setting up something on a standalone box, mainly because it looks like the set of knowledge I need to set up anything on Kubernetes is a superset of…

It's really not unless you are doing a half-assed job of setting up bare boxes.

Lets see to get something even half-reasonable on a bare box you need the minimum:

process monitor: For this you can use systemd, supervisord, etc.

logging: rsyslog or similar.

http reverse proxy: nginx or haproxy

deployment mechansim: probably scp if you are going this ghetto but git pull + build and/or pull from s3 are all common at this level plus a bunch of bash to properly restart things.

backups: depends on persistence, litestream for sqllite these days, pgdump/whatever for RDBMS, wal shipping if you are running the DB on your own boxes.

access control: some mechanism to manage either multiple users + homes or shared user account with shared authorized_keys.

security: lock down sshd, reverse proxy, etc. stay on top of patching.

So are bare minimum there is a ton of concepts you need to know, you are essentially regressing back into the days of hardcore sysadmins... just without all the hardcore sysadmins to do the job correctly (because they are now all busy running k8s setups).

Meanwhile to deploy a similarly simply app to k8s (assuming you are buying managed k8s) you need to know the following things:

container + registry: i.e Dockerfile + docker build + docker push gcr.io/mything.

deployment: Describes how to run your docker image, what args, how much resources, does it need volumes, etc. You can go ghetto and not use service accounts/workload-identity and still be in better shape than bare boxes.

service: how your service exposes itself, ports etc.

ingress: how to route traffic from internet into your service, usually HTTP host, paths etc.

Generally this is equivalent but with way less moving parts.

There is no ssh server, patching is now mostly just a matter of pressing the upgrade button your provider gives you. You now only need to know docker, kubectl and some yaml instead of systemd control files, sshd_config, nginx.conf, bash, rsync/tarsnap/etc.

K8s reputation as being hard to run is deserved.

K8s reputation as being hard to use is grossly undeserved.

Re: Kubernetes is a red flag signalling premature optimisation

#113

At this point I'm pretty much convinced these repeated "Kubernetes is bad for startups" rants are some kind of FUD campaign (probably grass roots from people who've missed the containerisation and declarative infra train). Kubernetes is actually pretty great for the vast majority of use-cases. Sure if you don't have experience with kubernetes leave learning it until after you've hit product-market fit. But rejecting…

"Containerization and declarative infra" are only a small fraction of what could be done with real network distributed OS's as early as the 1980s and 1990s, and with far lower levels of overall complexity. That "train" has left the station a long time ago, it's going full speed and there are no brakes on it either. Of course you can keep chugging along with clunky K8s and call that a "good default choice". But that's…

So where is this real progress happening today?

I will say I think what the fly.io guys are doing with VMs on the edge and in-process distributed databases is pretty exciting.

Re: Kubernetes is a red flag signalling premature optimisation

#114
post #46

Earlier quoted context omitted.

How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?

You can't really tell for a Web App whether it'll be faster in JS or Python, but you can definitely expect a Computer Vision application with lots of heavy number crunching to be a lot faster in C++ than in Python. We have actually also made comparisons, and even if you use things like numpy and Python bindings for OpenCV, you won't reach the speed that a C++ application achieves easily without optimization.

That depends a lot on what that CV application does and what hardware it runs on. Naive C++ (that runs on CPU) is usually much slower than using Python as glue for libraries that run on GPU.

Re: Kubernetes is a red flag signalling premature optimisation

#115
post #6

[OP here] It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product. Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your co…

Doesn't it depend what staff you have? I would have agreed with this in 2018 but the world has moved on. If you have a bunch of people who know it, you can deploy a cluster into gcloud or aws with a few clicks or lines of IaC. Would I recommend a startup team learn kube while trying to ship a product? No. Would I think it's a red flag if a team who already know it choose it as their preferred platform? Also no.

What about maintenance of that cluster (of possibly only 1 machine) though?

Re: Kubernetes is a red flag signalling premature optimisation

#116
post #80

Earlier quoted context omitted.

This is a common misconception. k8s isn't about scale, multi-node or even reliability/resiliency. We had solutions for all of that before it came along. It's about having a standard API for deployment artifacts. The k8s manifests are trivial (if verbose) the complexity comes from running the underlying layer which when you are small you simply outsource to AWS or GCP. There is some k8s know-how that is table stakes f…

It would be great if otherwise smart people Also learn to know when what’s trivial to them is not trivial to the masses. K8s is not trivial, not to me at the least. I’m not some super duper engineer but I do alright? That’s all I can say at the least.

Have you made a good faith attempt to use k8s? Or are you just regurgitating how hard it is to use based on what you hear on the Internet?

My experience is even mediocre engineers are capable of understanding k8s concepts with minimal assistance assuming things are either sufficiently standard (i.e google-able) or well documented with any company specific practices.

K8s == hard to run, k8s != hard to use.

Re: Kubernetes is a red flag signalling premature optimisation

#117
post #44

It depends how experienced you are with it. If your team has no experience with it, don't do it. I'm pretty experienced, having set up a bunch of infras, so I'd run a blog on it now

Indeed - having used it for few years, I'd start the initial infra (for testing/playground/whatever) as small k8s on a local VM or similar solution so that we could prototype against the target abstractions from day one. Much, much less work to then move the deployments elsewhere, including building and teardown of integration testing environments.

When I get a contract to move a startups infra to k8s the majority of the work is actually untangling the services and making them accept configuration and communication in a sane way, the actual yamls are easy. Starting with k8s actually enforces some structure and standards and makes for a much more friendly environment to work in, usually you can run the whole infra on your laptop

Re: Kubernetes is a red flag signalling premature optimisation

#118
post #27
post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spen…

That makes sense assuming you have already written your backend in JS. In that case, yeah the bar for rewriting in another language should be high (as it should be for any ground-up rewrite). But it's not a "premature optimization" when you are deciding on the tech stack to begin with.

Re: Kubernetes is a red flag signalling premature optimisation

#119
Man these opinion pieces get boring fast and very rarely add value.

I honestly couldn't give a toss if some guy thinks using some is , it's a technology, a tool, try it, use it, if it works for you good, if not use something else. Move on.

The only time it's a allowed is if it's bashing JIRA :)

Re: Kubernetes is a red flag signalling premature optimisation

#120

Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…

> I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too.

Taking human resource information into consideration sounds very wise. Although, learning a new language is generally not that a huge barrier, while changing your whole stack once the minimum viable product cap is passed can be very expensive. And if you need to scale the team, the available developer pool is not the same depending on which technology you have to stick with.

It doesn’t invalidate your point, but maybe it brings some relevant nuances.

Post reply on HN