It has application and Layer 7 support, so that's going to be the next evolution. I had built an institution that I wanted to be number-one in Southern California, and I got bored and wanted it to be number-one in all of the US. When I talk to folks that used to work for, or who work for, Citigroup, they want to come work with me because we're doing things like NVMe capabilities of my sub-infrastructure that operates with 100 Gbps port speeds across state-of-the-art Aristas in a way that people can only dream of. 

As we prepare for the next five to 10 years, everything is based on network performance, latency, and application support. We have it set up in a way where we test the capabilities of the telco, the main provider, the local ex, the firewalls, and the switches right into our virtualized infrastructure in every single one of our locations. We virtually eliminate any finger-pointing. We know that if anything goes into maintenance due to an outage, and the failover is supposed to occur, we can instantly test it.

We called out AT&T on a 1-Gbps NNI that was supposed to support 60 folks—which in and of itself was a problem, because we're supposed to have 700 Mbps, guaranteed. When they failed over to a 100 Mbps, they completely saturated it and ran out of bandwidth. We were able to call them on all of this in real time. When we thought there should be 10 Gbps per 60 clients, we identified that they had unnaturally put all 60 through a 1-Gbps line.

The value is for networks on which hundreds and hundreds of thousands of dollars are being spent, where we have this level of intel. And we don't actually have to move around the network at a point in time, the way the world operated for the first 20 or 30 years of networking. We literally send traffic during the day and off-hours. We schedule these tests for repetitive performance, and the results are delivered in a digestible PDF report so that a non-technical person can see what passes and what fails.

It has saved hundreds and hundreds of thousands of dollars. You can pay that money, but there's no guarantee you're getting that capability. 

We also can tell instantaneously whether or not we need to consider justifying more throughput or if we don't need what we have. There are probably several ways to look at what that is worth to an organization. However, if you have a system that's out in the cloud world, whether it's budgeting or mortgages, try to put a dollar figure on the capability to ensure the systems are working beautifully at all times.

In addition, Skylight has improved the interaction between my network, data center, and application teams, 100 percent. The layer side of it will be the icing on the cake. I will tell you the user experience before the user can tell you the user experience. We're fixing things for the applications team, and they don't know how or why. We're taking things that, in the mortgage world, historically had epic low rates in production, and doubling them. Just this week, I did something which changed a process that used to take between 30 seconds and a minute and a half and made it real-time, instantaneous. It's extraordinary.

Skylight brings the firewall and security teams to be very in-tune with the network teams, the telco teams, and the carriers that do the local. Any one of those could be finger-pointing at the other. We pinpoint exactly what the issue is, we tell them where it is, and it's pretty irrefutable. There are a time savings and there is collaboration.

You start buzzing away with NetFlow out of SolarWinds, and they'll tell you 17 reasons why it's something else. It's like playing a good game of chess. You think about every move two years in advance and, when it comes down to it, you end up with $50,000 worth of free gear, including, but not limited to, removing traffic shaping and policies that you know are strangling the network. I liken it to having the very best medicine for bronchitis or asthma or any type of breathing condition. This would be the medicine you would want. It opens up the complete "breathing" of the network, right down to every component, whether you're streaming video or doing other things.

You can simulate VoIP issues. As we move the organization to enterprise SIP, my biggest concern in my data centers is that if we ever had one-direction audio, we would never be able to figure it out. It would just take an extraordinary amount of time. Now we can simulate it, understand it, and resolve it in really short order. In fact, I have an engineer who came from LA Fitness, with 720 locations, and he said he took over a year and a half to figure out a problem, and he could have done it in under a month with this software.

When we moved small packets over certain routers, they would absolutely fail, and the world would tell me, "Oh, well, that's the way it is," and I said, "That's not possible." I proved that with higher caliber gear. We were able to move packets flawlessly down to 0.1 and 0 percent packet loss, which is unheard of, and maintained it. I proved it and showed the result. And then I did that again to ensure that the memory and the processing capabilities of the next-gen firewalls that are in every single one of my locations, are capable. And that was right through my primary firewall, to make sure they're capable of sending and adhering to certain traffic loads.

When I joined the company four-and-a-half years ago, I changed everything on a massive scale, to the point where if a vendor calls up and says something may not be running as expected, I politely explain to them that it's not even possible and that they need to take a look at their coding. I took apart every single piece of the puzzle, including four brand-new core switches that run the entire institution, where before we had three that were 10 years out of date; 120 switches, all Cisco, all brand-new. There was no stone unturned. When we run Accedian, if something isn't right, I can tell you exactly what it is and why.

In terms of reducing mean time to respond, it's done so by years. I don't even know how to estimate it. There are things that could never have been solved. When they tell you that they have put Quality of Service on your network, it could take you a lifetime to figure out and identify that the packet traffic and the tagging is converted because you have poor policy that converts everything into a particular tag. No one will believe what I'm saying in terms of saving "years to a lifetime," but you just have to see what this stuff can do. When used properly, there's no telling what you can do. I can say "from a year-and-a-half down to a month" and that's a reasonable metric.

One major piece of what we are doing is called active monitoring (ant Module). Active monitoring is to monitor all circuits we have. For example, from Miami to New Jersey, we have a circuit. We're going to measure the performance package: loss, delay, jitter, and slew codes. We measure those KPI metrics, then we know how our network is doing. That's one side of the monitoring.

Another component is called a passive monitoring. At every location and between locations, we have a lot of application data. So, we are collecting all that data to the Accedian on-premise enterprise appliance (PVX). The PVX will collect all the application data locally and analyze it based on the different network segmentation of the traffic and its different applications, such as the Internet abroad in traffic, email traffic, database traffic, web traffic, or other production application traffic. It will separate them and analyze that traffic for each flow. If there are some issue with some application, it will be able to detect them.

For example, if people say, "Oh, my email is very slow." It can tell me, "Because the DNS resolution took 10 seconds. It should it be maybe 0.5 seconds. That's why there is a problem." Then, we can look into why it's taking so long to resolve a DNS thing. So, that helps us troubleshoot. Otherwise, when people complain about the performance, we don't know where to look into that issue. Therefore, this is a very good tool. We can look at the real-time data. We can understand why maybe a server is overutilized, then we can troubleshoot it from there. So, it's very powerful. We like it.

We have had poor network performance, and when we complained to our service provider, whomever they were, we didn't have data to back up our claim. We needed to show them something, such as, "Over the last three minutes, we haven't been collecting data between the two endpoints of your circuit." That's not good, and we needed to show them something.

Accedian can help me find the root cause of this issue. In general, we need to measure the service provider's performance. The service provider, when they sell you your circuit, will give you an SLA. Therefore, we can use the information that we collected to compare it to their SLA, whether it's package loss or latency. It can help me pinpoint the root cause of the network problem quickly. That's definitely one good thing.

With the passive monitoring for the application, they can pinpoint an application issue quickly to avoid finger-pointing. Application people might say it's a network issue. Network people might say, "No, it's not my issue. It's an application issue." We can get into those ping pong games all day long. It will not get us anywhere. With this tool, it can help us intelligently troubleshoot the root cause of the issue, which is great.

In terms of network troubleshooting, not so long ago a new company started (IT hosted on our location), and one of them was complaining about QoS trouble with VoIP telephony. They decided to go with a cloud telephony solution where I did have no say in it. I had to tell them, "I have no idea how this thing works. I have no visibility into any of the management of that solution." They were complaining about bad voice quality. Normally, I shouldn't have been able to know anything about it. But I thought I would just put Skylight on it for a moment to have a look at what was happening. I changed the mirror for a while so that Skylight could see the traffic, and it didn't take long to figure out that there were a few agencies that the company was using that had, at certain moments in time, some notable packet loss and some bad MOS scores on the VoIP part.

With that information, I was able to go to the company that gave us the SIP trunk and tell them about it. They changed some parameters, because there was something wrong on their side, and it was fixed. 

Without that hard information it would have been pretty difficult to find things like that. Skylight is not used on a daily basis, but when it's used it usually helps to fix a problem pretty fast. I don't really have to look into multiple devices because it captures most of them. With that information I can usually say, "Okay, why is your server slow? Maybe you should not have all the thin clients asking every ten seconds about some server." If you have 1,000 thin clients, suddenly you have 100 requests every second.

That's what you can easily see with Skylight. 

I have no idea how much time it has saved when it comes to response time, but I am comfortable saying "a lot."

In terms of helping improve interaction between our network, server, desktop and database teams, we're all in the same boat. It has helped me a lot when they have had serious issues. It helps me to say, "You came to me with an issue, I found this information. Which points to a specific problem at some team".  It helps them, of course, in figuring out why something is slow/not working... It helps us saving time. We can look for a solution, not the problem.

In the past, we had some serious loads on a file cluster, which was mainly due to a few procedures doing some bad things, like passing through an entire directory and asking for every file in the directory tree one by one. While doing that, it continually opened and closed all the total transactions. So it was incredibly slow and incredibly heavy, because of one bad procedure. Skylight helped us a lot at that point in time, especially the server team, to figure out why the file cluster was slow. In the end it was a simple procedure creating havoc on the FILE Cluster. Hard to find when you can't see CIFS traffic.

We are dealing with a couple of organizations who are using Skylight sensors, so the SFP based analytics to look at multi-sites. 

There is a large supermarket chain looking to invest and put into deployment a lot of sensors to look at different store performance, trying to understand latencies between stores, packet loss, and why certain applications are having issues. They are really looking into the link metrics of latency jitter, packet loss, and response times for multiple sites and stores to give them some insight into performance of networks, since one of the things they have got to work out is, "Do their internal networks have a problem? Is it their external networks? If it is their external networks, does it have anything to do with them, their edge devices, or is it the carrier who has the issue?" It is about the finding the demarcation between internal edge and carrier problems to understand who is at fault. This is sort of an example of where our customers get some value out of the solution.

It is about finding operational problems. When sites go down, we try to determine who is at fault. While there is not much finger-pointing, the solution is just trying to analyse when there is an outage and where do we start looking to fix it. The very nature of why organization chooses to use the solution is to accelerate the meantime to resolution and find where problems lie to get them rectified as quickly as possible.

It helps optimize productivity and downtime. Before our clients used this sort of stuff, the downtime was sort of an unknown problem. People were doing silly things with Wireshark traces trying to work stuff out. The hard part was finding out what the problem was. There was meantime trying to understand what the issue was, then trying to solve it. We have cut down that scenario of trying to work out where the problem is, which is obviously a benefit to our clients who use Accedian sensors.

It has sort of improved capacity planning by helping to size the network bandwidth or performance for the infrastructure.

Skylight is on our data center. Only our network teams have access to it. However, the network team does speak about the diagram of the dashboard to the application team, who doesn't have access to Skylight. Thus, the solution has helped to improve the interaction between our network and application teams as we work together.

We're still in the research stage. We are looking to test performance management systems on a standalone network, which we will load with real-world traffic. We will conduct these tests this year. It's yet to go live, but testing has been very positive.

I do a lot of troubleshooting with Skylight, troubleshooting network speed and application performance. It's really good because we have all the metrics, and it's very easy to find a direct route to the problem.

For example, one month ago we had to change a lot of servers in a laboratory. Before the change of the infrastructure, we took a snapshot of the network infrastructure and the performance. After the replacement of the servers, we took the same snapshot, the same picture of the network and the performance. We could see if the network was better and if the server performance was better than the old server. It was easy for us to see if the replacement of the hardware was good or not; or, after the virtualization of a server, if the performance is better or not. Without Skylight it would be difficult to compare because we would not have any measurements.

My work is easier with Skylight. It's easier to troubleshoot. It's easier to get a view of my network's health.

It has also helped to improve the interaction between our network, data center, and application teams. I can generate a report, for example, of database status or health. It makes it easier to discuss with the database administrators, to explain where a problem is. It's much easier to explain issues and to discuss them with the correct guy.

It's very important for us to have it. We save a lot of time when we have a problem. It's very easy to point to the problem and to get to the solution, whether it's a network problem, an application problem, or a server problem. It's very easy with Skylight.

In addition, it has improved productivity for sure. Regarding improvements in downtime, it's difficult to evaluate because we had a lot of other sensors to help us know if a server had a problem or if there was a database problem. If it was a big crash, for example, we had that information before we started using Skylight. If the issue is a degradation of an application or a service, Skylight is very useful because we see it on the main dashboard. We see all the applications. It's a critical application. If we have a green, and after that it's orange and then red, we know we have a problem. It's easy.

In terms of network troubleshooting, we had an issue with an application, that it was slow for certain users. We didn't understand why. We started to investigate and, thanks to Skylight, we were able to see that the application was very chatty. It was fetching lines one-by-one. That meant it had to do many transactions to get the full bundle from the host. Skylight helped a lot in this case because we could see that there were 1,000,000 small transactions instead of just a few.

We didn't have a tool before to investigate end-to-end performance issues. Thanks to Skylight we have a tool for this kind of investigation. When business users are complaining about application problems, we are able at least to identify where the bottleneck is. Of course, if the bottleneck is on the server itself, we will use tools other than Skylight because it is more for network investigation than on the server side. With Skylight we can identify that most of the time is spent on the database or on the proxy or on the application server. It has sped up investigations a lot. Before, we had to spend more time to identify in which block the bottleneck was found. Now it's much faster. It has reduced our mean time to respond by at least 50 percent.

In addition, sometimes users complain that they are not getting the data they want. Thanks to Skylight and the PCAP functionality, we are able to capture the traffic and to confirm whether the data was transmitted or not. It's quite important in terms of proof.

Skylight has helped to improve the interaction between our network data center and application teams. The server people are now aware of the possibility of investigating the traffic. Thus, when a technical team is facing an issue, they always think, "Okay, maybe I can get more information thanks to Skylight."

Performance Vision saves time diagnosing performance problems. It also anticipates where investment is needed by pointing to the infrastructure limitations.

This product enabled us to identify the cause of some apps known to be running slow. Analyzing connection times from the sequence of elements involved in a request (PC, application server, database server) enables us to immediately identify the element that is failing.

When we are approached for our expertise following an incident on an SI that seems to indicate network infrastructure, the application easily allows us to highlight the black points and to generate exculpatory (or inculpatory) reports for the infrastructure, pointing to the real blocking points.

Following network saturations, analysis was able to reliably detect where the problem came from and solve the problem.

When a remote contact complains about a slow application, we can immediately pinpoint the cause of concern.

Root cause analysis and speed of application performance analysis is faster.

APM analysis is much faster than traditional root cause analysis of application problems.