Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

Post reply on HN
Print view View original

81–90 of 319 posts

Re: You might not need Kubernetes

#81

Post by kayoone »

citilife wrote: post #56
combatentropy wrote: post #19

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…

For reference, this runs on a $5 AWS instance: https://hnprofile.com/ The database is $600 per month, but that data runs five different websites (and it's a few hundred Gb of data). EDIT: for those mentioning the 502 gateway error, it does auto scales - Now it's costing more per month, at least temporarily.

$5 AWS instance ? aren't they all substantially more than that ?

Re: You might not need Kubernetes

#82

Post by metalrain »

You most likely need few cheap servers, a loadbalancer and great team. So yeah no Kubernetes, no microservices nor chaos monkey. What you need is to know, really deeply know your technology stack. This is where boring software helps.

Re: You might not need Kubernetes

#83

Post by vesak »

tshannon wrote: post #31
combatentropy wrote: post #19

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…

Does hacker news really run on one server? What if server goes down? I've always though high availability was the more important reason for multiple servers, rather than performance. Even if you have only two paying customers, they are probably paying for the right to hit your website / service 24/7.

Well, there's another important question: What percentage of all services need high availability? Stetson-Harrison method shows that it's less than 5%.

Re: You might not need Kubernetes

#84

Post by cat199 »

segmondy wrote: post #37
djsumdog wrote: post #28

Earlier quoted context omitted.

I once got an interview from a company in the container space because one of their exec read an article I published talking about the trouble with container systems[1]. (Really good talk/interview, but I ended up not moving forward because I didn't want to move back to the west coast). I've been in smaller shops that wasted a lot of time on K8s stuff and fell behind on their timeline. If you want to run k8s, DC/OS, e…

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

built != run.

not sure if I agree with OP on precise figures, but, if you're dealing with:

- actually federated k8 infrastructure (distributed etcd, etc)

- enough system load that k8 is actually worthwhile and not 'cool'

- user / dev requests

- whatever background IT projects are going on (updates / new nodes, existing upgrades, testing new configs, etc)

and you want:

- 24x7 operations (or even stringent 8x5)

- people to be able to use the restroom and take vacations and still have 1-2 sets of hands available

1 person doesn't quite cut it, because (s)he will quit eventually, and you will have nooone.

dev-centric mentalities of 'it compiled, ship it, i made a new futuristic fancy feature aren't i amazeballs' often don't take into account real operational concerns, which i think is precisely the point in critiquing k8s here

Re: You might not need Kubernetes

#87

Post by wpietri »

combatentropy wrote: post #19

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…

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine.

On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead of investing in learning old-school techniques.

The problem for me with the old big-server-many-apps approach is the way it becomes hard to manage. 5 years on, I know that I did a bunch of things for a bunch of reasons, but I don't really remember what or why. It mixes intention with execution in a way that gets muddled over time. Moving to a new server or OS is more archaeology than engineering.

The rise of virtual servers and tools like Chef and Puppet provided some ways to manage that complexity. But "virtual server" is like "horseless carriage". The term itself indicates that some transition is happening, but that we don't really understand it yet.

I believe containers are at least the next step in that direction. Done well, I think containers are a much cleaner way of separating intent from implementation than older approaches. Something like Kubernetes strongly encourages patterns that make scaling easier, sure. But even if the scaling never happens, it makes people better prepared for operational issues that certainly will happen. Migrations, upgrades, hardware failures, transfers of control.

Re: You might not need Kubernetes

#88

Post by [deleted] »

tshannon wrote: post #31
combatentropy wrote: post #19

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…

Does hacker news really run on one server? What if server goes down? I've always though high availability was the more important reason for multiple servers, rather than performance. Even if you have only two paying customers, they are probably paying for the right to hit your website / service 24/7.

[deleted]

Re: You might not need Kubernetes

#89

Post by Sahbak »

I honestly don't understand the amount of negativity towards dockers and kubernetes sometimes.

All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill).

Afterwards, deploying, testing, reproducing things is, in my opinion, much better than managing your applications on random servers.

Might I be wasting some money on a k8 cluster? Maybe. Do I believe the benefits outweigh the money? Absolutely.

Re: You might not need Kubernetes

#90

Post by hinkley »

amq wrote: post #14
coreyja wrote: post #10

Earlier quoted context omitted.

I am in the exact same boat as you are, and would love some feedback as well! I have been considering Kubernetes so that I can allow horizontal scaling, but haven't done it yet. For my use case I am VERY well aware that Kubernetes is overkill, but I don't see a great middle ground between Dokku where I am now, and Kubernetes.

I have found Docker Swarm Mode to be a good middle ground. Essentially, it's docker-compose which you can run on multiple servers.

I've started experimenting with Swarm myself but I know one guy who has a histamine reaction every time I mention it. I haven't gotten (or really tried to get) a straight answer out of him about why it's a bad thing.

If you have a countable number of instances of a couple dozen services and one or two "lots of instances" services it seems like it should suffice just fine. And really, my brief sojourn into Kubernetes left me feeling like I bumped into road blocks for anything more complicated than that. Especially with sidecars, or if your tool chain uses multiprocessing instead of threading (Rails, Node, Python?, etc) to deal with concurrency.

Post reply on HN