301–310 of 319 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
The point is they have been coding away for more than a year without having getting out of beta. The CTO spent 3 weeks learning k8s and setting it up, those 3 weeks which could have been spent on features or ironing out bugs in the product and releasing an actual 1.0 of the product. You can always work on k8s once you have paying customers and have actual demand. Are you telling me you need k8s for not even 10 custom…
Earlier quoted context omitted.
The point is they have been coding away for more than a year without having getting out of beta. The CTO spent 3 weeks learning k8s and setting it up, those 3 weeks which could have been spent on features or ironing out bugs in the product and releasing an actual 1.0 of the product. You can always work on k8s once you have paying customers and have actual demand. Are you telling me you need k8s for not even 10 custom…
For some use cases (GPU) it's considerably less expensive to spend the time learning kubernetes.
Earlier quoted context omitted.
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 fo…
> Yeah I use a DigitalOcean load balancer in front of the servers.
Why the load balancer if the app only serves family and friends, and maintenance windows are okay? It should be able to run on a single server.
> They make things complicated for a few seconds of downtime
In some cases, it's more than "a few seconds of downtime". In one of the apps I maintain, some requests accept file uploads, and some stream long .csv files that are generated on demand. These requests can take several tens of seconds. If the system is unable to start a new version of the app, and switch traffic to it, while keeping existing connections to the old version, then we're talking about at least 1 minute of downtime.
We've thought about simplifying things using a "maintenance page that automatically checks for the backend coming back", but 1 minute is just too long for our paying users.
Some day, we deploy new versions multiple times. Our paying users would be unhappy about the multiple interruptions :-)
That said, with the advent of single-page applications, maybe it should be okay to transparently retry requests on the client side while the app is restarting on the server side (returning 503). No maintenance page. No complex zero downtime logic.
> I might consider Swarm.
We were already using Docker and docker-compose. We manage zero downtime deployments using docker-compose and nginx as a reverse proxy, scripted with Ansible but it was a bit too hacky for my taste. It's when I started to consider Docker swarm mode. And it's really great, even on a single-node, especially when you're already using docker-compose. I'm oversimplifying a bit, but it's basically running `docker swarm init` and replacing docker-compose with `docker stack deploy`. I recommend it.
Earlier quoted context omitted.
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.
> 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 Reminds me of Mongrel2
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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 fo…
Thanks for following up! > Yeah I use a DigitalOcean load balancer in front of the servers. Why the load balancer if the app only serves family and friends, and maintenance windows are okay? It should be able to run on a single server. > They make things complicated for a few seconds of downtime In some cases, it's more than "a few seconds of downtime". In one of the apps I maintain, some requests accept file uploads…
I use DO to manage the DNS for the domain. I use their LB to manage the TLS cert for the domain. By doing this I don't have to manage TLS connections in my application nor deal with certification creation and rotations. DO are doing it for me for $10/month. That's a bargain given my time is worth $100/hour.
I can also easily swap out the backend server, or add more, as I see fit. This falls in line with your zero-downtime argument. The LB is there and ready to go should I want to attempt such things :)
> In some cases, it's more than "a few seconds of downtime". In one of the apps I maintain, some requests accept file uploads, and some stream long .csv files that are generated on demand. These requests can take several tens of seconds. If the system is unable to start a new version of the app, and switch traffic to it, while keeping existing connections to the old version, then we're talking about at least 1 minute of downtime.
But this is the key point of it all: your application and its users demand zero-downtime. My mother (in-law) does not :)
> I'm oversimplifying a bit, but it's basically running `docker swarm init` and replacing docker-compose with `docker stack deploy`. I recommend it.
Looking into it right now. Thanks a lot for the recommendation.
Earlier quoted context omitted.
HN hasn't been fronted by Cloudflare since July.
Why did they stop using Cloudflare?
There are other parts of Y Combinator that still use Cloudflare though.