Ansible is great, but (imo) aged. Sure it's good for dealing with legacy hardware that cannot support terraform like state, but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
Is there anything in Ansible that is susceptible to aging?
I mean, Ansible is a tool designed to apply idempotent changes on one or more computer nodes following a declarative specification, and that only requires ssh access to work. What is there to age?
> Sure it's good for dealing with legacy hardware that cannot support terraform like state,
What? Exactly what leads you to believe that anything in Ansible is tied to hardware, let alone legacy hardware? And what do you mean by "terraform like state"?
> but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
I don't understand what you tried to say, and frankly your comment sounds like an AI-generated buzzword soup.
With Ansible you need to specify the configuration state you want your nodes to have, and you need to apply configuration changes in a consistent sequence. This means not only specifying the configuration changes but also the verification and validation checks. The extent of your playbooks depend on how extensive your configuration is.
> Ansible solved a large problem (config management) before the kubernetes era (...)
Your comment makes absolutely no sense at all. Kubernetes provides a way to create clusters and run apps on them, but COTS hardware or VM instances aren't magically born into a working cluster node. What Kubermetes does is something that bears no resemblance to what Ansible actually does. Ansible is used to configure nodes without requiring anyone to install any specialized software other than setting up a working SSH connection. I personally use Ansible for stuff like setting up a Kubernetes cluster on COTS hardware running fresh Ubuntu installs using MicroK8s. How exactly do you expect to pull that off with Kubernetes?
> Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
Depends on the size of your business. For small-medium size businesses, Ansible and VMs require much less support and developer knowledge than Kubernetes and containerisation.
I worked for a business with a million customers who served them using 10 VMs.
I don’t disagree, but what is there for a terraform-like state config management system for bare metal and VMs when they are necessary? What provisions the machines that run the clusters?
Kubernetes for small and medium businesses is extremely inefficient. I definitely wouldn't want to be dealing with that at this stage of my business's growth.
Not sure how containerization would help in case of for instance network devices or baremetal servers management. You've picked only a small use case for Ansible, there's much more.
Saw him do a talk where he went from hello world to automating a bunch of LEDs in couple hours and easily followed along the whole way through.
Ansible is so much more powerful than Terraform (IHMO, due to its pre-cloud roots). Too bad about lack of a "revert" feature/pattern and lack of multi-repo glue/scaffolding.
[+] [-] chologrande|2 years ago|reply
Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.
[+] [-] rewmie|2 years ago|reply
Is there anything in Ansible that is susceptible to aging?
I mean, Ansible is a tool designed to apply idempotent changes on one or more computer nodes following a declarative specification, and that only requires ssh access to work. What is there to age?
> Sure it's good for dealing with legacy hardware that cannot support terraform like state,
What? Exactly what leads you to believe that anything in Ansible is tied to hardware, let alone legacy hardware? And what do you mean by "terraform like state"?
> but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.
I don't understand what you tried to say, and frankly your comment sounds like an AI-generated buzzword soup.
With Ansible you need to specify the configuration state you want your nodes to have, and you need to apply configuration changes in a consistent sequence. This means not only specifying the configuration changes but also the verification and validation checks. The extent of your playbooks depend on how extensive your configuration is.
> Ansible solved a large problem (config management) before the kubernetes era (...)
Your comment makes absolutely no sense at all. Kubernetes provides a way to create clusters and run apps on them, but COTS hardware or VM instances aren't magically born into a working cluster node. What Kubermetes does is something that bears no resemblance to what Ansible actually does. Ansible is used to configure nodes without requiring anyone to install any specialized software other than setting up a working SSH connection. I personally use Ansible for stuff like setting up a Kubernetes cluster on COTS hardware running fresh Ubuntu installs using MicroK8s. How exactly do you expect to pull that off with Kubernetes?
[+] [-] okeuro49|2 years ago|reply
Depends on the size of your business. For small-medium size businesses, Ansible and VMs require much less support and developer knowledge than Kubernetes and containerisation.
I worked for a business with a million customers who served them using 10 VMs.
[+] [-] jonwest|2 years ago|reply
[+] [-] selfhoster11|2 years ago|reply
[+] [-] allarm|2 years ago|reply
[+] [-] influx|2 years ago|reply
[+] [-] ed-209|2 years ago|reply
Ansible is so much more powerful than Terraform (IHMO, due to its pre-cloud roots). Too bad about lack of a "revert" feature/pattern and lack of multi-repo glue/scaffolding.
[+] [-] planetafro|2 years ago|reply
[+] [-] ChrisRR|2 years ago|reply
[+] [-] NickKampe|2 years ago|reply
[+] [-] AndrewDavis|2 years ago|reply
Thanks!
[+] [-] asfarley|2 years ago|reply