The Red Hat Ansible Automation Platform (acquired by Red Hat in 2015) is a foundation for building and operating automation across an organization. The platform includes tools needed to implement enterprise-wide automation, and can automate resource provisioning, and IT environments and configuration of systems and devices. It can be used in a CI/CD process to provision the target environment and to then deploy the application on it.
$5,000
per year
ServiceNow IT Service Management
Score 8.5 out of 10
N/A
ServiceNow is a fast-growing service management provider that went public in 2012. Built on the ServiceNow Now Platform, the IT Service Management bundle provides an agent workspace with knowledge management, and modules supporting issue tracking and problem resolution, change, release and configuration management, and (on the higher tier ITSM Professional plan) ITAM and software asset management.
It has helped save us so much time, as it was designed to automate mundane and repetitive tasks that we were using other tools to perform and that required so much manual intervention. It does not work very well within Windows environments, understandably, but I would love to see more integration. I want it to be sexy and attractive to more than just geeky sysadmins.
In our organization, we are using ServiceNow extensively. Change Management, Incident Management, Problem Management, Time tracking are few modules which we use extensively. This sort of model will work for any product or service based companies as the product is built on ITIL framework. So this product will be suited for small or large scale companies to better organize and add controls and track SLA's for technology or business process.
Debugging is easy, as it tells you exactly within your job where the job failed, even when jumping around several playbooks.
Ansible seems to integrate with everything, and the community is big enough that if you are unsure how to approach converting a process into a playbook, you can usually find something similar to what you are trying to do.
Security in AAP seems to be pretty straightforward. Easy to organize and identify who has what permissions or can only see the content based on the organization they belong to.
When I have a number of requests to make, for example a request to add a dozen or so user accounts to more than one group account in Active Directory , I can put all the needed information into the initial form, add it to my "shopping cart" and all of that information remains on the screen for the next item for which I only need to edit a few items (like the AD group name in this example), and keep adding them to the shopping cart until I have them all. When I "Check Out" each of those items is generated as a separate task under the one request. It simplifies and expedites the creation and tracking of these kinds of requests.
I can easily and quickly see what tickets are currently assigned to me in order to prioritize them and remain aware of my workload.
Numerous fields for CIs can be used when trying to find the entry for a particular item. For example, IP Address, server name, raw text, classification, and so on.
To help with making sense out of related tasks, when a task is assigned to me and I need to open another task for a different team to work in order to complete my task, I can open a sub-task from my ticket so that the relationship between the two can be pulled up later into reports. For example, I may have a task to build a new vm, and need to open tasks for networking, security accounts, software installation and so on. By opening sub-tasks from my assignment, the time spent by all parties concerned is tied together for more meaningful cost accounting.
YAML is hard for many to adopt. Moving to a system that is not as white space sensitive would likely increase uptake.
AAP and EDA should be more closely aligned. There are differences that can trip users of the integration up. An example would be the way that variables are used.
Event-driven Ansible output is not as informative as AAP.
It is hard to find areas for improvement, the tool is very powerful. That said, building the CMDB still involves some manual interaction which was not how it was presented in demos.
The CMDB data is almost too deep and detailed. When you build the relationship map it can be so large that it is overwhelming. You can limit this, but the default maps are massive if you are discovering lots of device classes.
The product is expensive. Since they are the leader in the industry and the product has tons of features, they definitely charge for it!
Even is if it's a great tool, we are looking to renew our licence for our production servers only. The product is very expensive to use, so we might look for a cheaper solution for our non-production servers. One of the solution we are looking, is AWX, free, and similar to AAP. This is be perfect for our non-production servers.
To be completely honest setting up a new ticketing system can be a pain in the ass. Once you have it setup and customized the way you want it, you don't want to switch unless you're unhappy with the product. Unless future releases and updates really muck the system up, I wouldn't change.
The dashboard is so confusing, [there are] many clicks to open a task and search by a ticket. The Enterprise customisation [we did] has finished to kill the software and creates a really bad experience on a daily basis. [It is] So slow, and so many clicks to process a ticket. Works only on IE so, that [should] make you realize that [it] is a bad idea.
Great in almost every way compared to any other configuration management software. The only thing I wish for is python3 support. Other than that, YAML is much improved compared to the Ruby of Chef. The agentless nature is incredibly convenient for managing systems quickly, and if a member of your term has no terminal experience whatsoever they can still use the UI.
There is a lot of good documentation that Ansible and Red Hat provide which should help get someone started with making Ansible useful. But once you get to more complicated scenarios, you will benefit from learning from others. I have not used Red Hat support for work with Ansible, but many of the online resources are helpful.
I would give it this rating because we have had no major issues with the support for ServiceNow after we implemented it at our organization. They seem to respond promptly and efficiently if we ever do need to open a support case with them about an issue we are having.
To type in what should be a text box, you have to click an empty cell, a tiny text box pop up opens with a check box and an X. You the. Type in the text box and have to click the check mark. If you have a bunch of fields to fill out, doing this is very annoying. Absolutely know thought went in to this. I'm sure somebody in marketing thought it was a good idea. It wasn't.
Without exception, every client I have worked with has been very happy with their resulting product. While this is partly due to my work, I must point out that the platform is the winning decision, not the implementer.
I haven't thought of any right now other than just doing our own home-brewed shell scripts. Command line scripts. And how does this compare? It's light years ahead, especially with the ability to share credentials without giving the person the actual credentials. You can delegate that within, I guess what used to be called Ansible Tower, which is now the Ansible Automation platform. It lets you share, I can give you the keys without you being able to see the keys. It's great
We used to use Jira to handle service tickets but it's way too robust for something this straightforward. Due to the nature of Jira, you needed to already have a lot of documentation and knowledge about who should be assigned the ticket, so the lift of creating a ticket was time consuming.
Overall ServiceNow has a positive impact on getting the SLA of tickets down in supporting our customers.
One negative impact has been the amount of time to get the product to produce an ROI, it's almost too big to fail and too big to replace. You almost become committed to the product. Good or bad.
Another negative impact would be if you track metrics of employees and time tracking, there is a lot of scenarios where engineers will track time on tickets but not get credit for closing them as the assignee function of tickets can only be tied to one user and credits only the engineer who closes the ticket.
Another positive impact would be the level of security for permissions and scaling the workloads is robust and you will get out of the system what your team is willing to put in.
