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

291–300 of 319 posts

Re: You might not need Kubernetes

#291

Post by _drFaust »

lostapathy wrote: post #36
tshannon wrote: post #31

Earlier quoted context omitted.

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.

What if hacker news goes down, more work gets done for the day? It’s really common to over estimate the cost of being down, while underestimating the costs of resiliency. And in the end if you can’t fully afford the resiliency, you end up with a system that’s more complicated and thus less stable than it could have been had you just accepted a tiny bit of risk.

extremely valid point. The initial setup isn't the challenge, it's the endless tweaks to make it fault tolerant. For anyone looking into k8s, take time to research best practices for monitoring and readiness probes.

Re: You might not need Kubernetes

#292

Post by _drFaust »

movedx wrote: post #212
loftyal wrote: post #166

Earlier quoted context omitted.

Same with me, never had any interviewer actually give me an actual real rebuttal, other than "but it scales!!". I love software, but I really get tired of the blind cargo-cult culture of most of the industry.

I'm not an interviewer, but: * Version controlled deployments of your application via K8s state files * Once an application is live, you can easily deploy a new version and have traffic drained over for you * Recovery of applications (Pods) that fall over * Automatic replacement of your application when a piece of hardware fails (K8s will see the Pod has died and bring it back up elsewhere) * You can use labels and o…

You've summarized it really well, been using k8s for the past year on a large microservice infra and it's been a pleasant experience. Most problems were flaws in the way our cluster was setup or our misunderstanding of the config options k8s provides.

Re: You might not need Kubernetes

#293

Post by sdotsen »

wilsonnb3 wrote: post #266
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…

I did a programming project for a job interview recently at a company called Willowtree that makes iOS and Android apps for other companies. It was a pretty simple project, basically wrap a rest API around some JSON data provided to you. I ended up deploying mine to Google Cloud Platform onto a VM running Ubuntu and Apache, and they seemed rather concerned that I took that approach instead of leveraging some kind of…

You prob dodged a bullet then. We give out take home exercises (not my idea but whatever), and we tell the client we don't care which config mgmt you use just pick something you're comfortable with. We use TF+Ansible but we would never frown upon work that's something using Salt, Chef or CFEngine.

Re: You might not need Kubernetes

#294

Post by radlad »

TheDong wrote: post #214
radlad wrote: post #213

Earlier quoted context omitted.

A Dockerfile is an input which produces an image as an output. That image should not suffer from the bit rot examples you gave (e.g. "what about older versions of packages in debian's apt repos that have been deleted?") However, when security patches are released, your image obviously will not contain them.

I am not arguing that the docker image output is mutably changing. It is a good artifact that can be reproducibly run. The comment I am originally replying to is 'docker image definitions are idempotent'. Note, 'image definitions', not 'images'. My point has nothing to do with the image, but with the image definition itself.

Understood, just trying to point out there is still a flaw with the image (in that updates are actually important!)

FWIW at my work, we don't use apt for installing packages. We compile the packages as a part of the Docker build. This generates mostly idempotent builds.

Re: You might not need Kubernetes

#295

Post by movedx »

ngrilly wrote: post #273
movedx wrote: post #252

Earlier quoted context omitted.

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

At present, yes. It could be easily overcome with a simple A/B deployment mechanism.

Re: You might not need Kubernetes

#296

Post by movedx »

atleta wrote: post #287
movedx wrote: post #252

Earlier quoted context omitted.

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

> I've containerised a recent Go application I wrote. All it contains is the binary, an assets/ directory for CSS ... So basically you're using docker in place of tar here really. Not saying it's not convenient but it doesn't give you anything above the tools we already had before. You create an installation package locally (it could be a deb, a tar file or even just a local directory) and then transfer it to the dep…

> So basically you're using docker in place of tar here really.

Not even in the slightest. They don't even compare... at all.

By using a TAR archive of you deployment files, you're completely side stepping all the benefits of isolating an application into a container, whether it's a monolith or 56 microservices.

First up: portability and allowing anyone, on any hardware, and any OS to run the application with a single command. All they need to do is install Docker and "docker run" will do the rest. With a TAR file based deployment, they need TAR, they need to know how-to deploy the application and manage the files; they may need some runtime on their system like Ruby, Python or NodeJS; and they cannot restrict the resources the application is using...

On the back of the above: for your developers to fire up a new version of the application that a collogue may have written requires muddling around in Git and using branches -- this interrupts work flows and can lead to lose of work if "git stash" isn't used right. With a container: they just run it.

Secondly you can restrict the resources the application is using inside of a container much easier than you can with one that is not.

I'll make one final point here: Docker Compose. You're missing out on a lot of free stuff here. It's so easy to write a Docker Compose file that brings up everything needed by the application - databases, caches, mocked APIs - allowing anyone in your organisation to bring up the application on their laptop and play with it, including the CEO, DBAs, QA, the receptionist.

You're ignoring all of this because... well I can't put my finger on it, to be honest. Maybe you enjoy hurting your self? lol

Good luck. I don't feel it's worth responding to future comments on this thread. You're clearly unwilling to listen or try new things.

> It's similar to how I deploy the projects. I use fabric (for copying files and executing remote commands, e.g. for db migration) in place of a makefile, but the idea is the same.

Haha! No, they're not the same idea. One is idempotent and the other is not. That's a big differences. And why Fabric? Why not Ansible or Salt Stack?

Man what a way to make your life more difficult for no reason.

Re: You might not need Kubernetes

#297

Post by ngrilly »

movedx wrote: post #295
ngrilly wrote: post #273

Earlier quoted context omitted.

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?

At present, yes. It could be easily overcome with a simple A/B deployment mechanism.

I used to do that before switching to Docker swarm mode (docker stack deploy automates rolling deploys with zero downtime). In my experience, it's not that simple to do it correctly. You have to start the new containers, wait for them to be ready, then switch traffic to the new containers, drain connections to the old containers, and eventually stop the old containers. You need some kind of reverse proxy to do this, or at least iptable rules.

I'm curious: how would you do it? Is your app directly exposed on the Internet, or is it already behind a reverse proxy?

Re: You might not need Kubernetes

#298

Post by movedx »

ngrilly wrote: post #297
movedx wrote: post #295

Earlier quoted context omitted.

At present, yes. It could be easily overcome with a simple A/B deployment mechanism.

I used to do that before switching to Docker swarm mode (docker stack deploy automates rolling deploys with zero downtime). In my experience, it's not that simple to do it correctly. You have to start the new containers, wait for them to be ready, then switch traffic to the new containers, drain connections to the old containers, and eventually stop the old containers. You need some kind of reverse proxy to do this,…

You're not wrong. It's not simple, but it's also not that hard, really.

Yeah I use a DigitalOcean load balancer in front of the servers. At this point in time the application serves my family and friends. It's not critical. And even when or if it does become public, even then I would just use maintenance windows.

Not sure what the benefit of zero downtime deployments are, to be honest. They make things complicated for a few seconds of downtime to switch traffic over. You can even make a maintenance page that's all fancy and checks for the backend coming back up and then redirects traffic... not that hard at all.

I might consider Swarm. Probably not though. I do agree those technologies can complicate matters but they can also make life easier. I guess it's a balancing act, isn't it?

Re: You might not need Kubernetes

#299

Post by icebraining »

jerf wrote: post #132
wpietri wrote: post #87

Earlier quoted context omitted.

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

How can Ansible be "massive overkill"? It's literally an interpreter of scripts, just like sh or bash. It doesn't require daemons or other infrastructure, just connects over SSH and runs the script.

Re: You might not need Kubernetes

#300

Post by icebraining »

sowhatquestion wrote: post #271
woolvalley wrote: post #270

Earlier quoted context omitted.

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

Declaring types in a dynamic language only to have them ignored at runtime does not inspire much confidence.

Funny, I see it the other way; declaring types in a dynamic language yet only having them checked at runtime does not inspire much confidence. With mypy, you actually get static checking, so you're not dependent on your tests hitting the bug.

Post reply on HN