Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

271–280 of 319 posts

Re: You might not need Kubernetes

#271
post #133

Earlier quoted context omitted.

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

To me the biggest red flag there is the php. After developing with typed languages, a dynamic language is honestly a pain. Cron is easy to replace if needed. Like I would feel much better if it was python, golang, java or C#. Javascript I feel like is the new PHP. Another issue is what I call the COBOL syndrome, where your career future isn't as great. You can still be a shop with a relatively good career future tech…

PHP has had optionally typed function parameters and return values since the late 5.x releases I think (current release is 7.3). Types are checked at runtime and throw TypeErrors if the declared types are violated. They can also be checked ahead of time by IDEs with code inspection such as PhpStorm.

The 7.4 release is adding typed class properties as well[1].

I maintain a ~75k LOC PHP codebase (using the Laravel framework), and we have almost never encountered type issues. The new style of PHP (and Javascript is heading in a similar direction tbh) is to write it almost like it's Java, but with the option to fall back to dynamic "magic" as needed. If you utilize the dynamic elements sparingly, and following widely understood conventions, the productivity-vs.-reliability tradeoff is highly favorable for many applications compared to languages like Java and C#.

P.S. I like Python, but I would argue PHP actually has a better story to tell about types these days. "While Python 3.6 gives you this syntax for declaring types, there’s absolutely nothing in Python itself yet that does anything with these type declarations..." [2]. Declaring types in a dynamic language only to have them ignored at runtime does not inspire much confidence.

1. https://laravel-news.com/php7-typed-properties

2. https://medium.com/@ageitgey/learn-how-to-use-static-type-ch...

Re: You might not need Kubernetes

#272

Earlier quoted context omitted.

>Containers are a mechanism to run your old machine[s], but with a reproducible setup script. Well, exactly. There is not much to them, conceptually. So why does orchestration has to be so complicated? https://www.influxdata.com/blog/will-kubernetes-collapse-und... Also, serverless should be simpler. But it's not, like you said. That's my point. There is way too much accidental complexity bundled with these technolog…

Containers are conceptually simple. Products like Kubernetes, Docker, etc which need to be sold or have a for-profit motive, on the other hand, need to be complex so the supporting company can sell software and support contracts. The two purposes are directly opposed to each other.

> need to be complex so the supporting company can sell software and support contracts.

I think it's more likely due to the need to solve everybody in the world's use case. Yours is just a convenient (for some) side-effect.

Re: You might not need Kubernetes

#273
post #252
post #245

Earlier quoted context omitted.

I may have been sloppy to use the cloud infrastructure expression. It can mean different things to different people. Sure thing, you want to use at least VPS-s, from the very beginning. Maybe even blob storage as/if needed. But probably that's it at the beginning. > Put another way: in what way have you seen containers being abused? Well, I wouldn't say abused, but they aren't really necessary a lot of time. E.g. if…

> ... if we talk about a small company with a single product (which, the developers being sane, is a 'monolith' as opposed to being broken into microservices) then containerizing the thing really adds nothing. I totally agree with the monolith thing. Did that my self recently too. I don't agree about it not being helpful to containerise them, though. I've containerised a recent Go application I wrote. All it contains…

When you deploy new versions of your app, is there a short downtime between the moment you stop the old version and the moment you start the new one?

Re: You might not need Kubernetes

#274
post #172
post #160

Earlier quoted context omitted.

You can put everything in containers and still not need much orchestration, though. My personal projects run in dozens of containers, and the "orchestration" consists of a Makefile include pulled into each project that creates a systemd service file based on some variables, and pushes it into the right place. The service files will pull down and set up a suitable Docker container. The full setup for a couple of dozen…

> Of course it won't scale to massive projects Most projects aren't massive -- at work, 2 years on, we're still using a single instance of a single node, with the only component that needs to be reliable stored as static files in S3.

Absolutely. Which is one of the reasons I find things like Kubernetes overkill for most setups.

Re: You might not need Kubernetes

#275
post #160

Earlier quoted context omitted.

You can put everything in containers and still not need much orchestration, though. My personal projects run in dozens of containers, and the "orchestration" consists of a Makefile include pulled into each project that creates a systemd service file based on some variables, and pushes it into the right place. The service files will pull down and set up a suitable Docker container. The full setup for a couple of dozen…

When you deploy a new version of a container, how do you avoid downtime? Do you start a new container running the new version, wait for the new container to be ready, switch traffic to the new container, stop traffic to the old container and drain connections, and then stop the old container?

For my home projects it doesn't matter. For work projects, yes. It's an easy thing to automate. Incidentally most of the pain in this is that most load balancers are reverse of what makes most sense: the app servers ought to connect to the load balancer and tell it when it can service more requests, not get things pushed at it.

Re: You might not need Kubernetes

#276
post #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 ma…

As an experienced developer I’m finding it harder to find companies who use “boring”, simple and stable solutions. Any chance you’re hiring remotely?

Re: You might not need Kubernetes

#277
post #157

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…

Spot on, friend. So recently I started writing a simple web application for my family. They send emails to each other with gift wish lists in them and we all have to juggle those emails around. I figured some products would exist already to solve this problem, but I wanted to make my own. When it came time to make it I thought: "This has to be a REST API with a JS front end" and then further down the line, "Man I sho…

> so it went into a Docker container for the added security benefits

Which are? Last I heard containers (with baked-in dependencies) were generally considered very bad for security because the dependencies never get updated.

Re: You might not need Kubernetes

#278
post #159

What bothers me about k8s is that it promises a lot ("15 years of experience of running production workloads at Google" at your fingertips! yay!) but it's in fact still a young, ever-changing solution. Even developing an app locally with minikube is a PITA for a lot of reasons. From Helm to Telepresence to Skaffold, every tool out there is just unpolished and overambitious. Don't want to imagine how those problems mi…

Skaffold is only 5 months old. That's a little unfair to call it unpolished an over-ambitious.

It's made by Google which boasts about its 15y experience on containers?

Re: You might not need Kubernetes

#279

Earlier quoted context omitted.

My friend is trying his luck with his own start up, they have yet to launch a 1.0 of product but the CTO implemented K8s citing scalability. I legit laughed at that statement.

My friend has a startup and a single person got a k8s cluster running on aws with kops+GPUs in a couple weeks. He loves it. The people who are running it successfully don't come on here to complain.

> a single person got a k8s cluster running on aws with kops+GPUs in a couple weeks

In the context of your GP's comment:

1. How long would it have taken that one person (or the startup) to get started with AWS+GPUs without k8s?

2. How much effort would it take that person to debug an issue with if/when one springs up?

3. What happens when the single person goes on leave?

Re: You might not need Kubernetes

#280
post #133

Earlier quoted context omitted.

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

> Candidates see our stack as boring and bland I would say that there are probably a lot of developers who would be very happy to work on a non-buzzword stack, but the problem is that as a developer, it's extremely hard to know if your tech stack is the result of directed efforts to keep it simple, or if it's the haphazard result of some guy setting it up ten years ago when these technologies were hot.

I would be happy to work on a stack like that, but I can't deny that it seems somewhat career limiting long term.Especially as I am over 40 now. I will be seen as not keeping up to date.

(I certainly think I design and build better software than most people having done a few years of maintenance programming recently, people just create over complex monstrosities for what should be simple apps)

Post reply on HN