 Live from San Diego, California, it's theCUBE! Covering KubeCon and CloudNativeCon, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome back, this is theCUBE's coverage of KubeCon, CloudNativeCon 2019 in San Diego, 12,000 in attendance, I'm Stu Miniman, my co-host is John Troyer, and welcome back to the program, a multi-time CUBE alumni. Your Honor, Aviv, who's the CTO and co-founder of Iguazio, we've had quite a lot founders, CTOs, there's big brains at this show, your Honor, so let's start, there's really a gathering, there's a lot of effort building out a very complicated ecosystem. Give us first kind of your overall impressions of the show and this ecosystem. Yeah, so we're very early on on this ecosystem, we were one of the first batch of CNSF members when there were a few dozens of those, not like a thousand of those, so I've been to all those shows, we're part of the CNSF committees for different things and initiating, I think this has become much more mainstream, I told you before, it's sort of the new VM world, a lot more, all the infrastructure vendors along with middleware and applications that are coming here. So one of the things we like having you on the program, your Honor, is you don't pull any punches, so we've seen certain waves of technology come with big promise and fall short, big data was going to allow us to leverage everything and a large percentage of solutions had to stop or be pulled back. Give us, what's the cautionary tale that we should learn and make sure that we don't repeat? You know, so I've been in CTO for many years in different companies and what everyone used to say about me, I'm always right, I'm only one year off usually, I'm usually a little more optimistic, so you know, we've been talking about Cloudera and Hadoop World sort of going down and Kubernetes and cloud services essentially replacing them, we were talking about it four years ago and what you see that's actually happening, you know, with the collapse of MEPR and Hortenware going into Cloudera, things are going down. Customer are now telling us, we need equivalent solution for Kubernetes, we're not going to maintain two clusters. So I think in general, we've been picking on many of those friends, we've invented serverless before it was even called serverless with Nucleo and now we're expanding it further. And now we see the new emerging trends really around machine learning and AI. That's sort of the big thing. I'm surprised, you know, that's our space, we're essentially doing a data science platform as a service, fully automated around serverless constructs of people who can develop things really, really quickly. And what I see that, you know, third of the people I talk to are, have some relations to machine learning and AI. Yeah, maybe explain that for our audience a little bit because when, you know, Kubernetes first started very much an infrastructure discussion, but in the last year or two, very much application specific, we hear many people talking about those data use cases, AI and ML early days, but you know, how does that fit into the overall discussion? Yeah, but it's simple. You know, if you're moving to the cloud, there are two workloads. There's lift and shift workloads and there are new workloads, okay? Lift and shift, why bother moving them to Kubernetes? Okay, so you end up with new workloads. Everyone is trying to be cloud natives or elastic services and all that. Everyone have to feed data and machine learning into those new application. This is why you see those trends that talk about all data integration and various frameworks and all that in that space. So I don't think it's by coincidence. I think it's that's because new applications in corporate intelligence, that's why you hear a lot of the talk about those things. You're right. What I loved about the architecture, what you just said is like, people don't want to run another cluster. I don't want to run two versions of Kubernetes. You know, if I'm moving there, you're still built on that kind of infrastructure framework and knowledge of how to do serverless and how to make more nodes and fewer nodes and persistent storage and all that sort of good stuff and run TensorFlow and run all these big data apps. But you can talk about that just as the advantage to your customer because it seems like you could run it on top of GKE. You could run it on prem. I could run my own Kubernetes. You could just give me a stack. So we say Kubernetes is not interesting. I don't want anyone to get offended, okay? But Kubernetes is not the big deal. The big deal is organizations want to be competitive in this sort of digital world. They need to build new applications. All the ones are in sort of maintenance mode. And the big point is about delivering new applications with elastic scaling because your customers may be a million people behind some sort of app, okay? So that's the key thing. And Kubernetes is a way to deliver those microservices. But what we figured out, it's still very complicated for people, okay? Especially in the data science world, it takes about few weeks to deliver a model on a Jupyter notebook, whatever, and then productizing it is about a year. That's something we've seen. Between six months to a year to productize things that are relatively simple, okay? And that's because people think about the container, the TensorFlow, the CUDA driver, whatever, how to scale it, how to make it perform, et cetera. So what we came up with is, traditionally there's a notion of serverless, which is abstraction with very slow performance, very limited set of use cases. We said serverless is about elastic scaling, paper use, full automation around DevOps and all that, okay? Why cannot apply to other use cases of really high concurrency, high-speed batch, distributed training, distributed workload? Because we're coming, if you know my background, VP in Melanox and other high-performance companies, so we have a high-performance DNA. So we don't know how to build things that are extremely slow. It sort of irritates me. So the point is that how can we apply this notion of abstraction and scaling and all that to a variety of workloads? And this is essentially what Iguazu did. This is a combination of high-speed data technology for moving data around between those functions and extremely high-speed set of functions that work on the different domains of data collection and ingestion, data analytics, machine learning training and machine learning model serving. So a customer can come on our platform and we have testimonials around that, that things that they thought about building on Amazon or even on-prem for months and months, they built in our platform in few weeks with fewer people, because the focus is on building the application. The focus is not about tuning your Kubernetes. We go to customers, some of them are large banks, et cetera. They say, our IT likes Kubernetes, we have our own Kubernetes. So you know what? We don't bother. Initially, we used to bring our own Kubernetes, but then I don't mind. We do struggle sometimes because our level expertise in Kubernetes is way more sophisticated than what they have to say, okay, we've installed Kubernetes and we come with our software stack. No, you didn't. You didn't configure the security, you didn't configure Ingress, et cetera. So sometimes it's easier for us to bring, but we don't want to get into this sort of tension with IT. Our focus is to accelerate development on the new application that are intelligent, move applications from, if you think of the traditional data analytics and data science, it's about reporting. And what people want to do and some applications we've announced this week an application around real-time cyber collection, it's being used in some different governments is that you can collect a lot of information, a SMS, telephony, video, et cetera. And in real time, you could detect terrorists, okay? So those application requires high concurrency, always on rolling upgrades, things that weren't there in the traditional BI oracle, you know, kind of reporting way. So you have this wave of putting intelligence into more highly concurrent online application. It requires all the DevOps sort of aspects, but all the data analytics and machine learning aspects to come along. All right, so Yaron, speaking of those workloads, for machine learning, Kubeflow is the project moving that space along. Give us the update there. Yeah, so there is sort of a rising star in the Kubernetes community around how to automate machine learning workflow. That's Kubeflow. I'm personally one of the committers in Kubeflow and what we've done because it's very complicated because Google developed Kubeflow as one of the services on GKE, okay? And they tweaked everything. It works great in GKE, even that it's relatively new technology and people want to run it in a more generic. So one of the things in our platform is a managed Kubeflow that works natively with all the rest of the solutions. Another thing that we've done is we made it fully serverless. So instead of Kubeflow approach is very, you know, Kubernetes oriented, containers, the animals, all that. In our flavor of Kubeflow we can just create functions and you just like chain functions and you click and it runs. You've mentioned a couple of times, how does serverless as you define it fit in with Kubernetes? Is that working together just functions on top or I'm just trying to make sure we parse and understand? You'll hear different things. I think when most people say serverless, they mean sort of frontend application, things that are sort of low concurrency, et cetera. You know, when we mean serverless, we have eight different engines that each one is very good in different domain, like distributed deep learning, you know, distributed machine learning, et cetera. And we know how to fit the thing into any workload. So for me, we deliver the elastic scaling, the paper use, and the ease of use of sort of no DevOps across all the eight workloads that we're addressing. For most people it's like a single trick pony. And I think really the future is moving to that. And if you think about serverless, there is another aspect here which is very important for machine learning and is reusability. I'm not going to develop any algorithm in the world. Okay, there are a bunch of companies or users or developers that can develop an algorithm and I can just consume it. So the future in data science, but not just data science, is essentially to have like marketplaces of algorithms pre-made or analytic tools or maybe even vendors licensing their technology through sort of pre-packed solution. So we're a great believer of, forget about the infrastructure, focus on the business components and daisy chain them into a pipeline like your pipeline and run them. And that will allow you most reusability, the lowest amount of cost, best performance, et cetera. That's great, I just want to double click on the serverless idea one more time. But so you're developing, it's an architectural pattern and you're developing these concepts yourself. You're not actually, sometimes the concept gets confused with the implementations of other people's serverless frameworks or things like that. Is that correct? I think there are confusion. I'm getting asked a lot of times, how do you compare your technology compared to let's say K-native, you've heard the term. K-native is just a technology. Or open FAS. Or open FAS is a CGI server. It's an open community, it's very nice for hobbyists. But if you're an enterprise, you need security, LDAP integration, authentication for everything. You need UIs, you need CLIs, you need all of those things. So Amazon provides that with Lambda. Can you compare Lambda to K-native? No, K-native is I need to go from Git and build and all that. Serverless is about taking a function and clicking and deploying. It's not about building. And the problem is that this conference is about people, IT people, from people that like to build. So they don't like to get something that work. They want to get the Lego building block so they can play. So in our view, serverless is not open FAS or K-native. It's something that you click and it works and have all the enterprise set of features. We've extended it to different levels of magnitude of performance. I'll give you an anecdote. I did a comparison for a customer who was asking me the same question, not about K-native, but this time Lambda. How do you guys compare with Lambda? Now, Nukio is extremely high performance. We're doing up to 400,000 events on a single process. And the customer said, you know what? I have a use case, I need like 5,000 events per second. How do you guys compare, total across all my functions? How do you compare against Lambda? We went into the price calculator, 5,000 events per second on Lambda, that's $50,000. Okay, $50,000. We do about, let's say even in simple functions, 60,000 per process, $500 VM on Amazon. $500 VM on Amazon with our technologies, 60,000 transactions per second, 5,000 events per second on Lambda, that's 50,000. 100 times more expensive. So it depends on the design point. We design our solution to be extremely efficient, high concurrency. If you just need something to do a webhook, use Lambda. If you are trying to build a high concurrency application, efficient, an enterprise application on a serverless architecture construct, come to us. Yeah, so just, I'll posit this for you because it reminds me what you were talking about about the builders here. In the early days of VMware, to get it to work the way I wanted to, people need to participate and build it. And there's the Ikea effect. If I actually helped build it a little bit, I like it more. To get to the vast majority to adopt those things, it needs to become simplified and I can't have all the applications move over to this environment if I have to constantly tweak that and everything. So that's the trend we've been really seeing this year is some of that simplification needs to get there. There's focus on the operators, the day to operations, the applications so that anybody can get there without having to build themselves. So we know there's still work to be done, but if we've crossed the chasm and we want the majority to now adopt this, it can't be that I have to customize it. It needs to be more turnkey. Yeah, and I think it's a different in attitude between what you'll see in Amazon reinvent in a couple of weeks and what you see here because there is also the focus of we're building application. What kind of tools Andy Jess is going to just launch today on the floor, okay? So we can just consume it and build our new application. They're not thinking, how did Andy Jess, he built his tools, okay? And I think that's the opposite here. It's like, how is Istio working inside underneath the hood? Who cares about Istio, you know? You care about having connectivity between two points and all that. How do you implement it? Let someone else take care of it and then you can apply your few people that you have on solving your business problem, not on infrastructure. You know, I just met a guy, came to our booth. We've seen our demo, pretty impressive how we write few function and its scales and does everything automatically. He said, we want to build something like you're doing, you know, not really, like only 10% of what you just showed me and we have about six people and for three months we're just like scratching our head. I said, okay, you could use our platform, pay us some software license and now you'll get, you know, 10 times more functionality and your six people can do something more useful. He says, right, let's do a POC. So that's our intention and I think people are starting to get it because Kubernetes is not easy. Again, people tell me we installed Kubernetes, now install your stack and then they haven't installed like 20% of all the things that you need to install. Well, Yaron Jave, always pleasure to catch up with you. Thanks for all the updates and I know we'll catch up with you again soon. Sure. All right. For John Troyer, I'm Stu Miniman. We'll be back with more coverage here from KubeCon, CloudNativeCon in San Diego. Thanks for watching the Kube.