Ansible is a procedural mess. It's like helm had a baby with a very bad procedural language. It works, but it's such a mess to work with. Half of the time it breaks because you haven't thought about some if statement that covers a single node or some bs.
Comparing that to docker swarm and/or k8s manifests (I guess even Helm if you're not the one developing charts), Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism (i.e. desired state like K8s manifests).
> Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism
We thought this, too, when choosing Salt over Ansible, but that was a complete disaster.
Ansible is definitely designed to operate at a lower abstraction level, but modules that behave like desired state declarations actually work very well. And creating your own modules turned out to be at least an order of magnitude easier than in Salt.
We do use Ansible to manage containers via podman-systemd, but slightly hampered by Ubuntu not shipping with podman 5. It's... fine?
Our mixed Windows, Linux VM and Linux bare metal deployment scenario is likely fairly niche, but Ansible is really the only tenable solution.
Isn't this tiered support a necessity when operating at scale? How can you help thousands of customers where faqs and getting starteds don't cut it? You need a filtering mechanism (L1) to help users directly without overloading the product team with a standard reply rtfm.
It's triaging the support so the people who are best-capable of answering specific things don't waste all their time answering the stuff a new hire can take care of after one week training.
Two layers is fine, so long as they're allowed to talk to each other. Adding a third causes a lot more problems.
Once you get beyond having a single dev team, a layer of support is necessary: you can't expect consumers to know which of your dev teams they ought to be talking to.
My employer has an amazing support team, who are effective champions for the user when interacting with development teams. They're fantastic.
That's an important requirement of an effective support team: they have to have a seat at the project management's table. They have to have the power to request features + changes from developers, at the same priority level as the rest of the product development team. IMHO it's important both for the support team morale, as well as ensuring a positive UX.
That said, most of the issues I see from support are straightforwardly bugs, even if they're not normally easy ones to fix. But when they have information they think is worth sharing, it's always been worth my time to listen.
But then the main contributor, Lightbend company, decided to change the license from Apache 2, to BSL.. Now Apache Pekko is the fork that should continue the implementation :)
Note that setting up tere requires defining an alias in your shell config anyway, so you can choose any name you want with basically zero extra effort! Except for coming up with an abbreviation you remember, of course. But I agree, it is faster to type with alternating hands.
