5 ms·

Stackstorm has been around since 2014 [1]. Rundeck is another closest competitors that worth mentioning. Things have evolved a lot in the ops space since then.

Stackstorm has been around since 2014 [1]. Rundeck is another closest competitors that worth mentioning. Things have evolved a lot in the ops space since then. With advent of container orchestration of the operational automation pieces have also moved to the orchestration layer. There have been quite some new tools in the space I have been tracking for instance Fylament [2] which got acquired by netapp, blinkops etc. Post rendezvous with this domain, some bigger problems most of the major framework tools like this have is that, it is very hard to get started. There are lot of pre-requisites given the nature of the ops automation, this leads to a problem where it is very hard to active a customer. Secondly, these frameworks are always competing with it is bash/python script deployed with some container orchestration or some cronjobs. I have also seen people write CRDs and reconciliation loops in k8s doing lot of the tasks these automation frameworks would do. [1] https://en.wikipedia.org/wiki/StackStorm https://en.wikipedia.org/wiki/StackStorm [2] https://www.netapp.com/newsroom/press-releases/news-rel-20220223-487305/ https://www.netapp.com/newsroom/press-releases/news-rel-2022...

chillfox 4y ago
Every time I need to automate something and I look at these solutions it becomes clear that I can put together a Ruby script to handle it much faster than getting one of these automation solutions up and running.
- debarshri 4y ago
  I agree that writing a ruby script is tempting. Where I disagree with you is that, when you have an organisation of 100s of devs, these scripts become tech debt. You need to have standard operating procedures delivered via one platform, that's when rundeck et al plays an important role.
  - chillfox 4y ago
    Never have been able to get management buy in for automation. I even had one manager tell me that there was value in having someone do it manually instead of automatic, I suspect part of their pay or career progression was based on the size of their team.
    - debarshri 4y ago
      That is precisely what I mentioned in my first post. Activating the customer and getting them to value is the biggest challenge these frameworks have. It is hard to buy into a framework from get go.
      - chillfox 4y ago
        So part of the problem from a sysadmin/developer perspective here is that these automation solutions are too difficult/time consuming to setup on the side and prove their value to management. They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can.
        gjvc 4y ago
        They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can. They absolutely can. Find a spare host or create a VM. Write a shell script to run docker, or much better, use "docker compose" to create the setup. Have it run on the quiet for a while and get familiar with it, a little more every day, before using it in production. It's crucial that you are confident about using it, so that when you come to sell it to anyone else, your confidence transfers to them. (Sales, in large part, is about the transfer of feeling.) Once you have got the deployment and backup/restore, and tool-specific critical procedures clear in your mind, you're ready. It's not a five-minute job; it's about demonstrating your strategic value to management by getting out of the toil loop. But, to be clear, if you feel you don't have the backing of anyone about such things, you certainly have my sympathy. The best way I have found out of the mire is to work on a workflow (create/destroy, backup/restore, LDAP integration) a little a day, until it's there, and then suddenly, your work put in over the days and weeks will be an overnight success. Good luck!
        chillfox 4y ago
        The competition is cron and a folder of scrips which provides a productive result from day one. I am not in an ops role at the moment, but in the past nothing has been able to beat cron. And the main reason is the time required to get automation tools up and running.

chillfox 4y ago

Every time I need to automate something and I look at these solutions it becomes clear that I can put together a Ruby script to handle it much faster than getting one of these automation solutions up and running.

debarshri 4y ago
I agree that writing a ruby script is tempting. Where I disagree with you is that, when you have an organisation of 100s of devs, these scripts become tech debt. You need to have standard operating procedures delivered via one platform, that's when rundeck et al plays an important role.
- chillfox 4y ago
  Never have been able to get management buy in for automation. I even had one manager tell me that there was value in having someone do it manually instead of automatic, I suspect part of their pay or career progression was based on the size of their team.
  - debarshri 4y ago
    That is precisely what I mentioned in my first post. Activating the customer and getting them to value is the biggest challenge these frameworks have. It is hard to buy into a framework from get go.
    - chillfox 4y ago
      So part of the problem from a sysadmin/developer perspective here is that these automation solutions are too difficult/time consuming to setup on the side and prove their value to management. They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can.
      - gjvc 4y ago
        They basically can’t start as a one or two person on the side initiative and then grow the way other technologies like introducing version control and CI can. They absolutely can. Find a spare host or create a VM. Write a shell script to run docker, or much better, use "docker compose" to create the setup. Have it run on the quiet for a while and get familiar with it, a little more every day, before using it in production. It's crucial that you are confident about using it, so that when you come to sell it to anyone else, your confidence transfers to them. (Sales, in large part, is about the transfer of feeling.) Once you have got the deployment and backup/restore, and tool-specific critical procedures clear in your mind, you're ready. It's not a five-minute job; it's about demonstrating your strategic value to management by getting out of the toil loop. But, to be clear, if you feel you don't have the backing of anyone about such things, you certainly have my sympathy. The best way I have found out of the mire is to work on a workflow (create/destroy, backup/restore, LDAP integration) a little a day, until it's there, and then suddenly, your work put in over the days and weeks will be an overnight success. Good luck!
        chillfox 4y ago
        The competition is cron and a folder of scrips which provides a productive result from day one. I am not in an ops role at the moment, but in the past nothing has been able to beat cron. And the main reason is the time required to get automation tools up and running.