AppNeta by Broadcom Reviews

Most of the time, we use it for testing the performance of networks for voice and video. It's not designed to be exclusively that, but that's what we use it for most of the time because network performance for the voice and video is notoriously difficult to monitor and manage.

We've built a business around AppNeta because in the early days, it was, and it still is, a unique tool in the way it operates, and we do a lot of consulting work for much bigger companies. Most of our work comes from a company into video and voice solutions, but we have done a lot of work with other ISPs. Essentially, we've built the business around what AppNeta can do.

It works well for visibility into the internet and cloud environments. AppNeta works from a source probe, and it sends a low bandwidth stream of traffic to a target. If the target is not another probe, it has to use ICMP. One slight difficulty is that a lot of the cloud vendors don't allow ICMP into their cloud infrastructure. The way around that is to install a software probe in the cloud. So, AppNeta has installed software probes in nearly every Microsoft Azure location, and those probes are publicly accessible, which means we can reach them by using a different protocol. If we need to test somewhere that's not Azure, such as Amazon Web Services or Google, then we would need to install a software probe in the cloud. So, it's one more step than we've had to use in the past, but that's because of what cloud providers will allow and will not allow into their data centers.

In terms of active and passive monitoring for alerting us to the deterioration of digital experiences before users are impacted, the delivery side is always active because that's the way it works. The passive side is used to monitor the operational traffic that's on the network. It works fine, but we don't use it very much because there are always security implications. So, we only use the active side of the tool. The passive side looks at the operational traffic that's already on the network, which can become tricky security-wise because when you do that, you are able to see all of the traffic unless it's encrypted. We don't tend to use that. We have used it, and it's useful to work out notifications and alerting. From the active side, we can see if the utilization is high, but we can't tell what's causing the high utilization. If we can get security authorization, we can use the passive side to find out which applications are using all the bandwidth. Typically, we're mostly focused on the active side of the testing, and the alerting and the notifications are very useful.

We use the Automatic User Geo-Location feature. It happens automatically. It's not something that you can turn on or off. We do use it, but I'm always a little concerned about how accurate it might be. That has nothing to do with AppNeta. For example, if I try to find out where my home broadband is, quite often, it'll show me in London, whereas actually, I live 80 miles away from London. It's just where the IP address is logged. We do use it, but we use it cautiously. It's good for the remote workforce. We've done a lot of troubleshooting work for people working from home. Over the last couple of years, so many people have started working from home, and they've had to rely on commercial broadband rather than business broadband. Often, people have no experience in networking or troubleshooting. We're able to get them a software agent that can be installed on their machine, and then once it's on, we just remotely manage it from a central location. So, once a user has installed the probe, which is no more difficult than any other Windows or Mac application, they don't have to do anything else. We take it over from there. When AppNeta first brought the licensing out for working-from-home pros, it included 25 agents, and recently, they pulled that up to 50 agents. It's pretty useful. For the price of one standard license, you get 50 agents that you can either put in for people working from home, or you can put them in a branch office as if it was a hardware probe. We found it to be very flexible for that purpose.

In terms of ease of using the Automatic User Geo-Location feature to determine if a problem is user-specific or region-specific, it depends on how many agents are around. We do know what the ISP is because it automatically tells us the ISP, as well as the geolocation. If we see people in similar locations and they're having problems with the same ISP, we can pin that down to an ISP problem. It's a question of comparing and contrasting what all the users are doing, but the end-to-end thing is, AppNeta already has a system to work out where a problem might be, whether it's at the local end with the user, or at the remote destination end, or somewhere in between. It always has that ability. There's a combination of ways to find out where a problem might be getting caused and who's causing it and why.

It's very good for our Mean Time to Identify (MTTI) for performance issues across business-critical apps, locations, and users. Obviously, when you're dealing with an end-to-end path, the devices and the connections are not all owned by the same people. The local part of the network is owned by the customer or a third party. There may be one or more ISPs, and there might be an ISP at the local end and a different ISP at the remote end because we work globally. So, we may be testing between the US and the Far East, or with the UK and South Africa. There's always at least one telco, and normally, more than one telco. Although we can pinpoint the problem and find out who owns it, it doesn't mean we can fix it fast because it all depends on other third parties accepting what we say and getting on and fixing it for themselves. However, normally, if there's a problem that lasts more than, for example, 10 minutes, we pretty much know exactly where the problem is.

It hasn't had much effect on our mean time to resolve (MTTR) because we're not normally in a position to resolve it. We're all pretty much external consultants. We can explain to people where the problem is, but we don't have direct relationships with telcos, where we can instruct them to go and do this. The MTTR for a problem is a bit unpredictable, but that doesn't have anything to do with AppNeta. That has to do with convincing the person or the organization that owns the problem area to get on and fix it.

We have seen a reduction in open tickets using AppNeta. Before people used AppNeta, they didn't have a reliable method to find out where the problem was. Sometimes, when we work for a particular client, a problem ticket has been open for a month because the problem is periodic, and it is unpredictable when it happens. When it does happen, they don't have the right tool in place to monitor it, and then we come in and install AppNeta, and generally, we can get that ticket closed within a few days of us becoming involved. So, we often find that problem tickets have been open and unresolved for quite some time, and then we come in and put AppNeta in, and typically, we can get that ticket closed within a few days. It's just a matter of how quickly the people involve us in the problem. If we were involved right from the beginning, I'm pretty confident that it would definitely result in tickets getting closed earlier. Sometimes, tickets are getting closed within minutes because we've done our bit and we've said what the problem is and where the problem is. There's not really any point in holding the ticket open any longer because the resolution is up to some other third party like ISP or telco.

We primarily use the solution for general network performance. We used the solution in a large retail organization. I've used it to prove my infrastructure and have installed virtual and physical probes. Firewalls need to be open so the probes can gather information. Then, the data is placed in one aggregation point, and we look at the data from there in its totality. 

We also use it for load testing in order to discover the latency tolerance for upgrading environments or moving to cloud space. 

We invested heavily in IT infrastructure and have used this to QA the network infrastructure prior to standing up a new environment. We're focused on resiliency, performance, and latency. 

I was brought in to set up a new environment for an enterprise-grade organization, and AppNeta was employed for two purposes. One was to prove the infrastructure because the mandate from the executive is that we had to ensure our performance was the same if not better than existing.

Second, it was used to assist the performance testing of an enterprise-level application and where we would actually take the probe and tool. We could introduce environmental burdens on the environment to see how the application would operate with those burdens while doing load testing simultaneously. Although, that was using another tool called HP LoadRunner.

Another improvement is that we can isolate performance issues using AppNeta very quickly, in as little as a few hours.

The solution has allowed us to establish a baseline that is quantifiable. When you take the load and move it to another location, this solution is going to tell you exactly what's happening on an infrastructure level. This way, you don't have to focus on the infrastructure and can focus instead on the code itself and the application performance.

This solution helps prove that if we move to the cloud, we'll still be as effective as we are on-premises.  

It's proving the infrastructure, but more importantly, it offers the ability to discuss multidisciplinary issues with the health of the environment that goes up from the infrastructure and up through our transport layer into our presentation layer. A lot of times the individuals will have very narrow perspectives based on their role in our organization. This helps bridge the gap in communications through reporting and facts that we can sit down and look at.

When I actually take the load and I start moving it around then I see a reduction in opening tickets by 70-80%. I normally am the one who recommends it, and I introduce it to give myself a fighting chance to make sure we minimize the impact on operations.

It's critical because people don't spend a lot of lost time. It gets them focused, and the meantime to resolution is decreased. There are also fewer tickets open because we actually understand where the problem lies. It provides visibility to that.

We have a couple of data centers and clouds, and we have our retail campuses as well as supply chain and distribution centers. We use AppNeta in all these locations to check the connectivity and performance between the locations. That's a major use case that we have.

We have a public cloud and on-premises setup. 

Its benefits have been in terms of alerting and monitoring. That's pretty much what this tool is supposed to do, and that's what it's doing.

It's pretty good in terms of visibility. It has been pretty helpful. A couple of times when users were complaining about the issues, I was able to find or share the facts and say, "It's not the network. It's something else above in the food chain." That's where it was a lot helpful.

We use active monitoring but not to the level that I want to. We are still in a transformation phase, but passive monitoring works the way it should. It's pretty straightforward. Whenever someone complains, we pretty much go into the tool and get the stats about what is there and whether it's something in the network or something up in the food chain.

It has drastically decreased the Mean Time to Identify (MTTI) for performance issues across business-critical apps, locations, and users. We didn't have a similar tool before. This is the first tool that we got. We found it and did the PoC. It has decreased our MTTI and saved 1-2 hours that our engineer used to spend checking multiple locations for any issues. The time taken to isolate a performance issue varies. If AppNeta is able to catch that right away, then it's quick. If it doesn't and if it's something that's way beyond AppNeta, it takes some time.

There are also time savings when it comes to Mean Time to Resolve (MTTR) for performance issues. AppNeta is not doing any changes to our network. So, the first thing is to find the issue, and once we find it, we can roll back or do whatever we do to fix the problem. In terms of the reduction in open tickets using AppNeta, there hasn't been any reduction because it's not doing any type of fixing of the network. It has only helped us to decrease the MTTR because we now know where to look.

Fundamentally, it is for network monitoring or user experience monitoring. We've deployed the hardware appliances all around our network environment at all of our branch office sites and even some of our larger sites. We use it to run synthetic transactions back and forth between the actual appliances, as well as some HTTP servers and other similar devices.

It is software-as-a-service. So, we are using whatever version they upgrade to.

It has helped us to see issues or problems rather than having a customer report them.

A lot of times one of the AppNeta transactions showed that there is an issue, whereas everything seemed to be working properly. Once we dug into it, we realized that it really was highlighting a problem that otherwise we would not have seen. The biggest lesson I have learned from using this solution is to always trust the tool.

My company used AppNeta by Broadcom to do voice testing on several customer sites, and we also did some data testing. Right now, my company is trying to see if the tool works within a cloud-based solution and trying to troubleshoot something that the customers are experiencing right now over the cloud with their Microsoft Teams.

In our company, the tool helps us get to where we think an issue is occurring, and we also can improve the network setup correctly for our customers with Q-SYS and similar settings.

Our main use cases are SD-WAN or a cloud migration or an application moving to SaaS. Most of our customers are moving to SaaS and cloud, and from traditional MPLS to SD-WAN networks. We want to tell our customers what the experience is like during and after the implementation of SD-WAN, or during the migration of an on-prem application to SaaS. We want to tell them what the application performance is like, or what the network performance is like. That is what we provide to customers and it is our main focus area for the product.

I am in pre-sales and, here in the Middle East, and most of our customers here do not go with SaaS. They mostly have on-prem data centers and go with SD-WAN. They connect their branch with SD-WAN and they want to know what the performance is of their SD-WAN terminals. That is the major use case in this region.

Apart from that, because most of our users are working from home, we also concentrate on providing user-experience information for any application that an end-user is using while working from home.

It helps when it comes to monitoring ISPs or SLAs undertaken by SaaS providers, to make sure that they are meeting the SLAs they have promised. IT engineers who are sitting in our office do not have access to what is happening with SaaS and cloud applications. So when a user is having issues with such an application, he will contact the internal IT team. Without AppNeta, the IT engineer cannot be sure where, exactly, the problem is because he has no access to or visibility into the network outside the office. Having AppNeta can provide a clear picture of where the problem is and the engineer can use it as proof to show the ISP or the SaaS application provider if the problem is on their side.

Before a user encounters an issue, we have the points that are being actively monitored and we are alerted from different locations. With AppNeta in place, we can check whether the issue is in one branch office or location or it is in different locations. It might be a problem on the application side. AppNeta helps us identify exactly where the problem is.

Generally, an end-user will not open a ticket the moment they see a problem. They will wait for maybe five or 10 minutes. Only once they feel that, yes, there is an issue, will they open a ticket. With the active monitoring in place, we know that there is a problem because the monitors keep checking the network every minute. Before the user experiences it and opens a ticket, we are aware of the problem and are going to fix it. When the IT team is aware of a problem that affects most users, the number of tickets is definitely going to be reduced because they know where a problem is and are fixing it before other people experience it. With AppNeta, we have seen a reduction in tickets of 15-plus percent.

In terms of MTTR, once you have identified an issue, the resolution time will depend on how quickly the engineer can resolve it. Monitoring solutions are only there to pinpoint where exactly the problem is. After that, it's the IT team that has to take care of it, whether they have to contact the respective SD-WAN vendor or SaaS provider or ISP. AppNeta reduces our MTTR for sure.

From a technical perspective, PathView provides an effective, reliable indicator of network availability across our widely distributed physical locations. From a non-technical perspective AppNeta Customer Support remains continuously and positively engaged with us.

PathView provides immediate unequivocal confirmation of service restoration during situations that involve planned or unplanned loss of network connectivity.

End-to-End video testing - we would deploy m22s into a client’s network where we plan to deploy a high end video endpoint. This allows us to ensure that the client's network is capable of handling the planned video traffic. We run it over 24 hours or 7 days so that we can see the effect of any other traffic on the network, such as nightly backups.

We run 24 hour or 7 day video based network path assessments to ensure our customers networks are ready for video systems.