What is your primary use case for Accedian Skylight?

I use Accedian Skylight to diagnose performance or slowness issues on networks. The solution has undergone a change - it used to be on-premise, but now it has transitioned to a SaaS solution. Despite this change, it still requires the purchase of some internal probes. The SaaS environment is currently not widely adopted and thus, not much is known about it.

My company has many customers and needs to collect the performance stats of the devices, which is an Accedian Skylight use case. My company works with different Accedian solutions, such as Orchestrator, Sensor Flow, etc., and uses Accedian Skylight for device discovery.

My client uses Accedian Skylight for monitoring their IP network, that is, for application performance management and network monitoring.

We are a company who specializes in analytics, both testing and analysis. We get involved in DDI: DNS-DHCP-IPAM. We do a lot of stress testing, protocol testing, and protocol analysis, so we use a number of different tools. We typically try to promote to our clients best of breed type products. At the moment, we have a demo system with the whole suite. That would be VCX and PVX. We are using the Skylight centres to do link testing as well as analytics for multi-office simulations. So, we have set up a demo system within our lab to talk to a couple of home offices as well as look at traffic coming into our own office. Therefore, we have some setups that we can demo to our clients who want to do similar sorts of things, e.g., people who want to be able to text links or look at jitter and latency from one site to another. Typically, people who have multi-office/multi-sites want to be able to link test and understand the latencies between each site. First, they want to be able to understand if there are any throughput issues. Second, from an analytics perspective, they look at application network performance from a centralised perspective. We use it for demonstration purposes to provide solutions to our clients looking for this level of analytics and level of testing. That is our primary goal. While we use it to look at our own networks, it is mainly there as a demonstration type of tool. We have a number of tools that we use for demoes. This is just one of them. However, the fact that we have a demo system to show people is also the way we look at analysing our own network. We can look where things are being held up or being impacted, such as cloud apps, on our own in-house environment as well as at our connection to our public service provider. We have a public cloud instance for all our other probes or SFPs. Then, everything else is on-premise, VM deployment. For example, even our PVX analyser is sitting as a VM. So, we have one big server that is partitioned out with different VMs to handle all different parts of the Accedian suite.

We had issues for a number of years with our carrier. I had dropped our bonded T1, 3 Mbps, to go to 100 Mbps fibre, minimum, to every location. We have 26 branches. Because of the scale and the magnitude of the capacity, it's fraught with not noticing whether we're getting our subscribed bandwidth, and we're paying a lot of money annually for our MPLS network. When I figured out the players like AT&T, and others in the mix, can have NNI, even though you think you have a 10 Gb connection—my backbone and my data centers are now connected to 10 Gb lines, my backbone is pretty much limitless—I wasn't sure what we were getting. The scale of improvement from going to fibre, with this institution so used to having 3 Mbps, made everything look better. Except, I knew that when I need to put hundreds of terabytes of data across data centers and other components, I would have very specific expectations, and my intuition was that it wasn't even close. I was pretty much correct. We had video that was having trouble, and that was the "tell." When we started to look deeper, we had massive amounts of packet loss at higher capacities and smaller packet sizes. I've got a year or two worth of research at the highest levels. We needed a product such as the Accedian, that could knock it out—exactly where the issue is—in a matter of moments, and they were right. It's an extraordinary endeavor. I had an intuition that things needed correcting, and I was spot-on. Accedian is a combination of SaaS and hardware devices. I have eight in my data centers and I have 26 branches, so the total we have is close to 85.

We are an IT consulting system integration and managed service provider. We provide service to different companies and focus on IT infrastructure, licenses, and security network. We also provide IPs, data center, virtualization, cloud solutions, etc. Our customer had a performance issue. So, I introduced them to enterprise side of the Accedian solution. They have both on-premise and SaaS, but the primary component is deployed on-premise. We gave them two components to the solution: One is called active monitoring and another is called passive monitoring. The active monitoring is part of their box appliance into the circuits and used to collect real-time information. That information will be sent over to their SaaS platform for analytics. We collect the information locally, installing a sensor control unit, which is a virtual server. Then, information gets collected from all the locations via active monitoring. The information will then be sent over to a the SaaS platform, which Accedian has for analysis. * The ant Module is an appliance monitor, like a black box appliance. That's controlled by VMware. It is active monitoring and appliance-based. It plugs in data to the local VMware virtual server for collection, which is sent over to the cloud staff for analytics. * The latest version of PVX that we are using is 6.6. That's for the application performance monitoring, which is passive. I know they are also trying to get the PVX into the cloud for analytics as well. I think that will happen later this year, but right now, it's being analyzed locally on a separate VMware server. They have a bunch of VMware servers using the full control for orchestrator and to do analysis. For this particular deployment, we monitor the Internet, but we don't have Amazon Web Services or cloud deployment. We don't use the cloud for our service application. We have a local hosted service data center and our own private cloud. We built our own hosted data center at a third-party. Therefore, we do monitor the data side of the performance, including the connection, network, and application, but it's not a public cloud. We deploy the same PVX and ant Modules in our private cloud environment. These collect the application data for me so we can see how the application performs. It has achieved what I wanted to do, so it works great.

We use Skylight to monitor the performance of our network on different sites. We also use it to troubleshoot if there is an issue on the network/standard and the end user experience is good. Recently, we used Skylight to monitor the amount of external user VPNs. With COVID-19, we have many people who work at home. We used Skylight to count the number of users and monitor the Internet line to see if there was a point of saturation. It is mostly deployed on-premise with some services in the cloud.

We are looking into systems that will provide users with end-to-end application and network performance monitoring in real-time. Media and broadcasting place quite high demands and, consequently, the ability to know exactly what's going on is key to success.

We use it to troubleshoot application issues. For instance, when an application is slow we can identify where the bottleneck is in the chain.

We are a hospital and we have a lot of external consultants and a lot of external programs. When we have a performance problem with a program, generally the response of the consultant is, "Oh, it's your network, your infrastructure, your server." With Skylight it's easy to prove that the problem is not our infrastructure and, in most cases, the problem is the application. We use it to improve the performance of the database tables as well as for our Citrix solution.

Our primary use case is troubleshooting. If a user starts to complain about something that's not working, we have a look into it. It depends on whether it's already into the mirrors or not, because that's a problem at the moment. We have most of our servers on ESX machines at the moment, and each of these machines have dual 10-giga links. Putting them all together with a mirror onto only one 10-giga link makes it drop packets. I usually don't do that. I usually only put one or two of those servers into the mirror to avoid too much packet loss. In the future we should go for a more distributed version, where we have Skylight on each ESX server so we don't lose any information at all. But at the moment, we have just one big appliance, called Site Extra Large, and we are running 5.1.3R1.