What is our primary use case?
We use it both internally on our managed services offerings, which are new for us, and I've used it for the last two years in my customers' environments to help me with deployments, primarily on the networking side. We also place a big focus on source control and the software development lifecycle.
How has it helped my organization?
It's going to help differentiate our services. It's something new that we're using internally, and our managed services, themselves, are new within Canada. It's something we're doing to help scale faster. Our company has an offering called through which we manage the subscriptions to various cloud providers for clients. We help them to automate that component.
We also offer another service to help customers connect to various clouds effectively, through VPNs to different clouds. A big piece of that is standardizing. If client A comes in, versus client B, we want to standardize that process and make it repeatable, so we're templating that as much as possible in Ansible.
Sometimes we'll combine various tools so we'll use Ansible on a native cloud formation. We're looking at Ansible as our key orchestration engine for the data model that we developed internally and to help pump that out.
What is most valuable?
To me, a great thing about Ansible is that it can do everything. Cloud, on-prem, Windows, Linux, networking. I've not seen any other orchestration tool able to do that as easily.
The biggest thing I like about Ansible is the check mode so that we can verify, after we've pushed, that the config is actually what we intended. That's a big feature that I like about the product.
What needs improvement?
The way it's going to improve is with the community contributing more to the platform in terms of modules that interact with different devices. And perhaps it can contribute use cases, which is something I'm very focused on: documenting and showing them to customers; not just roles but how I use those roles, how I get started.
Part of my initiative, in terms of using Ansible to build Ansible, is to demonstrate how I properly structure Ansible to deploy to a server with various roles. In my case, my role works on both Red Hat and Ubuntu Debian: How do you structure it to handle multi-OS, which is something I've learned from Jeff Geerling, whom everyone knows.
The power of the community is what's going to make it better. It feels like it's growing every year. It's how the community is coming together. There's a lot of enthusiasm around that and it's contagious. People are excited about it. It has really been fun being here at AnsibleFest 2018 and seeing the passion about the product.
What do I think about the stability of the solution?
From an Ansible perspective, it is stable. Working more on the networking side, typically the challenge is with the particular networking device that we're dealing with: specifically, getting structured data returned, with the consistency of the CLI, across platforms. The challenges are not necessarily Ansible, per se, they're more because of the variety of vendors.
It's impossible to tell Ansible, "Okay, handle every use case possible, every version of code." I've been trying to identify issues with platforms and how we can address them by fixing a module or parsing that data properly, without having to get Cisco to fix it in our code. That approach is somewhat backward, but we've had to deal with it a few times.
What do I think about the scalability of the solution?
So far, we haven't run into any scalability issues. We haven't needed to scale to the levels I've heard spoken about here at AnsibleFest 2018. Certainly, this summer, we used it to push over 8,000 lines of code on network devices and it worked quite well.
How was the initial setup?
In terms of the setup, there are still aspects that are a bit complex to set up, especially the different Python libraries' dependencies. I use it against Windows as well and that means integrating with Kerberos. But I've actually developed a role on GitHub to stand up an Ansible development workstation with all those requirements to make it easy. I actually use Ansible to deploy Ansible, which is kind of ironic.
What other advice do I have?
Another thing that I've been doing is mentoring teams on how to use Ansible. Ironically, I've been mentoring the server teams, which is where I worked in the first part of my career. I was more on the server side: Windows, a little bit of Linux. But I find it's so easy to use that it's more about the concepts and the Ansible language.
I saw a very interesting use case where Harvard University Online essentially does its entire deployment using Ansible end-to-end, with native infrastructure. That is geared to a lot of things we do within our managed services. I knew that was possible, but seeing it in real life, how they deployed and the number of different stacks that they've touched, was something. Their ability to demonstrate they've done that is pretty remarkable.
Because some documentation needs to be improved - while getting started with it is getting better - it's hard to give it a perfect ten. It's definitely in the top products that I suggest to customers. I would rate it a nine out of ten. But you have to look at it as a framework. It's not going to come in and solve all of your problems, but you can build on it. You can develop your own module if it doesn't ship with the product. The core of Ansible is very solid.