What is our primary use case?
We have it deployed in our cloud Azure VM environment. So, we have it physically installed on our servers, but it is a cloud deployment.
How has it helped my organization?
There are a number of different checks that it does. The first thing that it will do is try to connect to the agents. For example, if an agent machine isn't there and isn't available, the way we have everything set up is that the first job will fail. However, if you have a series of jobs with dependency, succession, then you can set it up so it will prevent the other jobs from running. This way, it is not running things out of order or running things without a job where all the other jobs are dependent upon the first job running successfully. There are a number of different ways that you can set that up within JAMS. We definitely use some of the more simplistic ones since that is what works.
We don't need enormously complex workflows in the system, and the main functionality within JAMS is really what works for us. We have found that trying to keep it simple, not making things overly complex, within our job scheduling and configuration has worked best for us. If it isn't broken, don't fix it.
It makes everything that we want to do so much easier. We have had a number of instances in the past where we have had developers who have been working on a project, and even though we have had JAMS for all these years, they will create some SQL Server Agent job, or something like that, to run a task. When it is in code review and development is complete, the question always comes around, "Can JAMS do this?" The answer has always been, "Yes." Pretty much anything we have ever developed could be run by JAMS.
Our operations team who manages JAMS picks the project up, puts the jobs in, and starts running them. Whether it is the developer or some other resources somewhere else in the company, they want to be kept in the loop on the processing of those jobs. We can use the built-in JAMS alerting to keep them up to date. They can be alerted only when there is an error. Or, they can get an alert anytime the job runs so they know whether it was successful or failed. Over the years, there has been a greater adoption of people coming to us, saying, "Hey, can I run this in JAMS?" Instead of them going off and creating it on their own.
Its Interactive Agents are critically important for running jobs on all our various servers. If we didn't have that, we would have to do something individually on each of those different servers, trying to time everything out. It would be nearly impossible.
What is most valuable?
The most valuable feature is the basic core of the software itself. That is just the level at which you can set scheduling and dependencies between jobs, how everything can be set and scheduled based off of one another, and the ability to run jobs across 25 to 30 different virtual machines. It gives the ability to be able to run jobs on all those servers as well as have them all be visible. In the schedule from one centralized JAMS client location, we can bring up the client interface and see everything that runs across our entire infrastructure, which is really invaluable. We can instantly access all the log files for anything that happens, e.g., if we get any job errors. That is definitely what is most valuable to us.
There are some different batch queue features, e.g., we can quickly change the servers where jobs are running. When we made a full move to Azure to be fully cloud based, we had to change all our jobs and the servers that they were going to be running on. The way it had been originally set up was that we used batch queues, where each job would run on a particular server and it would be assigned to the queue, which had the agent definition in it. That told it what server to run on, which was very easy. We didn't have to go through and change thousands of jobs. We only had to go through and change about 20 to 25 different queues, then just point them at different servers. Therefore, it was a very quick and easy change.
We have used some of the built-in PowerShell FTP capabilities within JAMS as well as some of the other PowerShell capabilities. We also use the triggers a little bit, when we are watching for files to appear in a particular directory, etc.
The exception alerting process is reliable; it works. We don't do anything really fancy with it, and it is mostly based on the actual jobs themselves. For example, if an SQL job, some Windows executable, or an SSIS package that we're running returns an error exit code, JAMS certainly handles that and lets us know. It then does, with the rest of the job surrounding it, what we have configured it to do. From that perspective, it is great.
We have some specific instances where if jobs run too quickly or take too long to run, we use the exception alerting process on probably a few dozen different jobs that we have that are really important. The few times that it happened. It has saved us a lot of headaches because it is able to report those exceptions to us.
We use a fairly decent amount of the log file exceptions, where you can go in and parse the JAMS job log file for specific entries as it goes through. Then, it can actually error the job out for a job that otherwise might not end in an error. In our case, we wanted to be alerted and have it halt a process if some specific text string shows up in the job log. We have that set up on a number of different jobs, which saves us from a lot of headaches.
It has worked out pretty well for helping us handle complex scheduling requirements. We use it in one specific instance where our customers interact with our web-based platform. It has a section where our customers can go in and run one-off versions of their specific processes. So, they will go in and upload a new file, then they want to basically process that file into the system. What they can do is go to the page, upload their file, and then there is a button there that allows them to process it. That button actually links directly into our JAMS server using the JAMS APIs. That will kick off the jobs within JAMS directly. We have it set up so it only allows it to run it during certain times a day. It can check and monitor to see if an instance of a job is already running for that client. If it is, it returns back and tells them that they need to wait for the current one to finish. It returns the actual history from JAMS so they can see all the previous instances of their jobs that have run. This is a really nice feature that our customers really appreciate. It also saves us a lot of time. What would happen in the first couple years before we implemented this, our customers would upload their file, but then they would send in a support ticket for us to run their processes during the day and all our customer processing happens mostly overnight. Therefore, they would want this intraday update of the process. As soon as we implemented this for all of our clients, those support tickets just disappeared. It made a big difference in our ability to support customers.
What needs improvement?
I would like the ability to have the JAMS client, where we monitor everything, be fully web-based and secured so only certain people can access it. It should be set up and look similar to the actual JAMS client that we use as a desktop application on the server. A fully web-based JAMS would be nice for traveling or when you are not able to directly access the actual server with the client when we want to log in.
All my machines at work are Macs. JAMS client is a Windows-based thing. It is all built on .NET, which makes perfect sense. However, that means in order for me to access it, I need to connect to a VPN, then log onto one of our Azure VMs in order to access the JAMS client. This is fine, but if for some reason I am unable to do so, it would be nice to be able to have a web-based JAMS client that has all the exact same functionality in it. There are probably a whole bunch of disadvantages that you would get with that as well, but that is definitely something that would make life easier in a few cases.
For how long have I used the solution?
We have been a JAMS user since late 2013.
What do I think about the stability of the solution?
It has been incredibly stable over the last nine years.
The only issues were few and far between. They baked more down to Windows than JAMS, but that is just how JAMS interacts with Windows, and you will get an instance where a JAMS agent will stop responding. I have probably had that 10 to 15 times total over a nine-year period. It is really more about the Windows VM needing to be restarted. It was something in the Windows network that was out of sync, so it wasn't JAMS causing the issue.
We had no downtime at all for the complete movement of an entire environment, which was great.
What do I think about the scalability of the solution?
The scalability is fantastic. We have never had any issues. We went from a couple hundred jobs to running 6,000 to 7,000 jobs per day now without issues whatsoever. It is extremely easy to use. I feel like if we had the manpower to put all the jobs in and stay on top of them, we could run 60,000 jobs a day through it without any issue. The scalability is more about the server environment that you are putting JAMS on rather than JAMS itself.
Right now, we have two people whose main responsibilities are managing JAMS. That is for new jobs, job updates, looking at job errors, monitoring, etc. Then, we have two to three other people who work in some siloed areas, so they manage their own jobs, i.e., creating their own jobs when they go in. They are still monitored by the main team of two, but there are a few other people who manage it. Within our company, we have about 115 employees. We have about four to five people who regularly interact with JAMS, with two of those being on a daily basis.
How are customer service and support?
I haven't had to use the technical support that much, which I think is a testament to the product itself. However, anytime we have had questions, such as, "Hey, can we do this with our license?" or, "What is the recommended upgrade path if we want to do it this particular way?" They have always been very quick and helpful, emailing back right away, having a phone call, or a video screen share call with us. They give us lots of options. Over the years, we have probably used it less than a dozen times, but every time has been a really good experience. I would rate them as 10 out of 10.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
It didn't really replace anything.
When I first started with Powwr, everything was being run manually, being done through Windows Task Scheduler jobs, or SQL agent jobs. It quickly became apparent that this would not be scalable. It didn't really give us what we needed, as far as visibility into jobs.
I previously worked for another company who owned and developed JAMS, so I knew of it. I reached out to them, and said "Hey, we really could use the solution here." Then, we signed up, got our licenses, and were underway. At that point, we were running about a couple hundred jobs per day. Now, nine years or so later, we are running somewhere between 6,000 to 7,000 jobs per day through JAMS. That is across multiple different servers and platforms. This allows us to keep everything in a single centralized management area where we can have different jobs running based off of ones running on other servers, platforms, and types. It has been really helpful.
How was the initial setup?
For the initial deployment back in 2013, when we first started, we had one main JAMS client server. At that point, we probably only had four or five other agent servers where we were running jobs. That deployment of the software took a matter of an hour or two. It was very quick and easy. Then, we spent the next month or so getting it set up to create all our jobs within it, really figuring out exactly how we wanted to run everything and trying to make it as efficient as possible. Also, we want to be able to make it so we could do the changes, e.g., if we were moving server environments or changing agent servers. We wanted to make it easy to do that.
We did take a little bit of time with planning and setup, but the actual deployment of the software was very quick. Even over the years, when we added a new server to run jobs on, it was really simple. When we do our server deployments, we make sure that the correct firewall ports and everything are open for JAMS. This is part of our standard VM deployment process. We then just use the automatic JAMS agent deployment feature. Therefore, we add an agent and it automatically deploys. About 30 seconds later, it was done.
We deploy the agents to all the remote servers that we have within our infrastructure. Therefore, once the deployment goes out, we are able to run any of our jobs. The biggest advantage that we have gained from this is being able to tie together jobs from our multiple different servers, allowing them to essentially interact with each other through the JAMS agents. For example, we have a process that has a dozen jobs in it and the first two jobs run on one server, then the next six jobs run on another server, and the last four jobs run on a third server. This makes up a larger process that completes some goals for us.
We can take the jobs that we run and write tables. The next job can pick up data from that, even though it is running on a completely separate server. They are all tied together from dependencies, so it makes sure that the right ones run in the right order, even though they are running on different servers. They don't even need to be in our environment.
We have jobs that we can run outside of our main Azure environment and can run on ones that are halfway around the world, as our company has a US portion and a UK portion. Therefore, we can run job processes where some of the jobs run on servers in the US and some run on servers over in the UK. As far as JAMS is concerned, it is just running the jobs. However, it is a big plus for us because we can keep everything linked together.
What was our ROI?
Back in 2013, I was the only user of JAMS. We had maybe 10 people in our company at the time, as we were just starting out. Just implementing JAMS on a smaller scale saved me probably five to six hours per day of work. That was massively significant. I was able to sleep at night. Getting JAMS in place was a game changer for us back then. As we have grown from 10 employees to 115 employees over the last nine years, JAMS has grown with us in how we use it and what we use it for.
What's my experience with pricing, setup cost, and licensing?
The pricing is very fair. We have seen very minimal to no price increases over the years. We are not banging down the door of support all the time either. I would imagine if we were a company that submitted a dozen support tickets a week for the last nine years, then it might be a little different because we would be eating up everybody's time. However, for what we get out of it, the pricing is extremely fair. Back when we were originally looking and brought in JAMS, we were looking at a couple of the other competitive products that were in this space, but the pricing from JAMS was far and away better than what the other competitors could offer for the same functionality.
Which other solutions did I evaluate?
From my perspective, we went straight for JAMS. However, from the company's perspective at that time, they wanted to look into a couple of other competitive products. So, we did do a little bit of that.
We chose JAMS because it could be very easily integrated into our existing environment. We were completely Windows-based. We were doing a lot of .NET development. It just fit very well. Though I am unsure, it may still be the only .NET-based scheduler out there. To have this capability was really a big plus.
Some of the other competitive products had a much steeper learning curve. We were able to take some of our employees that had never seen it before, and within a matter of minutes with some quick training, they could get in there, create new jobs, and get things running.
What other advice do I have?
For a while, we had a secondary environment set up where we would run various test jobs. Or, if we were testing out software updates, like JAMS software updates, we would run that environment as well.
I would rate it as 10 out of 10. I would definitely not hesitate to recommend it and have recommended it.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Thanks for the 5-star review of JAMS! It's great to see you're enjoying the stability and scalability of JAMS over the past 5 years. Also, thanks for your feedback on creating more documentation and/or information guides on how to create custom execution methods. I have shared this information with our product team. If interested, we have a customer community, Automation Insiders, for current customers to share experiences and ideas on all types of topics. This may be a great place to start. If you ever find you need any assistance, please do not hesitate to reach out as we are always at your disposal. Thank you again!