Apica Synthetic alternatives and competitors

Our primary use case is for monitoring. We've got a number of auto finance applications and hosted applications that my teams are supporting. Apica offers outside-in visibility of what a user would experience if they were actually logging into the platform. We noticed that we were missing that outside component. We had a lot of internal monitoring in place for making sure that the user experience was good, but when it came to being able to support our users and report back on issues our users might be experiencing, and work to remediate or identify and resolve issues that our users may be experiencing from the open internet connection that they've got into our hosted environment, it was just not sufficient. So Apica is what we're using that for today to actually give us an outside-in view of what the end-user would actually experience from the beginning to the end and from their overall use case experience for our hosted applications. 

We also use it to monitor the internal service platforms that we use to support our infrastructure, support our environments, and support our internal clients. We use it for monitoring port status and service statuses associated with network-based applications like FTP file transfer platforms, MQ platforms, shared services, SOA platforms, and a number of other internal platforms that we utilize the shared services across our application stacks to serve the service of our clients.

It gives us a clear line of sight into when we're actually having an external network event that's impacting our end users. Previously to implementing Apica, we would have to rely on our end users to tell us, "Hey, we can't get into the website." With Apica and regional monitoring that we have set up in our higher profile application stacks, we're able to tell if we've got a regional network issue, a national network issue, or some other network event that's occurring that may be an internal network issue that's being exposed as a manifestation of user login failures across our application stack. We didn't have that line of sight prior to implementing Apica and so it's really helpful there.

The other thing that it helps with, that is an indirect benefit of doing URL based monitoring with these types of frameworks is that we've actually caught a few expired certificates and we've also caught encryption changes that have impacted our users' ability to access the environment that maybe some service provider downstream to us has changed.

Prior to having Apica, we never really had a clear line of sight into either of those things, other than some automation that we had internally that were basically report based, and they weren't driven off of real-time data like Apica provides. When your cert expires, Apica comes back with an alert saying, "Hey, my check has failed. And the reason my check has failed is that I can't establish an SSL connection because the cert is invalid." That's a great benefit to reap from having that framework in place that wasn't anything that we ever thought of during the time that we were implementing it. Those things are really nice to have.

It's too early for me to actually give a definitive answer on whether or not it had addressed Edge because we haven't been able to build out sufficiently complex user scenarios in our synthetic monitoring areas with Apica. But from what we have set up, it will definitely give us more insight when we're dealing with a complex infrastructure-based failure event scenario. It gives us more insight as to where specific failures are occurring, because it's giving us a lot more data back that gives us detail into where the user experience is actually not functioning. From the diagnostic data that the synthetics that we do have set up from that diagnostic data that we get back because we have an incredibly complex application infrastructure and architecture for some of our apps, we are able to quickly narrow down where within that infrastructure we're actually having a problem with that diagnostic data from the synthetic logs that we get back from the alerts. I would say it does, but we don't really have really deep synthetics setup to the point where I can go to regression test my entire application stack for one of my apps. I just can't do that yet, but it's definitely something that we have in our roadmap of to-dos.

The fact that Apica offers multiple deployment options, like on-premise, hybrid, and managed cloud solutions definitely helps my company meet our security requirements. Some of the internal texts that we need to do require us to have on-premise infrastructure components. Having a hybrid option is definitely helpful. I think the other piece to that is the flexibility to be able to go entirely cloud with Apica is incredibly beneficial because then you get access to regions all around the world that you have a line of sight from that can help you with getting visibility into what's happening from a client use case perspective. For example, if I have a lot of clients in Canada because we do have application products in Canada, I could, in theory, have an Apica presence in a Canadian region that will give me a localized view of what the user experience is like in conjunction with other regional views to help me narrow down when I am seeing a problem; if it's a regional issue or if it's something that's more global in nature. That actually is usually beneficial for us.

We use its ability to use our own scripts. What we use Apica for right now has primarily been based on the importing of Selenium Flames groups that we've developed for mimicking our user transactions. We've also been working on utilizing their automation platform by a ZebraTester and we've been learning how to work with that so that we're still in the early stages with it. But we've been seeing a lot of additional potential from that ZebraTester framework as well. LoadRunner is something that we've been talking about but we haven't really explored that at this point in time.

What we've developed in Selenium is that we've been able to easily convert over into the native Apica workflow stuff for the synthetics that we have configured. Once those Selenium scripts are created, you use it once, and then it's in Apica. The results have been fantastic from that standpoint and the simplicity of being able to use something that's common and standard across the industry, in terms of using system Selenium to create your synthetic transaction scenario, makes it really easy and helpful to actually get into the platform and a little bit more of an in-depth way versus having to learn an entirely different scripting language or having to learn something new in order to do those types of things.

It's hard to say whether or not this scripting feature has saved us money or resources. Because of that flexibility, more people have been able to access that component than normally would be able to. From that standpoint, it has increased our adoption rate. It hasn't necessarily improved outside of that, but with an increased adoption rate, because it's easier to implement and easier to use by more people, we're getting more value out of the framework without having to have dedicated script or dedicated people writing automation for it. 

From our standpoint, there are a number of valuable features. The WebHooks are obviously really great. The alert framework is really good and then the reporting and visualizations that you get from the dashboards are good. Those three areas are primarily what my team's focused on in terms of usage from day to day.

The dashboard view tells you the health of the services that we have monitored, and how the health of the entire infrastructure is doing at a glance. My teams have given me a lot of good feedback that I just keep the dashboard up on my workstation during the day, and if we get an alert, I can immediately go and investigate if I'm in the dashboard. I can also sometimes catch an event as it's occurring so save myself a little bit of time and be able to get in and see what's going on more quickly as a result of that. From the alerting standpoint, that in conjunction with the dashboards that you get, really compliment each other because then you can drill down and actually get into what's happening from a transactional standpoint or transactional perspective, and see where within the transactions that we're monitoring, where what steps are failing, get more details on why those steps are failing and work to mitigate and resolve those issues based on that.

It's that visualization component that really ties everything together and the drill-down capabilities that you get starting from the dashboard that really makes Apica very useful from a day to day support standpoint.

There are a lot of capabilities that we're not really taking advantage of that we could. There are a lot of opportunities to grow in terms of how we're using the framework, especially when it comes to doing things that are more complex, like facilitating deeper checks via multi-protocol based scenarios that tie in with ZebraTester automations that get created or more advanced regression-based scenarios that we might want to set up in the synthetic checks. We're using around a third of all the capabilities that we have available to us so we definitely have a lot of room in terms of what Apica offers for growth and for expansion of our use cases.

The alerting is impressive. 98% of every alert I see come out of Apica is a valid alert. The other 2% of the time, we will get an alert or something will not be right which is because we overloaded our Apica infrastructure with something that we were doing. It was a self-inflicted thing. If you actually remove that from the equation, what you're really talking about is that it's nearly a 100% success ratio of events to real events. 

It's been fantastically accurate at identifying events. The sometimes frustrating part of that is convincing other people that what we're actually seeing, coming out of Apica is a real issue and it needs to be addressed because a lot of times people will just not be convinced by the data that they're seeing until well after the fact. As we've been using the platform more and more, there are more teams out there that are understanding that when a team member brings something up from Apica, it's not to be taken lightly.

From my perspective, I would say it has saved us costs involved in monitoring. It's enabled my resources to work more focused. It's enabled them to work more accurately. It's enabled them to work more authoritatively and it enabled them to work more adeptly. From an operational standpoint, I would say that it's at least improved our monitoring efficiency by 5% to 10%.

Having to install an application on your desktop to utilize something like ZebraTester is a little cumbersome. It would be nice to see that become a web-based application. 

Having the documentation a little more accessible, and easier to digest by people who are just learning how to use the framework, especially when it comes to more complex or more edge-based cases would be really helpful to have. That is really it, but I think the other thing that would be really nice to have, and it's not necessarily a big downside is when the browser agents need to be upgraded, it would be nice if that just happened automatically and it was transparent and seamless to us and to our infrastructure.

We started using Apica around two years ago. 

It's very stable. We don't ever see any issues with it.

It scales well.

We have about 200 technical users and they're mainly technical support application development and infrastructure support teams.

We have a couple of dedicated resources for deployment and maintenance. Obviously, they share responsibilities across different application stacks, but we do have resources available. They're a monitoring infrastructure support team.

We have 200 users. We have 100 Synthetic and another 100 regular licenses, and we've got a lot of room to grow so that we plan on increasing usage quite a bit over the next couple of years.

The initial setup was moderate. We have a moderately complex setup here in LA.

It was moderately complex because we've got the hybridized infrastructure for Apica. If we were entirely cloud-based, we would probably be a little more straightforward and simplified. But because we're using both on-premise and the cloud infrastructure, it just makes it a little more complex.

We've got a number of groups that we've got a center of excellence basically. The center of excellence is helping teams by enabling their use of the platform.

We used their support during our migration. The vendor engagement with Apica is second to none. I've worked with some really big companies out there and I have been seriously impressed with our technical account team, with our support teams, and with our account executives for Apica. They are great partners to us and they listen and they help and they try to help, and they're just a fantastic group to work with.

The level of support reduced the time and costs involved with switching. It also is an ongoing, continual improvement type of strategy. It helps us to implement new solutions more quickly because they're accessible and again, always there to help so it's great.

They anticipated our needs during deployment. The adoption rate has been a little bit slower than what they were anticipating, but that's no fault of theirs.

I'd say it took us a good six months just to get everything set up the way that we wanted it.

We have absolutely seen ROI. The percentage of time saved that we've gotten from this platform has been helpful. That translates itself into client success stories as well.

It would be nice to see them have an enterprise license where an enterprise can just buy unlimited.

Professional services are at an additional cost, but it's very fair.

We also evaluated AppDynamics. 

I would highly encourage organizations that have external applications, web-based applications to definitely consider this platform if they're looking for something to give them an end to end view in the overall user experience.

Having that outside-in view, you don't really think about it at the time when you don't have it. But once you actually have that outside-in view, that really gives you that same context that the end-user has. It's kind of surprising how much more you actually learn about things that aren't necessarily within the infrastructure that might impact your clients and potentially impact us so it's been very revealing.

I would rate Apica a seven out of ten. 

Apica is used to perform availability checks of our IT services. We put what we call synthetic checks in place, and these are mainly used to check if a specific application is running correctly, or if it is not available.

Because it is a platform that allows us to check the availability of our services, we have a process in our company that allows us to open an incident when we receive an alert that is raised by Apica. It is really critical in our company to have a tool like Apica, because every time we have an alert we know that there's a real problem in our system and we can forward the problem to our internal team so that they can take charge of the problem and solve it as soon as possible.

We are very satisfied with the flexibility that is offered by Apica. In our opinion it is much greater than in other products, even more expensive products. We found a good balance between the cost, after our spending review, and the features that it offers. The alerting is very reactive as well as very accurate. We are really confident in the alerts that we receive from Apica. The alerting accuracy has absolutely saved us time because we can minimize false positives and that means that we don't have to spend the time dealing with them. On a monthly basis it is saving us about 20 hours of work. That is the amount of work we did on false positives that we received before adopting Apica. That might seem like a low number, but trust me, when we have a critical issue, 24 hours are a lot.

We decided to move from another provider to Apica because it offers, from our perspective, more features and more advanced use case coverage. For example, it has a feature that allows us to set up business logic on the availability of our services. We can apply multiple criteria to trigger an alert. We have availability checks that allow us to check two different services at the same time and, to trigger an alert, both of them have to be down. One of the very difficult things with this kind of product is the possibility of false positives. Thanks to the flexibility that Apica provides, we are able to minimize the false positives, and that means that when we take charge of a problem opened by Apica, we are very confident that it is a real problem.

We are also using some JMeter scripts. At the moment, the platform itself is not using JMeter scripts, but they provide a converter that allows you to convert a Jmeter script into another language called ZebraTester. Thanks to that, we are using our JMeter scripts without any problems. And that means we can implement automation in the scripting and, obviously, that adds up to spending less time and effort on these automated activities. It's quite critical to have a tool that provides you this kind of automation. Apica also provides public APIs that allow us to run these kinds of scripts on demand. That is a good thing when you have to develop some automation to achieve very specific needs and tasks that are very frequently executed.

Overall, Apica has definitely saved us costs involved in managing monitoring, although I can't put a number on it.

There are several features that are really good. The first one is the flexibility and the advanced configuration that Apica offers when it comes to configuring synthetic checks. It provides the ability to customize how the check should be performed and it is very flexible in the number of synthetic locations that it can use. It allows us to run scripts from different locations all over the world, and they have a really good number of these locations.

There is also the ease of use. The user interface it provides is really advanced, but at the same time, it is really easy to use. That's a really good feature when it comes to daily use and our daily processes on the platform.

It is also very good in terms of the range of protocols it can monitor. Even if, at the moment, we are only using the HTTP protocol and browser synthetic checks—it's mainly the emulation of the end user browser—they also provide other protocols, such as DNS verification.

The first thing that I would suggest they improve is the user interface. Not from the point of view of how to access the features, but how they are presented. The user interface is very clear, but there are some components of the user interface that are not up to date. Just to give you an idea, today we have web applications that are called single-page applications that are much faster than the old style of web application. If we can move faster into the flow of the graphic user interface, and in a more effective way, it will save us a lot of time.

Another feature they can improve is related to how easy it is to set up what they call on-premises locations. Apica offers locations all over the world, but they also offer a manual to install a location on-premises to check the availability of services that are not public. This process, at the moment, is not so easy to achieve. The last time we did it, we were forced to contact their support to set it up. The automation of this kind of setup is not good. It should be something that does not require human involvement to follow the deployment. The possibility of being totally independent in installing and using an on-premises location would be much better.

I've been using Apica Synthetic for about one year.

The stability is absolutely excellent. We haven't had any issues so far. And when there was some kind of unavailability of the service, because no software is perfect, they advised us before or, if not before, as soon as possible, to let us know about the problem. This is definitely a good approach since if you tell us the platform is under maintenance for a problem, we can change our internal processes to take the unavailability into account.

It's very flexible in terms of scalability. At the moment we have about 2,000 scripts running on the platform without any problem. It's absolutely critical, since we are quite a big company, and moving from a software that is quite famous—because CA Technologies is a famous vendor—to another vendor, Apica, that is smaller, could be a risk. But after the PoC, we really trusted the Apica product. We are very happy that the platform is reliable and very scalable.

We used CA Nimsoft Monitor and Dynatrace Synthetic.

We were migrating from another product to Apica, so the main task that we performed was to migrate all the scripts that we were using on the old platform to the new one. We were able to do that thanks to the professional services support that Apica provided us. They offered us exceptional help in performing this task. It was mostly implemented using the APIs that Apica offers, since migrating data from a platform to another one requires some automation. You couldn't think about doing it manually. The Apica platform was made ready for our use cases because they provided the API that we needed to perform the migration.

The second task that I performed internally was to let the company know about the new processes to be implemented using Apica. The technology is the "engine," but then you need to build the "car" around the engine. That meant we needed to develop processes to let the people who were interested in using the platform know how to do so.

In summary, the first technical task was to migrate all the scripts from the old solution to the new one and the second step was to develop new processes, based on how Apica works.

Overall, our deployment took one year. But the level of support we received from Apica during our deployment helped reduce the time and costs involved in switching to their product. Without them, it would have taken double the time. Thanks to them, the time needed was reduced by a factor of half. They anticipated our needs, meaning that every time we asked them something specific, they replied right away, "We can do that. Don't worry."

It's not possible to provide ROI numbers for a simple reason. Last year we only performed the migration of the platform from CA to the new platform, so we have only been using Apica officially starting this year. We need more time to collect this kind of number. But the perception that we have after the assessment that we performed at the very beginning, is that it will halve our cost and double the performance of the processes that are related to the adoption of Apica.

We checked the new Dynatrace Synthetic platform. We decided to dismiss that and move to Apica after we performed the PoC, since we found that Apica was much more flexible than Dynatrace Synthetic.

Another main difference between Apica and the other products was the cost. We really thought that the balance in Apica between the features and costs was the best among all the products on which we did a PoC. 

There is also the support and the innovation that they bring. One of the reasons we decided to leave CA and Dynatrace is that they are bigger companies, but they are slower when it comes to solving a problem or when it comes to implementing a feature that we request. Apica is smaller, but being smaller means that you are even more flexible and more available when it comes to solving a problem. For example, Apica provided us with a totally new feature that we requested, before we moved to them. That feature was not in the Apica platform and it was critical for us. In about one month, they were able to develop that specific feature for us.

If you are looking for a product that offers a huge technology modernization, and quick support, you should take Apica into consideration, for sure. It is a small company compared to others, but they are really quick in answering your needs and providing you modern technology. If your company is growing and is looking to add new monitoring that is up to date, I would warmly suggest Apica.

We decided to use the SaaS version because we are trying to change the model of services that we are using in our company. We are trying to minimize the on-premises products because we don't want to be in charge of the management of the infrastructure of things that are on-premises. We are absolutely confident that Apica respects our security needs and that we can use Apica safely.