(dramatic music) >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're in our Palo Alto studio for a CUBE conversation. It's really a great thing that we like to take advantage of. A little less hectic than the show world and we're right in the middle of all the shows, if you're paying attention. So we're happy to have a CUBE alumni on. He's been on many, many times. Saar Gillai , he's now the CEO of Teridion. And Saar, welcome. I don't think we've talked to you since you've been in this new role. >> Yeah, it's been about a year I think. >> Been 'about a year. So give us kind of the update on Teridion. What it's all about and really more importantly, what attracted you to the opportunity? >> Sure. First of all, great to be here. I don't know where John is. I'm looking for him. He ran away. Maybe he knew I was coming. >> Somewhere over the Atlantic I think. 35,000 feet. >> I'll follow up on that later but hey, you're here. So, you know Teridion, let's talk about maybe the challenge that Teridion is addressing first so people will understand that, right. So if you look about what's going on these days with the advent of Cloud. and how people are really accessing stuff, things have really moved in the past. Most of the important services that people access were in a data center and were accessed through the LAN so the enterprise had control over them and if you wanted to access an app, if it didn't work, somebody when into the LAN, played around with some CISCO router and things maybe got better. >> But at least you had control. >> You had control and if you look at what's happened over the last decade, but certainly in the last five years, with SAS and the Cloud. Stating the obvious, more and more of your services now are actually being accessed through your WAN and in many cases, that actually means the internet itself. If you're accessing Salesforce or Box or Ignite or any of these services. The challenge with that is that now means that a critical part of your user experience, you don't control. The vendor doesn't control because you can make the best SAS up in the world but, and those apps are increasingly very dynamic. Caching doesn't solve this problem and the problem is now, okay, but I'm experiencing it over the internet. And while the internet is a great tool obviously, it's not really built for reliabilty, consistency, and consistent speed. Reality, if you look at the internet, it was designed to sent one packet to NORAD and tell them that some nuclear missile died somewhere. That's what it was designed for right? So the packet will get there but the jitter and all these things may work and so what happens is that, now you have a consistency problem. Historically, people will say well, that's all been addressed through traditional caching and that's true. Caching still has it's place. The reality is though that caching is more for stuff that doesn't change a lot and now, it's all very dynamic. If you're uploading a file, that's not a caching activity. If you're doing something in Salesforce, it's very dynamic. It's not cached. At Teridion, we looked at this problem. Teridion's been around about four years. I've been there for about a year. We felt that the best way to solve this problem was actually to leverage some of the Cloud technology that already exists to solve it. So what we do, actually, is we build an overlay network on top of the public Cloud surface area. So instead of traditionally, the way people did things is they would build a network themselves but today the public Cloud guys honestly are spending gazillions of dollars building infrastructure. Why not leverage it the same way that you don't buy CPUs, why buy routers? What we do is we create a massive overlay network on demand on the public Cloud surface area. And public Cloud means not just Amazon or Google but also people like AliCloud, DigitalOcean, Vulture, any Cloud provider really, some Russian Cloud providers. And then we monitor the internet conditions and then we build a fast path. If you think about it almost like a ways, a fast path for your packet from wherever the customer is to your service thereby dramatically increasing the speed but also providing much higher reliabilty. >> So, lot of thoughts. If I'm hearing right, you're leveraging the public Cloud infrastructure so they're pipes, if you will. >> And they're CPUs. >> And they're CPUs but then you're putting basically waypoints on that packet's journey to reroute to a different public Cloud infrastructure for that next leg if that's more appropriate. >> Yeah, and basically what I'm doing is I'm basically just saying if there's a, if your server's here whether they're on a public Cloud or somewhere else, it doesn't matter, and a customer is here, through some redirection, I will create a router on a public Cloud so a soft router, somewhere close from a network perspective to a user and somewhere close to the server and then between them, I'll create an overlay fast path. And then, what is goes over will be based on whatever the algorithm figures out. The way we know where to go over is we also have a sensor network distributed throughout the public Cloud surface areas and it's constantly creating a heat map of where there's capacity, where there's problems, where there's jitter and we'll create a fast path. Typically that fast path will give you, one of the challenges, I'll give you an example. So let's say you're on Comcast and let's say you've got 40 meg let's say, your connection at home. And then you connect to some server and theoretically that server has much more, right? But reality is, when you do that connection, it's not going to be 40 meg. Sometimes it's 5 meg, okay? So we'll typically give you almost your full capacity that you have from your first provider all the way there by creating this fast path. >> So how does it compare, we hear things about like Direct Connect between Equinix and Amazon or a lot of peer relationships that get set up. How does what you're doing kind o' compare, contrast, play, compare to those solutions? >> Direct Connect is sort of a static connection. If you have an office and you want to have a Direct Connection, it's got advantages and it's useful in certain areas. Part of the challenge there is that first of all, it has a static capacity. It's static and it has a certain capacity. What we do, because it's completely software oriented, is we'll create a connection and if you want more capacity, we'll just create more routers. So you can have as much capacity as you want from wherever you want where with Direct Connect, you say I want this connection, this connection, this much capacity and it's static. So if you have something very static, then that may be a good solution for you but if you're trying to reach people at other places and it's dynamic, and also you want variable capacities. For example, let's say you say I want to pay for what I use. I don't want to pay for a line. Historically, when you're using these things, you say okay, if the maximum I may want is 40 meg, you say okay, give me a 40 meg line. That's expensive. >> Right, right. >> But what if you say I want 40 meg only for a few hours a day right? So in my case, you just say look, I want to do this many terabytes. And if you want to do it at 40 meg, do it at 40 meg. It doesn't matter. So it's much more dynamic and this lends itself more to the modern way of people thinking of things. Like the same way you used to own a server and you had to buy the strongest server you needed for the end of the month because maybe the finance guy needed to run something. Today you don't do that right? You just go to public Cloud and when it's the end of the month, you get more CPUs. We're the same thing. You just set a connection. If you need more capacity, then you'll get more capacity that you need. We had a customer that we were working with that was doing some mobile stuff in China and all of a sudden, they needed to do 600,000 connections a minute from China. And so we just scaled up. You don't have to preconfigure any of this stuff. >> Right, right. So that's really where you make the comparison of public Cloud for networking because you guys are leveraging public Cloud infrastructure, you're software based so that you can flex so you don't have the old model. >> It's completely elastic, like I said. It's very similar. Our view is the compute in the last decade, obviously, compute has moved from a very static I own everything mode to let's use dynamic resources as much as possible. Of course, there's been a lot of advantage to that. Why wouldn't your connectivity, especially your connectivity outside which is increasing your connectivity also use that paradigm. Why do you need to own all this stuff? >> Right, right. As you said before we turned the cameras on the value proposition to your customers who are the people that basically run these big apps, is the fact that they don't have to worry about that but net is just flat out faster to execute the simple operations like uploading or downloading something to BOX. >> And again, you mentioned BOX, they're one of our big customers and we have a massive network if you thing about how much BOX uploads in a given day, right? 'Cause there's a lot of there traffic that goes through us. But if you think about these SAS providers, they really need to focus on making their app as good as possible and advancing it and making it as sophisticated as possible and so, the problem is then there's this last edge which is from their server all the way to the customer, they don't really control. But that is really important to the customer experience, right? If you're trying to upload something to BOX or trying to use some website and it's really slow, your user experience is bad. It doesn't matter if it's the internet's fault. You're still as a customer, So this gives them control. They give us that ability and then we have control that we can give it much faster speed. Typically in the US, it may be two to five times faster. If you're going outside the US, it could be much faster sometimes. In China, we go 15 times faster. But also, it's consistent and if you have issues, we have a knock, we monitor, we can go look at it. If some customer says I have a problem, right? We'll immediately be able to say okay, here's the problem. Maybe there's a server issue and so forth as opposed to them saying I have a problem and the SAS vendor saying well, it's fine on our side. >> Right, right. So, I'm curious on your go to market. Obviously, you said BOX is a example of a customer. You've got some other ones on the website. Who are these big application service providers, that term came up the other day, like flashback to 1990. 1998 >> I call them SAS >> It's funny, we were talking about the old days. >> To me, it's all the same, as a service guy. >> But then, as you go to market then going to include going out directly through the public Clouds in some of their exchanges so that basically, I could just buy a faster throughput with the existing service. Where do you go from here? I imagine, who doesn't want faster internet service period? >> Yeah, we started off going to the people who have the biggest challenge and easier to work with a small company right? You want to work with a few big guys. They also help you design your solution, make sure it's good. If you can run BOX and Traffic and Ignite. Traffic can probably handle other things, last year for example. We are looking at potentially providing some of the service, for example, if you're accessing S3 for example, we can access S3 at least three times faster. So we are looking potentially at putting something on the web where you could just go to Amazon and sign up for that. The other thing that we're looking at, which is later in the year, probably is that we haven't gotten a lot of requests from people that said hey, since the WAN is the new LAN, right, and they want to also try to use this technology for their enterprise WAN between branch offices where SD-WAN is sort of playing today, we've gotten a lot of requests to leverage this technology also in SD-WAN and so we're also looking at how that could potentially play out because again, people just say look, why can't I use this for all my WAN connectivity? Why is it only for SAS connectivity? >> Right, right. I mean it makes sense. Again, who doesn't want, the network never goes fast enough, right? Never, never, never. >> It's not only speed. I agree with you but it's not only speed. What you find, what people take for granted in the LAN but they only notice it when now they're running over the LAN is that it's a business critical service. So you want it to be consistent. If it's up, it needs to have latency, jitter, control. It needs to be consistent. It can't be one second it's great, the next second it's bad and you don't know why and visibility. No one's ever had that problem. >> I'm just laughing. I'm thinking of our favorite Comcast here. If they're not a customer, you need to get them on your list. Help make some introductions hopefully. >> So, people take that for granted when they're LAN and then when they move to the Cloud, they just assume that it's going to continue but it doesn't actually work that way. Then they get people from branch offices complaining that they couldn't upload a doc or the sales person was slow and all these problems happen and the bigger issue is, not only is this a problem, you don't have control. As a person providing a service, you want to have control all the way so you can say "yeah, I can see it. "I'm fixing it for you here. "I fixed it for you." And so it's about creating that connection and making it business critical. >> It's just a funny thing that we see over and over and over where cutting edge and brand new quickly becomes expected behavior very, very quickly. The best delivery by the best service, suddenly you have an expectation that that's going to be consistent across all your experiences with all your apps. So you got to deliver that QS. >> Yeah, and I think the other thing that we notice, of course, is because of the explosion of data right? It's true that the internet's capacity is growing but data is growing faster because people want to do more because CPUs are stronger, your handset is stronger and so, so much of it is dynamic. Like I said before, historically, some of this was solved by just let's cache everything. But today, everything is dynamic. It's bidirectional and the caching technology doesn't do that. It's not built for that. It's a different type of network. It's not built for this kind of capacity so as more and more stuff is dynamic, it becomes difficult to do these things and that's really where we play. And again, I think the key is that historically, you had to build everything. But the same way that you have all these SAS providers not building everything themselves but just building the app and then running on top of the public Cloud. The same thing is why would I go build a network when the public Cloud is investing a hundred billion dollars a year in building massive infrastructure. >> Yeah, and they are, big infrastructure. Well Saar, thanks for giving us the update and stopping by and we will watch the story unfold. >> Great to be here. >> Alright. And we'll send John a message. >> I'll have to track him down. >> Alright, he's Saar, I'm Jeff. You're watching theCUBE. It's a CUBE conversation at our Palo Alto Studio. Thanks for watching. We'll see you next time. (dramatic music)