Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

131–140 of 319 posts

Re: You might not need Kubernetes

#131

Earlier quoted context omitted.

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 ca…

I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers.

If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.

Re: You might not need Kubernetes

#132
post #87

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…

"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."

For my home servers, I've settled on "a default install of distro $X and an idempotent shell script that sets everything up for me". You have to use discipline to do everything in the shell script rather than simply fix the problem, but if you can do that, you end up with documentation as to how your server differs from a default install, and the ability to recover it again reasonably well if you store it in git somewhere or something.

It's only "reasonably" well because when you have one server running for years at a time, your script decays more quickly than you are going to fix it. If your server goes down three years later, and you decide to go with the latest $X instead of whatever you used last time, then your script will be out of date and need to be updated. It isn't nirvana. But it's the best bang for the buck when you're in a situation where chef/ansible/puppet/etc. is massive, massive overkill.

If you're already an expert with Docker, go nuts, but IMHO it's a bit silly to run a server just to run two Docker containers, just so you can say you're running Docker or something. Plus no matter how slick Docker has gotten, it's still more of a pain that just setting a few things up.

Re: You might not need Kubernetes

#133

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 someone who runs a very successful data business on a simple stack (php, cron, redis, mariadb), I definitely agree. We've avoided the latest trends/tools and just keep humming along while outperforming and outdelivering our competitors.

We're also revenue-funded so no outside VC pushing us to be flashy, but I will definitely admit it makes hiring difficult. Candidates see our stack as boring and bland, which we make up for that in comp, but for a lot of people that's not enough.

If you want to run a reliable, simple, and profitable business, keep your tech stack equally simple. If you want to appeal to VCs and have an easy time recruiting, you need to be cargo cult, even if it's not technically necessary.

Re: You might not need Kubernetes

#134

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…

You probably don't need kubernetes.

Lets be fair, it offers:-

> Orchestration of block storage

> Resource Management

> Rolling Deploys

> Cloud provider agnostic APIs*

If you don't need any of these things, and your stack fits on a single server or two, and you aren't already familiar with it, I'm not sure why you bother other than an interest.

That said, there's a world of companies that aren't FAANG, ub3r and Basecamp, and many of those paying reasonble sums of money have more complicated and resource intensive requirements that don't fit on a single server.

Government Departments, Retail Companies and Banks all likely have a number of different software development projects where giving a number of developers API access to a platform that offers the above advatanges is, in my opinion, a good thing. Once you get to FAANG level, who knows whether kube itself will actually help or hinder at that level.

* Personally I'd rather use the kube APIs than talking to any of the cloud providers directly. I imagine that's somewhat personal preference and somewhat because I've been able to easily run it in my basement.

*2 Namespaces also makes making more environments for CI/CD easier, so as soon as you have a team of developers and you want to do that sort of thing, it also makes sense. Not so much for a loan developer and his server.

Re: You might not need Kubernetes

#135
post #98

Earlier quoted context omitted.

I really think that running a LAMP server for the average beginning developer these days would be just as complicated, maybe more complicated, than running a single deployment on Google Kubernetes Engine. You have to know about package managers and init systems and apache/nginx config files and keep track of security updates for your stack and rotate the logs so the hard drive doesn't fill up. If you already know how…

>I really think that running a LAMP server for the average beginning developer these days would be just as complicated, maybe more complicated, than running a single deployment on Google Kubernetes Engine. Back when I first started doing web dev I went from knowing nothing about server setups or Unix (i.e. running off managed hosting) to a reasonably secure FreeBSD server with a working content management system in 3…

Containers are a mechanism to run your old machine[s], but with a reproducible setup script. A machine packed in a container happens to also run on your dev/CI environments. There isn't much logical difference between a physical machine, a VM and a container [0].

Serverless offers a large surface of APIs, some of them proprietary, tangled in an ever evolving dependency hell.

Historical note: Google Cloud started serverless with AppEngine, then focused on GCE [and later GKE] _because_ serverless was hard and AWS was eating their launch with VMs.

[0] For example, we can argue about security isolation issues in containers vs VMs. Eventually this will become a moot point as technology advances far enough that we can run each container inside a hardware-backed VM.

Re: You might not need Kubernetes

#136

Earlier quoted context omitted.

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 ca…

I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubern…

The only misunderstanding that's taking place here is how unproven you think the tech being discussed is.

No one is suggesting you spend sleepless nights troubleshooting beta software in production.

K8s is not beta software, and the fact that you have to misrepresent my position as such is a pretty good indicator that you don't find my actual position (use solid software even if it's new, as long as it's solid, which k8s is) to be objectionable. I wish you'd start there...

Re: You might not need Kubernetes

#137

Earlier quoted context omitted.

I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubern…

The only misunderstanding that's taking place here is how unproven you think the tech being discussed is. No one is suggesting you spend sleepless nights troubleshooting beta software in production. K8s is not beta software, and the fact that you have to misrepresent my position as such is a pretty good indicator that you don't find my actual position (use solid software even if it's new, as long as it's solid, which…

We disagree k8s is solid, so no further discussion is necessary.

You questioned the maturity of an IRC client that was only 3 years old [1]. But that's enough time for Kubernetes to be a mature orchestration framework, to be relied upon as critical infrastructure? Yes, more development resources have been committed to Kubernetes, but that does not make it solid.

[1] https://news.ycombinator.com/item?id=18408813

Re: You might not need Kubernetes

#138

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 manage dozens of apps for thousands of users. The apps are all on one server, its load average around 0.1.

If you're at this scale you can do whatever you want. Most of the stuff I've made has been with simple building blocks like you've described, maybe thrown in with some caches and a load balancer.

Although I've worked with other teams who really did have the high scale request flows that require you think about using a different architecture. Even so, K8s is not the end game and you can make something work even just extending the LAMP stack.

Re: You might not need Kubernetes

#139

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 that kub and, generally, cloud providers have allowed for more ambitious projects to be generally accessible.

My side project is intended to handle > 1 billion events per day, with fairly low latency. That's well over 10k events per second.

I doubt I could do this easily on a single box, and I wouldn't really want to try. Why constrain myself that way? Is it worth just doing this the standard LAMP way?

More and more problems are available to be solved using commodity systems, so we have more and more people solving those problems with these new systems.

Re: You might not need Kubernetes

#140
post #107

Earlier quoted context omitted.

One application server, yes. HN is fronted by Cloudflare for CDN + DDoS protection, which of course is a lot more than one server. That's why if you get a particularly long thread (1k+ comments), admins will beg people to log out so that the responses can be served from the CDN cache. Example: American 2016 presidential election https://news.ycombinator.com/item?id=12909752 (1,700 comments)

HN hasn't been fronted by Cloudflare since July.

Hm, interesting. I noticed HN started responding to HEAD requests with 405s recently; perhaps that is the cause.
Post reply on HN