>> From The Cube Studios in Palo Alto, in Boston, connecting with thought leaders around the globe. These are Cloud Native Insights. >> Hi, I'm Stu Miniman the host of Cloud Native Insights where we're talking to companies and practitioners about how they take advantage of the innovation and agility of the cloud. Happy to welcome to the program I have first time guests, you know, Ido Safruti he is the co-founder and CTO of Perimeter X going to talk him in a dual role, both as a practitioner and their adoption of Cloud Native Technologies serverless specifically as well as they are a Cloud Native supplier in the security realm. Ido thanks so much for joining us. Nice to have you on the program. >> Yeah, good to be here. Thanks. >> All right. So Ido, if you could, you're co founder of Perimeter X, give us just, if you would, a little bit of your background and you know, what Perimeter X does and we'll, go into it from there. >> Sure. So as CTO, I'm in charge of the research, engineering, and product team at Perimeter X, we are a vendor, a Cloud Native vendor of web application security protecting all kinds of different business logic abuses for our customers, mostly large websites that are in demand of web-scale. So not only doing the protection or the application, but also integrated into multiple infrastructure and running at scale. We're solving problems like account takeover, carding, a major card data skimming and so on. >> One of the conversations we've been having the last couple of years from security is, you know, there's no shortage of new threats, the surface area of attack, keep getting more here in 2020, everybody's working from home more, the people that are doing attacks didn't stop working. So if you could just, you know, how long has Perimeter X been around? And I want to lead up to the discussion of serverless, you know, what was the architecture considerations before? And what started leading you towards making a change architecturally? >> Yeah, so Perimeter X was founded almost six years ago, a little less than six years ago. And we were a Cloud Native Solution to begin with. We identified the challenges of where the gap security in native cloud application is. For in many cases, security solutions are not leveraging the breadth and the new architecture of where applications are built. And we're more of trying to slap in a standard enterprise security and on other cloud infrastructure. When we started, we wanted to integrate and adopt the cloud and adopt the flexibility of the specificity of the edge to help enhance our customer's infrastructure by adding security onto that versus forcing them to rearchitect it when they integrate security into it. >> Well, it's addressing, you say six years ago. I can't remember hearing the term Cloud Native that long ago. Obviously Cloud has been around for a while, but when I started this one of the discussions around Cloud Native was, Oh, people were talking about adopting containers and Kubernetes. And I said, they're great tools to help from, you know, the infrastructure standpoint, but you're talking about right, living in the Cloud, taking advantage of cloud services, you know. That's where we really see the opportunity in Cloud Native. So, you know, when you say you were built for the cloud, but you know, things like containers, server lists probably weren't doing those six years ago, maybe, or were you? >> Actually, yeah, so we started early versions of obviously all dockerized Grenades was not that great back then. So we were orchestrating some things on our own and gradually adopting other orchestration and mesh for our own service that is obviously running on multiple cloud vendors. But from us, from our point of view, the key for cloud was how can we enable our customers, and how can we integrate better with them in a way that enhance their infrastructure versus add friction? Because the challenge usually with security, is that security in most cases or traditionally, was adding friction and delays and complexity to developer process. And we're designing our solution to begin with on how can we leverage these new technologies? How can we leverage the fact that CDNs and edges are becoming smarter and can, you can start deploying your own payloads and logic to make our logic integrated with them and to partner with this cloud players in order to enable our customers to add these additional tiers. And I think this is from my point of view, one of the key capabilities of having the capabilities of computed edge and serverless, is making a lightweight integration and making your existing infrastructure smarter by making it easy to incorporate third party vendors or other solutions or more logic without forcing a wholly architectural solution. >> Yeah, no, no. You bring up some great points. I remember back the early days of Docker, it was, can we get the atomic unit to be closer to what the application is. But you know, my background is in infrastructure and it was okay, It went from the server to the VM, to the container. Yeah, there's an application that sits on top of it, but I don't think about it as opposed to serverless starts with the developer first and you know, how I build my application and then there are certain things that I have to worry about the platform. So, help us understand doing containers, looking at serverless, was it okay, we're going to completely overhaul and throw out what we had because there's something new and better. Are you doing still some containers and some serverless? Help us understand, you know, what drove that transition and what the outcomes were? >> Yeah, so our infrastructure our machine learning algorithms, the data processing that the heavy lifting that we're running on our own infrastructure, which is again, Cloud Native Infrastructure. But something that we're managing in many cases is using containers is using other environments because we were running heavy payloads. We're not fully relying on some other platform to run for us. We're leveraging a lot of these technologies to run it and run it in a more efficient way. Where we're adopting serverless is both in some of the front end decisions. So making smarter load balancing decision integrating with some other cloud vendors to help make sure that requests are coming in the right view, and things like this, but where it is more important even then is how can we make ourselves relevant for customers to adopt serverless and how can we help introduce security into these environments? Because, if you're looking at traditional security, if you're, if you're so it's more about, if I go to that one, how can I enable our customers adopt serverless? How can I enable our customers adopt new technologies into cloud? Because it could be a limitation if you're, if you're a security policy or if your architecture is such, that requires everything to go through a specific security proxy or some firewall, it may force you to utilize very limited architectures. If you want to deploy now with payload on some, on Lambda or on, on your CDN, it typically will be way in front of your traditional enterprise security solutions. How can you make that application smarter? How can you make that application sort, self-sufficient by connecting modules, by making sure that you're including modules that integrate security, and bring the security with you everywhere. So, so this is the motion that we're trying to define here. >> Well, and I'm sure you've got a really interesting viewpoint that I'd love to hear on this, Ido. So if you look at, you know, most new technologies, especially in the cloud space, serverless specifically, you know, costs that should be less expensive, you know, flexible. I should be able to, you know, make changes, and speed. I should be able to do more faster, but always when you look at those, you say, well, but what about security? Can I do all of those things, you know, be faster, better, cheaper, more agile, and not be less secure? So I'd love to hear any thoughts you have on kind of the, you know, the typical things, but also your security angle on them? >> Yeah. So one of the benefit of using serverless, and I think there are two types, initially thinking of serverless one is running your code in some, backend application, that may access different things, but you don't need to manage for scale because there is some platform that manage that. Which is one great option, what you're seeing more and more, and we're working in collaboration with Fastly and where you can see that on other edge platforms is having this notion of serverless, How can you deploy code to the edge? And the benefit there is that you can mitigate a lot of the risks outside your data center, outside of your cloud, that if there is, and this is where security plays so well with that, because you want to mitigate the risks and the attack as far away from your application as possible. So if you can deploy the logic that is doing that, or making decisions at the edge, it helps you improve your infrastructure cost. It helps you improve some of the applications that are still in the backend, so you can gradually forward deploy some of the logic that is relevant at the edge and getting the scalability, getting this ability to scale without limit, because a CDN or edge vendor, he has a lot of capacity and withhold if it's a denial of service attack, or if it's any other type of attack, weigh this logic in hand. Or even, sometimes it's just skill. Maybe you had a very good marketing campaign and you were having a lot of traffic. If you can deploy this skill somewhere that can handle that in a distributed, efficient way, you are having even better. >> Well, and it sounds like that that fits into what Perimeter X does. You know, when I think about edge, you know, scale concerns, security concerns are, you know, some of those top of mind as are just, you know, how. You know, can automation things like machine learning or AI help me? Cause usually that scale or a distributed nature of it means that it's not necessarily something that people alone could take care of themselves. Am I getting right, a little bit where Perimeter X is helping their customers? >> Yeah, yeah, yeah. And the idea is to connect, to help and to help offline offset some of the logic or some of the capabilities that, that you don't want your business to be an expert in. So if you're a retailer, you want to be able to sell the best to optimize accomodation for your customers and to handle that you don't want to be an expert in detecting bots or in identifying malicious code or things of that sort. And if you can offset that and with a lightweight, easy integration that does not limit your ability to innovate and adopt new technologies, this is what we're trying to help. Let us focus at this. But by integrating the edge by integrating with partners like Fastly and so that we can help enhance the infrastructure and add more capabilities, where you can focus on doing your own business and we can help allow and enable additional technologies. >> Along your serverless journey, what partners, what other vendors were helpful along the way? As I've looked at it, it's a relatively young ecosystem, but it's robust. So, you know, I'm curious who, some of the companies that have helped along the way? >> Yep. I think Fastly is definitely one that is from their earlier infrastructure. They always had the component of exposing their edge and making it more programmable via configuration and setting logic. And now rolling out a computed edge that is giving even more flexibility. Other CDNs are opening their edge as well with all kinds of tools, again, Lambda from AWS and other services. So this is one component of how do you manage that? How do you always read that? There are issues of how much state can you manage their access to data? And there are different services that allows that. Other platforms, which are more of the platform as a service that are not traditionally considered serverless. And you can think of it as eCommerce platforms helps you deploy your logic and some sometimes go to application into their ecosystem and helps you focus on again, managing your application. So think of Magento, think of a Salesforce cloud, these kind of commerce applications that you can deploy your logic. They're all fit into that ecosystem of help you. You want to write your code to that, your key on and let someone else manage the scale, let someone else manage some of the things that are common tool. >> Well, yeah, that's definitely one you see diversity of solutions at edge. You know, very different from if you were thinking kind of their traditional enterprise data center. Any, you know, as a CTO, when you look at edge, you know, where we were the maturation of this whole solution, or are there areas specifically that you expect in the next, you know, six, 12, 18 months that we will see some things solidify, mature down the line. >> Yeah. Yeah. So I think that the state where the edge compute is at now is more about deploying logic that is remote from the data center. So there is a limit. And if you look across different vendors to the more IO or data access capabilities of these loads. So if you can write the code and make it self sufficient, it's easier and it's more common to find platforms that will love it. What you're starting to see is how you add the data layer into that tier and making it more accessible. And that opens the gate for many more reach an interesting reputation, because once you can have a key value store, and once you can manage a state and modify configuration, you can then start deploying more complex applications and make more decisions. Do I see the billing system running entirely on the edge? probably not. There are things where you want to store it in the database. There are things that make sense to have it in some backend infrastructure, but a lot of payloads more and more environments are going there. And I think these additional services of queuing services, data services, database like services. So can, can I run a transaction on the edge? These kinds of technologies are currently emerging and you can see them in different levels for different vendors. And they will definitely open the gate even further for more and more patrons will be adopted at the edge. >> All right. Well, Ido last question I have for you, What advice would you give for your peers out there? as you said, you know, you were early in Docker adoption. You've done serverless adoption, you know, Edge is something that is gaining a lot of attention. What advice would you give to people here in 2020 as they look at, you know, the variety of Cloud Native options out there? >> I think the easy one is anything new that you build look around and figure out what is the best technology that can help you get there faster? And how can you build in a more strategic way for C-suite executive, if it's the CTO, CIO, CSO, think on how can you enable your team to move faster? How can you enable your team by the solutions and technologies that you select to have the flexibility of moving faster? how can you enable them to, to adopt new technologies and make it available? How can, and this is, you need some practices because you need to make sure that you are getting the right metrics. So whenever that you're using vendors that will help you collect and monitor the services and get the insights, because suddenly if anyone can deploy anything anywhere, then there is some concern about loss of control. So finding the right vendors that can help you or adopting the right processes that helps you gain this visibility while still enabling them to go anywhere. This is key. At least for us, it was key. And this is from wearing my product hat when we're building our services, this is what we're trying to enable our customers to do with this security. >> Well, Ido Safruti, thank you so much for sharing your journey, really appreciate you having on the program. >> Sure, thanks. >> And if you have people we should talk to, I would love hearing the stories of Cloud Native, how those adjustments are going and sharing your information with your peers. I'm Stu Miniman and look forward to hearing more your Cloud Native sites. (Calming music)