6 ms·

This seems like a terrible case of not separating concerns and needless optimization. It may work for you, but what if someone who does not know Go but wants to

This seems like a terrible case of not separating concerns and needless optimization. It may work for you, but what if someone who does not know Go but wants to use your project on a provider that is not hetzner?

dotancohen 3y ago
Not OP, but I presume that one could add `-deploy-aws` cmd-line to the Go binary with whatever steps AWS requires.
- rglullis 3y ago
  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.
  - dotancohen 3y ago
    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 3y ago
      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 https://github.com/terranix/terranix
    - rglullis 3y ago
      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/hcloud/index.html 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.
  - fragmede 3y ago
    If your person doing DevOps can't learn GoLang, you have bigger problems.
    - rglullis 3y ago
      Nice "No true Scotsman", and you are completely missing the point.
      - fragmede 3y ago
        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 3y ago
        > 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 3y ago
        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.
lelanthran 3y ago
> It may work for you, but what if someone who does not know Go but wants to use your project on a provider that is not hetzner? Well they'd run into the same problem if the script was Python, wouldn't they? And Go is ultimately far far easier to read, modify[1] and debug for someone who doesn't know it than Python is. [1] For example, adding a third-party library to handle new cases. I've never had a good time doing it with Python's various package management, but Go seems pretty good at it.
- rglullis 3y ago
  > Well they'd run into the same problem if the script was Python, wouldn't they? No, they would just use whatever tool is more appropriate for the job. Fabric would be fine, ansible would be fine, salt would be fine, putting it on Docker and deploying via compose would be fine. None of these tools force you to learn the implementation details of the application.
  - lelanthran 3y ago
    > Fabric would be fine, ansible would be fine, salt would be fine, putting it on Docker and deploying via compose would be fine. That still leaves them the problem of "If I don't know this tech stack, what do I do?" You are working on the assumption that everyone already knows Fabric, Ansible, salt or Docker. Whichever poison you choose, people who don't know that particular poison won't know how to install to a different provider anyway! You're making an argument against one particular poison, but I don't see it as any better or any worse than the others, which all have enough complexities to fill a book.
    - rglullis 3y ago
      > "If I don't know this tech stack, what do I do?" If you don't know how to use a tool that does one job, either you learn it or you just delegate that job to someone who knows it already. But defending the practice of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".
tutfbhuf 3y ago
Well, maybe he never wants "someone" to deploy his project. I think it is perfectly legitimate to handle it this way for a one-man hobby project. For a project where multiple people are involved, I think it's better to split concerns. Deployment should be handled transparently and reproducible in a CI pipeline that the team members who are allowed to deploy have access to.
- rglullis 3y ago
  But if you are a one-man show (and you want to keep it that way) you are in no condition to tell what would be the best practice for a team.
  - pdimitar 3y ago
    Yes you are. You are telling yourself what's the best way to do things in your own team, that is comprised of only yourself.
    - rglullis 3y ago
      If your argument can only be made in a very specific set of conditions and only applies to yourself, it's just a preference. I don't care how you prefer to do things on your own, but if I were interviewing you for a senior position in a team with a handful of people, and you tell me that's how you want them to work, it would be an almost immediate NO HIRE.
      - pdimitar 3y ago
        Yes, but you are moving goalposts. I was under the impression we were talking about the one-man army case only, not how they conduct themselves on interviews which is a VERY different topic.
        rglullis 3y ago
        The blog post was about the context of a team with multiple people. OP's comment was "I do this for my Go project's" and goes on to describe how to use a (open source) library that even deploys to Hetzner. So, either the commenter was trying to extend their practice to the point of the blog post or the comment was just expressing a preference when working by themselves, which has little to do with the content of the post.

dotancohen 3y ago

Not OP, but I presume that one could add `-deploy-aws` cmd-line to the Go binary with whatever steps AWS requires.

rglullis 3y ago
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.
- dotancohen 3y ago
  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 3y ago
    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 https://github.com/terranix/terranix
  - rglullis 3y ago
    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/hcloud/index.html 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.
- fragmede 3y ago
  If your person doing DevOps can't learn GoLang, you have bigger problems.
  - rglullis 3y ago
    Nice "No true Scotsman", and you are completely missing the point.
    - fragmede 3y ago
      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 3y ago
        > 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 3y ago
        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.

lelanthran 3y ago

> It may work for you, but what if someone who does not know Go but wants to use your project on a provider that is not hetzner? Well they'd run into the same problem if the script was Python, wouldn't they? And Go is ultimately far far easier to read, modify[1] and debug for someone who doesn't know it than Python is. [1] For example, adding a third-party library to handle new cases. I've never had a good time doing it with Python's various package management, but Go seems pretty good at it.

rglullis 3y ago
> Well they'd run into the same problem if the script was Python, wouldn't they? No, they would just use whatever tool is more appropriate for the job. Fabric would be fine, ansible would be fine, salt would be fine, putting it on Docker and deploying via compose would be fine. None of these tools force you to learn the implementation details of the application.
- lelanthran 3y ago
  > Fabric would be fine, ansible would be fine, salt would be fine, putting it on Docker and deploying via compose would be fine. That still leaves them the problem of "If I don't know this tech stack, what do I do?" You are working on the assumption that everyone already knows Fabric, Ansible, salt or Docker. Whichever poison you choose, people who don't know that particular poison won't know how to install to a different provider anyway! You're making an argument against one particular poison, but I don't see it as any better or any worse than the others, which all have enough complexities to fill a book.
  - rglullis 3y ago
    > "If I don't know this tech stack, what do I do?" If you don't know how to use a tool that does one job, either you learn it or you just delegate that job to someone who knows it already. But defending the practice of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".

tutfbhuf 3y ago

Well, maybe he never wants "someone" to deploy his project. I think it is perfectly legitimate to handle it this way for a one-man hobby project. For a project where multiple people are involved, I think it's better to split concerns. Deployment should be handled transparently and reproducible in a CI pipeline that the team members who are allowed to deploy have access to.

rglullis 3y ago
But if you are a one-man show (and you want to keep it that way) you are in no condition to tell what would be the best practice for a team.
- pdimitar 3y ago
  Yes you are. You are telling yourself what's the best way to do things in your own team, that is comprised of only yourself.
  - rglullis 3y ago
    If your argument can only be made in a very specific set of conditions and only applies to yourself, it's just a preference. I don't care how you prefer to do things on your own, but if I were interviewing you for a senior position in a team with a handful of people, and you tell me that's how you want them to work, it would be an almost immediate NO HIRE.
    - pdimitar 3y ago
      Yes, but you are moving goalposts. I was under the impression we were talking about the one-man army case only, not how they conduct themselves on interviews which is a VERY different topic.
      - rglullis 3y ago
        The blog post was about the context of a team with multiple people. OP's comment was "I do this for my Go project's" and goes on to describe how to use a (open source) library that even deploys to Hetzner. So, either the commenter was trying to extend their practice to the point of the blog post or the comment was just expressing a preference when working by themselves, which has little to do with the content of the post.