Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

121–130 of 319 posts

Re: You might not need Kubernetes

#121
post #11

"Anyways, the point I am trying to make is you should use whatever is the easiest thing for your use case and not just what is popular on the internet. " This is good advice in theory but in the real employment world you are killing your own career that way. At some point you get marked as "dinosaur" that hasn't "kept up". Much better to jump on the latest tech trend.

I get the sentiment here, but I don't think it's strictly true. The way I look at new technology is that I need to know enough about it to either discount it, or choose to use it. So long as I know what I'm talking about when I tell a prospective employer that I advise not using technology X, then they typically understand that I have the knowledge to make that decision. So your advise should be, learn about the late…

" try it out,"

How much time do most of us to really "try out" something deeply enough to have an informed opinion?

Re: You might not need Kubernetes

#122
post #18

Earlier quoted context omitted.

I haven't used it myself, but https://flynn.io/ seems to be targeted at that use case.

Last release was in 2017. I don't think flynn is still alive which is a shame.

https://github.com/flynn/flynn/commits/master

not at all in the loop here..

but release != alive; alive != new code, etc etc etc

Re: You might not need Kubernetes

#123

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

They do not, I run tens of low-traffic projects very successfully on a $10/mo Hetzner server on Dokku. Dokku is amazing and so is Hetzner, I don't know why people always go for the high-scalability, expensive options just to end up with 0 utilization.

Re: You might not need Kubernetes

#124

Earlier quoted context omitted.

How old are you?

Almost 40, 20+ years of tech experience.

Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech?

Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that.

What worked 5 years ago is a joke today, in many cases.

Re: You might not need Kubernetes

#125

Earlier quoted context omitted.

4-8 dedicate staff members to run k8s? seriously, How did you come up with that number? 1) You can run k8s hosted on Google, DigitalOcean with zero effort. 2) I built a k8s cluster in 3 days with zero experience after spending a week playing with minikube, reading the docs are kuberentes.io

> I built a k8s cluster in 3 days with zero experience after spending a week playing with minikube, reading the docs are kuberentes.io I'm pretty sure I can do it in an afternoon from scripts on github. But if something goes wrong all bets are off. Just getting something setup is not building a competence around it.

How well would you, with zero experience managing and deploying a stack, do the same in an orthodox LAMP setting?

Re: You might not need Kubernetes

#126
post #65
post #43

Earlier quoted context omitted.

I don't know. I've always found having an actual, functional product to be more impressive than a list of buzzwords on your resume. And most of the buzzword-driven development doesn't usually lead to a functioning system.

If you're buzzword compliant, you can fail forward. Your last product may not have worked out, but you've become an expert in Docker, Kubernetes, AWS, OpenShift, and Terraform which means that companies who are committed to the cloud (i.e., everybody) won't pass you over. Built an app that works before the cloud hype hit? Congratulations. You're a specialist in legacy technologies. We'll call you if we have a COBOL o…

I believe that is called Resume Driven Development. I see it in my org quite a bit. There are pros and cons. One of the cons is the academic exercises that have no bearing on customer requirements and last far too long. Mgmt won't kill these projects off for fear of losing good talent, so we end up with loads of shiny things that nobody wants to support and nobody will admit that we don't need.

Re: You might not need Kubernetes

#127

Earlier quoted context omitted.

Almost 40, 20+ years of tech experience.

Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.

Not concerned at all. I get paid to de-risk, not to ride the hype train.

> What worked 5 years ago is a joke today, in many cases.

Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.

Re: You might not need Kubernetes

#128
Sometimes choice of technology acts as a signifier. If you're building a startup, and you want to communicate to investors that "hey, we may not have the users yet, but we're built to scale!", Kubernetes and microservice architectures and sophisticated ETL pipelines convey that image better than saying "we've built for the minimal load that we're currently experiencing with a LAMP-based monolith.". The reality may be that your product's consumption patterns will never necessitate having anything more than that, even at a large scale. Your product may be great, you might easily be able to scale manually, but someone who holds the purse strings who knows just enough to be dangerous, might decide that if you're not using the "hot" technologies, you must not know what you're doing.

Re: You might not need Kubernetes

#129

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

I think you're right - at least 90% of servers on the web would be fine with a couple of instances at most backed by a decent db. It can get more compex depending on your resiliance requirements but it really doesn't have to be.

I guess I run a CPG stack - Coreos, Postgresql, Go. Don't bother with containers as Go produces one binary which can be run under systemd. It is far simpler than kubernetes and the only real reason for other servers is redundancy. The only bit of complexity is I usually run the db servers as a separate instance or use a managed service. You can go a long way with very boring tech. I've run a little HN clone written in go on one $5 digital ocean droplet for years - it handles moderate traffic spikes with little effort.

Re: You might not need Kubernetes

#130

Earlier quoted context omitted.

Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.

Not concerned at all. I get paid to de-risk, not to ride the hype train. > What worked 5 years ago is a joke today, in many cases. Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.

Refusing to adopt innovation because it doesn't match with what you knew when you were a technical contributor is risky, too.

Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky.

What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.

Post reply on HN