[rglullis]

Yeah, this is the way to end up with ad-hoc, bug-ridden, half-baked implementation of fabric (or ansible, salt, helm, nix, or any tool that is more appropriate for this job)

And you haven't addressed the issue that whoever is performing the role of DevOps on this project must know Go.

[fragmede]

If your person doing DevOps can't learn GoLang, you have bigger problems.

[rglullis]

Nice "No true Scotsman", and you are completely missing the point.

[fragmede]

You are erroneously invoking a fallacy that does not apply here. A qualified DevOps engineer will be able to pick up GoLang. I didn't claim that a DevOps engineer already knows GoLang, but that they're able to pick it up. If I'd say only true devops engineer's already know golang, you'd have a point.

Unfortunately, you missed it too.

[rglullis]

> qualified DevOps engineer

Which is not something that one professional needs to be in order to have to perform some duties that fall within the role of DevOps.

I am, first and foremost, an application developer using Python and JavaScript. But I also have extensive experience:

- setting up Docker Swarm clusters

- managing cloud infrastructure with Terraform

- configuring deployments with Ansible

- setting up observability on Prometheus/Loki/Grafana stack

- putting up together CI servers for my team

- setting up backup/restore infrastructure.

- deploying and managing internal OSS tools for a dev/data team: Gitea, Taiga, Redash, Apache Airflow, Baserow...

These are all tasks that could be part of a "DevOps Engineer" job description, but if you tell me that "to work with a primarily Golang dev team you need to pick up Golang", I'd be assuming that you are not looking primarily for a DevOps Engineer, but a Go Developer who can do DevOps. And because I am not a Go Developer, you'd be putting my whole application on the bottom of the Stack.

[fragmede]

Your point, that doing this ad-hoc in go results in a half-baked shitty reimplementation of ansible/chef/fabric/whatever, was well made. I totally agree with it.

My point was, is that the DevOps person needs to be smart enough to pick up Go, which I'm sure you are.

Any hiring manager that puts your whole application on the bottom of the stack because of a lack of experience isn't a good hiring manager and isn't worth your time.

[dotancohen]

Do fabric,ansible, salt, helm, or nix have the functionality of deploying to cloud infrastructures? There is a lot more to deploying to cloud infrastructures then just provisioning a server.

I've never seen these tools used in this capacity, especially nix.

[pxc]

I think such things have existed, but Nix deployment tools being relatively small projects with small teams or solo devs, a more common approach is to piggyback off of other IaC tools provisioning cloud infrastructure, e.g. by templating Terraform in Nix¹.

From a Nix user's perspective, this leaves a lot to be desired, because tools like Terraform are much less reliable than Nix tools that target local machines, and their management of, say, a VPC, is much less comprehensive than NixOS' management of an individual operating system. And they're slow as hell. But for the most part these issues are inherited from the APIs cloud providers expose, which don't meaningfully or uniformly support immutability.

--

1: https://github.com/terranix/terranix

[rglullis]

One could argue that if you are at the stage of "provisioning a server", then you should be using something like Terraform or Pulumi, not configuration tools like the one I mentioned.

Anyway, for the specific case of "deploying to hetzner":

- ansible has a whole collection of modules for hetzner: https://docs.ansible.com/ansible/latest/collections/hetzner/...

- For Nix, there is NixOps

- if no one in the team wants to learn any of that, Hetzner provides a CLI to interact with their whole cloud.

To repeat: the last thing I'd want from an application is to have its own deployment system.