Why is it called automation?



  • @Pete-S said in Why is it called automation?:

    If we do the car analogy an automatic transmission will shift whenever it sees fit depending on input from the cars speed,

    Based on input from the driver of the vehical, applying more or less pressure on the accelerator or brake.

    So yeah, you're still telling the system "what you want it to do".



  • @scottalanmiller said in Why is it called automation?:

    So.... how is that unlike Salt, Ansible, etc.? Like an automatic transmission, once set up, it drives for you. Even steers. So your example seems to be showing how, since you don't need to press a button, it is automated.

    It's unlike the "automation" tools because they don't do anything by themselves.



  • @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    So if the factory isn't setup that a dump truck can't drive up and just unload a bunch of metal onto a magical belt and the factory can't sort it out it's not an automated factory?

    Your logic here makes no sense.

    Some intervention is always required, just like with your car analogy that proves you're very clearly wrong.



  • @DustinB3403 said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    So if the factory isn't setup that a dump truck can't drive up and just unload a bunch of metal onto a magical belt and the factory can't sort it out it's not an automated factory?

    Your logic here makes no sense.

    Some intervention is always required, just like with your car analogy that proves your very clearly wrong.

    Most factories have some manual processes yes. Those parts of the factory are then not automated. If it was fully automated the dump truck would have to be automated too.



  • @Pete-S said in Why is it called automation?:

    @DustinB3403 said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    So if the factory isn't setup that a dump truck can't drive up and just unload a bunch of metal onto a magical belt and the factory can't sort it out it's not an automated factory?

    Your logic here makes no sense.

    Some intervention is always required, just like with your car analogy that proves your very clearly wrong.

    Most factories have some manual processes yes. Those parts of the factory are then not automated. If it was fully automated the dump truck would have to be automated too.

    So then you understand that in order to get a car to move, you have to build the engine in a manner in which the pistons can be moved, the spark plugs fire, the brakes and accelerator all work.

    The same thing with something like salt or ansible, you have to build the car or factory, from there it'll do what it's programmed to do.



  • @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    Right, but again, just like Ansible or Salt. You seem to be arguing that they are automation with each example.

    And that factory is run by.... just a script. That's what does that automation there.



  • @JaredBusch said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    But it had to be setup to do so in the first place.

    Yes, true. That the job of automation engineers in that case.

    An automated assembly line for instance would have robots working on it. Someone has to program them initially.

    If it was humans working on the assembly line it would not be an automated assembly line.



  • @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    So.... how is that unlike Salt, Ansible, etc.? Like an automatic transmission, once set up, it drives for you. Even steers. So your example seems to be showing how, since you don't need to press a button, it is automated.

    It's unlike the "automation" tools because they don't do anything by themselves.

    What? They do EVERYTHING by themselves. That's their purpose. What do you mean that they don't do anything? Everything you are describing - having them do all of the work without human input, is exactly what they are for. Anything else and you are misusing them.



  • @Pete-S said in Why is it called automation?:

    An automated assembly line for instance would have robots working on it. Someone has to program them initially.
    If it was humans working on the assembly line it would not be an automated assembly line.

    Even automated robots need to be put into mode by humans. They don't just up and move on their own whenever they want. Like @scottalanmiller said earlier, they would have to be sentient otherwise. All automated processes have to be started somehow.



  • @Pete-S said in Why is it called automation?:

    @JaredBusch said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    But it had to be setup to do so in the first place.

    Yes, true. That the job of automation engineers in that case.

    An automated assembly line for instance would have robots working on it. Someone has to program them initially.

    If it was humans working on the assembly line it would not be an automated assembly line.

    Right, exactly like Salt or Ansible or Puppet. Set it and away it goes. You only need to get involved if you want to modify the automation.



  • Okay, everyone hold up. The issue has to be that @Pete-S isn't understanding what these tools are and is thinking that they are remote access tools like MeshCental or ScreenConnect and isn't understanding that they are state engines which, by definition, are automation as there can be no human intervention in the state machine.

    So the discussion going on is going to go nowhere and just be an argument unless we address explaining that the underlying problem is that he's not trying to redefine automation, but doesn't know what Ansible and Salt are for.

    We are all trying to describe automation, but everyone agrees on what automation is. It's that Salt is automation is what is being missed.



  • So let's start with this... once SaltStack is set up, what does @Pete-S think that the role of a human would be?



  • @scottalanmiller said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    Right, but again, just like Ansible or Salt. You seem to be arguing that they are automation with each example.

    And that factory is run by.... just a script. That's what does that automation there.

    No, it's not the script per se that makes it automated. It's the behavior of the system.
    When you have set up ansible for instance you still don't have any automation anywhere. And you have nowhere to define automatic behaviors or responses.



  • @Pete-S said in Why is it called automation?:

    When you have set up ansible for instance you still don't have any automation anywhere. And you have nowhere to define automatic behaviors or responses.

    See... but that is the ENTIRE purpose of Ansible. All of it. Ansible is the "behaviours and responses" system. Without that, it doesn't exist.



  • @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    Likewise, in a factory that is fully automated thing will start and stop automatically. Things will happen automatically all the time. Not magically because there is obviously code behind it.

    If a person would have to press a button each time something has to happen it would not be an automated factory.

    Right, but again, just like Ansible or Salt. You seem to be arguing that they are automation with each example.

    And that factory is run by.... just a script. That's what does that automation there.

    No, it's not the script per se that makes it automated. It's the behavior of the system.
    When you have set up ansible for instance you still don't have any automation anywhere. And you have nowhere to define automatic behaviors or responses.

    FFS no shit.

    Because that is what the Automation Engineer is doing. Settingup Ansible.



  • @Pete-S said in Why is it called automation?:

    No, it's not the script per se that makes it automated.

    Do you agree that a script will produce the same result on different pieces of hardware that are running the same software components, repeatedly?

    If so, then you must agree that a script automates a process of some type. Install these pieces of software, configure these printers, do XY and Z.

    A script automates <something>.

    And by automate, it's installing or doing whatever you have the script configured to do.



  • It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.



  • @DustinB3403 said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    No, it's not the script per se that makes it automated.

    Do you agree that a script will produce the same result on different pieces of hardware that are running the same software components, repeatedly?

    If so, then you must agree that a script automates a process of some type. Install these pieces of software, configure these printers, do XY and Z.

    A script automates <something>.

    And by automate, it's installing or doing whatever you have the script configured to do.

    But a script doesn't just "come into existence" a script has to be created by an automation engineer. I was actually just wearing my AE hat about an hour ago.

    Ansible/Salt etc are an AE's workshop, it's where they create the scripts that they want to be run in the environment.

    You can have a building with machines in it, but unless the AE sets those machines up to be automated, they'd just be pieces of machinery sitting there waiting to do something.



  • @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.



  • @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would keep doing this, adding VMs, as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.



  • @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would do keep doing this adding VMs as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    Of course not. FFS

    That is the AEs job.



  • @DustinB3403 said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would do keep doing this adding VMs as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    Of course not. FFS

    That is the AEs job.

    No, you misread that.



  • @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would do keep doing this adding VMs as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    That is one level of automation. The script/process that monitors and issues the command to create/destroy.



  • @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would keep doing this, adding VMs, as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    But it is a totally different level of automaiton that configures and sets up the instance itself. That is the process/script being called by the process/script that monitors.



  • @Pete-S said in Why is it called automation?:

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would keep doing this, adding VMs, as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    And that's what it does.



  • @Pete-S said in Why is it called automation?:

    But they don't do nothing on their own.

    They do everything on their own.



  • @JaredBusch said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would keep doing this, adding VMs, as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    But it is a totally different level of automaiton that configures and sets up the instance itself. That is the process/script being called by the process/script that monitors.

    Right either the automation is inside these tools, or they automate another tool. But the end result is end to end automation.



  • @JaredBusch said in Why is it called automation?:

    @Pete-S said in Why is it called automation?:

    @scottalanmiller said in Why is it called automation?:

    @bnrstnr said in Why is it called automation?:

    It seems like he's thinking about automation as, say, load balancing. Two servers responding to whatever variables on their own.

    Which Ansible and Salt will do 🙂 That's one of their use cases.

    But they don't do nothing on their own. If you could define in Ansible that you wanted it to automatically install a new webserver VM when the load on the current VMs are over 60% for 10 minutes and change a load balancer to start using the new host. And it would keep doing this, adding VMs, as long as it is needed and then when load is under say 10% for an hour it would go destroy the VMs one by one. That would be automation.

    But it is a totally different level of automaiton that configures and sets up the instance itself. That is the process/script being called by the process/script that monitors.

    If the tools were really automation tools they would have all this and much more.

    Ansible is like an actuator. Something that makes another thing move, turn, open, close etc.
    With Ansible as an example, you can define the state of a system and when you run the script it will put the system in that state by installing, removing, changing files, running commands etc.

    That's great but it lacks the automation parts that makes things automatic. It lacks what is called a control system, which is where you define behaviors. X will happen when situation Y happens.

    You could cobble that part together with scripts just like you could do the actuator part without ansible and just scripts. And you could cobble together fetching inputs from the systems which is what you will base decisions on. For it to be called an automation tool you would really need all these components inside and they are not there.



  • @Pete-S

    The product automation but they need heck a lot of manual labor.



  • @Pete-S said in Why is it called automation?:

    You could cobble that part together with scripts just like you could do the actuator part without ansible and just scripts. And you could cobble together fetching inputs from the systems which is what you will base decisions on. For it to be called an automation tool you would really need all these components inside and they are not there.

    But those parts already exist in the systems that Salt or Ansible automate. Salt is automation, it just isn't the "automation of absolutely everything, even things that it is automating." You want it to replace all of the automation, all of the way down the stack and that isn't feasible or logical. It just doesn't make sense. Nor does it apply in any other situation.

    In your factor, there is no single automation tool that does all of the automation, each piece has its own automation and some automation tooling controls the whole. Nothing complex like this is automated by one thing.

    There is no logical end to this train of thought. If automating other automation isn't automation, then you'd have to write a singular OS with built in in-kernal automation and limit everything you do to that one system. The moment you want something external to automate something internal you have automation " in pieces" simply by definition.

    So within the confines of automation, these tools are complete automation.


Log in to reply