(upbeat instrumental music) >> Narrator: From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Hey welcome back everybody, Jeff Frick here with theCUBE. We're in our Palo Alto offices for a CUBE Conversation today. We're going to talk about an interesting topic. You know as all these applications get more complex and they're all Internet based. I'm sure you know that feeling when you're at home and you lose your Internet power you pretty much can't do much of anything. So what can we do about that? Who are some of the companies that are working on this problem? We're real excited to have an innovator in this space from ThousandEyes. She's Archana Kesavan, Director of Product Marketing for ThousandEyes, welcome. >> Archana: Thank you Jeff, it's good to be here. >> Absolutely, so this is crazy. Give us kind of the run-down on ThousandEyes and what you do and then we'll jump into it. >> Sure, so ThousandEyes is a company that provides and enables enterprises. Gives them visibility into how the Internet is impacting end-user experience, right? When you think of it, of what users are, what this user experience is, it could be twofold. One is if you're an enterprise providing a digital service then they're your customers, right? So that customer experience we provide visibility into that. Then also if you're an enterprise moving towards using cloud applications or SaaS applications, employees using those applications, we provide visibility into that space as well. Really the thought and the idea behind ThousandEyes and the reason we are here is as enterprises are moving to the cloud and relying on this Internet-based delivery infrastructure, they're are starting to lose visibility into their critical customer-facing and employee-facing applications. What ThousandEyes does is it gives them back that control by giving them that visibility into that environment. >> Okay so then just to be clear because there's a ton of kind of monitoring applications, we use the Sumo Logic, we do Splunk. So there's a lot of things around operations where they're monitoring these apps, and they're super complex apps. But your guys main focus if I understand, is the network. The network piece and the transportation of that app across the wire. >> Right, let me unpack that and explain with an example, right. Let's think you're an enterprise that's moving towards Office 365 and you have a global workforce, right? Your users are connecting report and your VP of sales happens to connect from a Starbucks or a Philz because we're in Palo Alto. Can't download emails, can't get to emails. What's the first step this person or this employee's going to take is call corporate IT and say hey, I can't get to my emails. Now it's up the the corporate IT team to go and troubleshoot that scenario, right? Because if you can't get to your emails or you can't get to these collaboration apps today it's productivity down the hill. The IT team now starts troubleshooting it and where do they start? Is it the WiFi at the Philz that's a problem? Is it Microsoft that's a problem because which I can't get to my email. Or is it that access in between which is the Internet, right? How do you get from a Philz all the way to Office 365 is through that Internet transport. So where we come in is irrespective of the application or even the network, right, we've very agnostic to it. And we combine application performance all the way to the network performance. We take it one step further and we see how the Internet is impacting the services throughout. Because what we see is our customers be that in enterprises consuming SaaS, or enterprises delivering these SaaS services, the production teams and the corporate IT teams they feel the brunt of this every day. They have people calling and say hey, I can't get to this, I can't get to that application. They have their own customers complaining that something's wrong. Unfortunately in this world of the Internet and the cloud, while it's enabled convenience and flexibility they've traded in that for control and visibility. So if you again go back to this Office 365 example that I was just talking about, the enterprise does not own the WiFi in force. It does not own the Internet. Not one entity owns the Internet. It doesn't own Office 365. So monitoring tools that have existed and that have been in place to understand issues within the four walls of an enterprise flatline when it comes to Internet-based delivery and connectivity, which is where we come in. >> What about VPNs, because isn't kind of the purpose of a VPN on one hand is to be secure 'cause Lord knows who's sniffing on the Philz WiFi. But does that not put you into kind of a higher grade Internet line back to the server to get to my email? >> Archana: Is anybody using VPN these days? >> I hear the ads all the time on the radio. (laughing) I don't know, that's a good question. You guys are sitting on there, are people not using VPN? Does VPN solve their problem? Or is it something that's in the backside that regardless of whether you're using VPN or not these are kind of back hall issues that have to get worked out? >> So VPN, if you think about it, it's kind of an encapsulation over the underlying network. You still have to move packets through this network. So you might be connecting through a VPN, but it's the underlying, if you're going through the Internet than that can result in performance degradation, too. So irrespective of these techniques that enable, or so-called enable, performance and make performance better, you still need to know how the transport's behaving and how it's influencing performance just because you don't control it. >> And as I understand, the way you guys are doing this is you have a lot, a lot, a lot of monitoring points all over the place, hence ThousandEyes. Tell us a little bit about kind of how that works, what's the network? How has that been growing over time? >> We've been growing our infrastructure, monitoring infrastructure, over the last few years. The way ThousandEyes gathers its data which you know all the way from the application layer to the network, kind of then looking at Internet performance is our fleet of agents are distributed, are pre-deployed in about 185 cities around the world. We call them Cloud Agents. Now these agents are actively monitoring the services that might be of interest to an enterprise. You can also take a form of these agents and enterprises can deploy them within their own branch offices and their data centers. You can also use them in cloud providers. We actually have agents pre-deployed in AWS, Azure, Google Cloud, and Alibaba too, which we recently announced. You can use these agents to monitor applications. You can use these agents to monitor your API endpoints which is another growing area that we see. So, fleet of our agents distributed. You can use that, a combination of agents that we own and pre-deployed along with agents that enterprises would like to put in their own infrastructure. >> Right, so you've got the ones already out there, you've got the ones in the clouds and then I can put some additional ones into my remote offices or places that are of interest to me. So if there's an issue because you said for tech support when the person can't get into email there's a whole host of potential things it could be, right? Office 365 could be down, there's all kinds of things. How does your application communicate to this poor person on the end of this service call that hey, it's a network issue between these two points? Or maybe it's a big exchange that's getting attacked like happened on the East Coast a couple of years ago. How did they work that into their triage so they know hey, we've been able to kind of identify that this is the issue not one of the other 47 things that's impacting that application? >> Right so we are a SaaS-based product. Our uniqueness and our secret sauce is how we look at all of these different layers that affect performance and we correlate them, visually correlate them in a time sequence. We present it to the corporate IT person or a production IT person who is actually triaging this issue. We help them very quickly pinpoint. It's very visual there. You can see how application performance ebbs and flows. You can look at what does a network pack look like? If I'm seeing an outage of the Internet service provider we're going to call that out. Obviously all of this is tied in with an alerting system which the platform enables as well. I think one of the most interesting changes that's happening in the industry is in the past when you found an issue, you could fix an issue because the chances are you owned that entire environment, right? It was a router that failed or a switch was dropping packets. You owned that switch, you owned that router. You could go and make changes to it. But in today's Internet-dependent and cloud-heavy environment, it's more about having the right evidence so you can escalate it to the right person. So knowing which neck to choke is absolutely critical in this distributed environment that enterprises are losing control over slowly. >> So the people start to make active changes in the way they route their traffic based on what they find? Is there either consistent good or consistent bad behavior in certain networks or certain public clouds that you can get a better latency performance by switching that? >> Sure, we've seen cases where usually enterprises have, let's take an example of an Internet service provider having an outage. Usually enterprises for redundancy they have two upstream providers, for instance, and they're probably load balancing traffic equally across these providers. Once ThousandEyes detects that one provider is completely down, could be a routing issue, could be a router failed within their environment. Once we alert them it's up to the enterprise to make that decision saying hey, we want to bypass this route, right? And we've seen that happen in a lot of cases. They do bypass routes if it's possible. It also depends on the severity of the issue, how long the issue lasts and things like that. But that definitely happens. >> You guys talk about a concept called Internet-aware Synthetic. What does that mean? >> Synthetics, it's interesting as a term. What it really means is trying to mimic something that's natural. Just the term synthetics in layman's language, right? Synthetic monitoring is really just that. While you're trying to understand application performance or how a website performs, synthetic monitoring replicates how a user would interact with that application. You replicate those steps and you periodically repeat them over time. Let's take an example. You're shopping online, you're going to Amazon.com. You're searching for whatever it is you're searching for. You get a list of results. You are interested in one item, you look at a review, you seem happy, you move it to your checkout, pay and move on, right? Those sequence of steps is what synthetic monitoring can actually craft. We keep executing those steps periodically so you can understand if there's any degradation of performance, has it slipped from baseline? So IT operations team can use that to understand if there's any change that's happening or if there is a particular area in the world where users are starting to see degradation and so on. The nice thing about synthetics is it's proactive. There's a lot of monitoring techniques out there that looks at real user interaction with the website. And to typically do that you need to insert a piece of code within the application itself that tracks that user's activity. That's great information. You want to see what your users are really doing and engaging with your website. That's very useful but it fundamentally doesn't tell you if performance is completely degraded or the checkout button's not working, for instance. That's where synthetic comes in. >> So is that the primary way that you maintain kind of this testing of the health of the network? Or are you using more of a passive, waiting for something to be slow and then running something like the synthetics to try to figure out where it is? >> The recommendation is to keep synthetics running constantly because you don't want something to slow down and then react. That's a very reactive approach. Really in today's digital economy you don't want an outage to last too long because customer loyalty is fleeting. You don't want even 10 seconds of wait time, right? The way I see it is every time I try to find a cab through Uber, if Uber makes me wait 30 seconds I'm moving on to Lyft. I don't have the patience to wait that long. You don't want outages to prolong so you definitely don't want to understand performance after they have degraded, right? So synthetics recommendation is to continuously monitor so you can find out what's happening and if there's any drift from required baselines. >> Okay and then are you running that concurrently across a number of geographies for the same customer? Because if this same shopper's sitting in Seattle versus if that same shopper is sitting in Mexico City or they're sitting in London are you running that concurrently to make sure that you're checking all the different potential hiccups? >> Our agents, because they are so pervasive across the globe you can pick an agent in one of those 185 cities and you can execute those same sequence of steps over time to actually run that. Now synthetics as a technology is not new. It really predates the cloud. The action of mimicking a user journey through a website, that really predates the cloud which is why it's fundamentally broken when it comes to these cloud and Internet-heavy environments. What we introduce, ThousandEyes Internet-aware Synthetics tries to take this age-old technique and tie that together with how the network and how the underlying Internet performs. So when you're looking at performance you're not looking at it in a silo. Because that's the other thing we hear all the time from our customers. Like the application team has blinders on. They're wanting to see if anything's gone wrong at the application. The network team has its own blinders on wanting to see if anything's gone wrong with the network, right? And usually what's happening is if they figure out it's not an application issue then they punt it over to the network team. The network team says ah, not my problem, you take care of it. So there's this constant finger-pointing that happens in today's environment. This pain has really gotten worse in the era of the cloud and Internet-based deliveries because guess what? Your application is first of all split into these microservices. The number of API calls that you are making has gone up, right? And all of these components don't sit in the same place. You're probably running into a hybrid infrastructure environment where some pieces of your code resides in your data center, the other may be in the cloud. Or you're making API calls which is resulting in a multi-cloud scenario. And what is it that's connecting all of these different environments is the actual network and the Internet. So understanding just hey, my app is down, is not good enough any more. You need to know my app is down, it's down because the Internet is causing problems for instance, right? So what ThousandEyes Internet-aware or network-aware Synthetics does is we look at performance right from the application stage, look at all those transactions see if they are run correctly or not. We tie them into how the underlying network is performing. And hey, if the Internet is causing issues we tie that into in a single correlated pin. So you're looking at one single platform and you're able to pinpoint quickly. You gather the evidence to escalate it to the right person. And at the same time you are bringing the application and the network teams together so it's more collaboration. It's not finger-pointing. Then that's what we really want to enable and what most of our customers actually do with ThousandEyes. >> Before I let you know I want to dig into the Alibaba announcement a little bit more. China is a special challenge on the Internet space. We've done some work over there and none of the Google services work and we use a lot of Google services. How did that come about? Is this a new growing area for you? I would presume there's all kinds of demand from the customers to try to get a little bit deeper penetration into that marketplace. >> China definitely is an interesting space. I mean because of the great firewall and all of the techniques China implements, performance is known to be relatively suboptimal in that region. Fortunately or unfortunately it's the fastest growing market, too. So enterprises want to invest in China. We're seeing a trend where they are moving their services to Ali Cloud. What does that mean for enterprises? You need to monitor that environment, too. Which means you want to understand how performances from Ali Cloud to Ali Cloud and so on. What we did recently is we increase our vantage points within Ali Cloud. Now you can look at user experience for users connecting from all around the world into Ali Cloud. You can look at API performance going from Ali Cloud to GCP or AWS, right? I think the key point to remember is that not just in China, but across the world not all cloud providers are created equal. We found some very interesting data for traffic between Beijing and Singapore, Ali Cloud performed relatively better, no surprises there. But AWS has relatively high performance. Same user from Beijing to AWS's data center in Singapore, they had a very circuitous route to get to Singapore. They were going from China to Tokyo to Singapore. During peak times, eight a.m. to eight p.m. Beijing time there was a lot of fluctuation showing some kind of congestion in the network, right? Ali Cloud we didn't see that. Understanding cloud provider performance is absolutely critical. What we do is our vantage points enable enterprises to do that. One of the initiatives that ThousandEyes we've been doing for a couple of years now is do a comparison of all these providers, AWS, Azure, and Google Cloud, and Ali Cloud now. Last year we had our first report, it's called a Public Cloud Performance Benchmark report that compared AWS, GCP, and Azure. This year we're expanding it to Ali Cloud as well. So that's launching in November so it's going to be interesting to see. >> Jeff: A lot of people will want to see that one. >> Yes, it's going to be interesting to see who performed better and where. It's always good information. >> Jeff: I was going to ask you if you could share, but I didn't want you to give away any secrets. But I guess we'll have to wait 'til the report comes out. >> Yes, mid-November it's going to be there. >> All right Archana, we'll look forward to that. I'm sure it will be more variable than what most people expect. >> Archana: We'll see. Thanks for having me, Jeff. >> Thanks you very much. All right, she's Archana, I'm Jeff, you're watching theCUBE. We're in our Palo Alto studios having a CUBE Conversation. Thanks for watching, we'll see you next time. (upbeat instrumental music)