3 ms·

> GitLab Workhorse is a Go service in front of our Ruby on Rails monolith and it's deployed as a sidecar inside of the webservice pod, which runs Ruby on Rails

> GitLab Workhorse is a Go service in front of our Ruby on Rails monolith and it's deployed as a sidecar inside of the webservice pod, which runs Ruby on Rails using the Puma web server. It's always amazing to me how complicated web stuff has gotten these days. I started out in the LAMP days over 20 years ago. I'm not this complexity is necessarily bad. I don't know the details and I don't know how to make a web app scalable today. But damn if this doesn't sound like a pile of hot garbage waiting to fail to my ears.

klysm 4y ago
I think ruby is mostly to blame. Proxies are almost always useful though and rarely contain that much complexity.
- davedx 4y ago
  This was nothing to do with ruby. It was to do with how docker, k8s and shells interact when trying to shut down processes.
marcosdumay 4y ago
Compare it with Gogs, that is an executable that you run. (Yes, it doesn't do CI/CD, but I don't think avoiding a CI/CD server is worth the extra complexity.) GitLab (the software) is a child of the microservices culture. That said, that architecture is probably a very good fit for GitLab (the company). It's just not very good for other people to self-host it.
- anderspitman 4y ago
  This is one of the reasons I'm focused on helping self-hosting take off. It reduces the complexity of the software by an order of magnitude, while retaining much of the scalability. One problem is it's still too hard. Hosting your own Gitea/gogs shouldn't be any more difficult or less secure than installing an app on your phone. This is where my work is currently. Another problem is things like repo stars. You can federate, but then every instance has to deal with spam. Not sure what a great solution to this is.
bastardoperator 4y ago
It is bad which is why all of these OSS products have consortiums and millions of marketing dollars behind them. Just look at the Platinum members of the CNCF. All cloud companies for the most part. Who really benefits from Kubernetes? I suspect it's the wallet of the Platinum members... I'm not saying the technology isn't good or solves a certain problem, but the reality is kubernetes is being heavily marketed and in many cases I've encountered it wasn't a good fit for what the team was trying to do. A server and copying files would have been easier but they've already made an investment and going back would look like failure.

klysm 4y ago

I think ruby is mostly to blame. Proxies are almost always useful though and rarely contain that much complexity.

davedx 4y ago
This was nothing to do with ruby. It was to do with how docker, k8s and shells interact when trying to shut down processes.

marcosdumay 4y ago

Compare it with Gogs, that is an executable that you run. (Yes, it doesn't do CI/CD, but I don't think avoiding a CI/CD server is worth the extra complexity.) GitLab (the software) is a child of the microservices culture. That said, that architecture is probably a very good fit for GitLab (the company). It's just not very good for other people to self-host it.

anderspitman 4y ago
This is one of the reasons I'm focused on helping self-hosting take off. It reduces the complexity of the software by an order of magnitude, while retaining much of the scalability. One problem is it's still too hard. Hosting your own Gitea/gogs shouldn't be any more difficult or less secure than installing an app on your phone. This is where my work is currently. Another problem is things like repo stars. You can federate, but then every instance has to deal with spam. Not sure what a great solution to this is.

bastardoperator 4y ago

It is bad which is why all of these OSS products have consortiums and millions of marketing dollars behind them. Just look at the Platinum members of the CNCF. All cloud companies for the most part. Who really benefits from Kubernetes? I suspect it's the wallet of the Platinum members... I'm not saying the technology isn't good or solves a certain problem, but the reality is kubernetes is being heavily marketed and in many cases I've encountered it wasn't a good fit for what the team was trying to do. A server and copying files would have been easier but they've already made an investment and going back would look like failure.