>> Announcer: Live from Copenhagen, Denmark, it's theCUBE! Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation and it's ecosystem partners. >> Welcome back, everyone. This is theCUBE's exclusive live coverage here in Copenhagen, Denmark for KubeCon 2018. I'm John Furrier with my cohost this week, Lauren Cooney, and our next guest, Ed Warnicke, distinguished consulting engineer with Sysco Systems, CUBE alum. Great to see you, welcome back to theCUBE. >> Good to be back. >> So great developer action, end of day one. We're going to be here all day tomorrow. So day one's kind of coming into the books. Your thoughts on what's happening here. Different crowd but active. >> No extremely active. Actually, one of the things I've noticed, and this is sort of a subtle point when you've been around a lot of open source projects is you have a lot of people who are new to the Kubernetes community are coming in. And one of the things I found extremely heartening is, they've got a really organized approach to it. When they did their developer summit, they had an entire track for bringing new contributors on. They've just revamped their documentation to help people that are here, and they're finding better and better ways to articulate the things that people need to hear to help them make the leap to Cloud Native. 'Cause one of the underappreciated things about Cloud Native is that it's different from the move to Cloud 1.0 that we made a few years ago, is that Cloud Native is not a lift and shift behavior. You have to change the way you think about doing your job. >> And that's the global platform. This is not just a transformation process. It's a lifetime transformation. >> Absolutely. >> Huge personnel issue. People process technology, technology last one. >> Ed: Have you accepted Cloud Native into your heart? >> I have come to terms with my-- (Ed laughing) lift and shift problem that I have, and I'm now aware, self-aware of Cloud Native. >> The first step is to admit you have a problem. (John chuckling) The making amends to your infrastructure takes longer. >> I mean, look if-- >> And you would know, so. (laughing) Well, anyways. >> We're all working on it. >> So, I have a question for you here. As you were talking about how you're seeing a lot of new developers coming on in and things along those lines. I'm also running into a lot of new developers at the hotel, at dinner, just walking around and having discussions. Where do you see these guys coming from? I see them coming from banks, from large technology companies that are based in Europe. Where are you seeing these folks? >> So that ends up matching very closely with what I'm seeing as well. From all over the place. From people who finance large energy projects, right? From all areas of finance. Basically, all the sorts of people who have big compute problems are starting to turn up at the Cloud Native world because this is literally where you solve those problems. And I think that's part of what's driving the ecosystem is, the folks in Kubernetes made a number of incredibly intelligent decisions early on about how their architecture was built in terms of the modularity and expandability of it. And the result is that you get lots of people with lots of energy coming in saying, "I have a problem like this." There's an obvious well-worn path to try and put together a proposed solution for solving problems like this. And they engage with the community. One of the things that you're seeing just in terms of how the community grows itself is, they've got special interest groups, SIGs for various areas in Kubernetes. They've now had to spawn working groups that come under them. You're just seeing things like Kubernetes proposals for how you're going to do things coming to far. So there's a lot of the maturity process that you expect to deal with the scale of people who want to solve their problems this way. >> So you're actually not seeing sprawl. You're seeing highly organized groups coming together in a way that can make the platform more positive. >> Yeah, absolutely. Not only am I not seeing sprawl, but I'm starting to see highly intelligent things being said by the people who work at what we think of as the core of Kubernetes. So I've heard a number of people make the comment that they expect the Kubernetes core to actually shrink in terms of what it offers because the broader ecosystem is picking up so much of the slack. So this sort of core APIs of, this is what is Kubernetes without having picked out some options that meet your needs, is keeping itself very tight while having architected it in a way where you could have this broad ecosystem without the kinds of problems you sometimes get with sprawl in other communities. >> So whilst you want to get bigger, but you've got to get smaller to get bigger. >> In some sense, yeah. You have to decide what's really important to get right in the core and really nail it. >> What are they getting right, in your opinion? What's right about it that's going on? You mentioned some of the smart decisions that they're making. >> So, a couple of the things that they've gotten really, really right are our relentless focus on developer needs. So I see this particularly in networking, and I think we've talked about this before. Developers don't want to know about subnets. They don't want to know about L2 segments. They don't even want to know about IP addresses, frankly. What they really care about is two things. Reachability and isolation. Everybody can talk to everybody unless they decide you should be isolated. And service discovery and service running. Those are the only two things they care about, and wouldn't you know it! In Kubernetes, you have network policies that control the reachability and isolation and services that do services discovery and service routing for you. So they've absolutely nailed the fundamental developer needs. >> Made you pain point. >> Yeah. >> So what's your take on just the ecosystem. Obviously, we've commented, and this is always a dangerous game with communities, is logo farm, everyone's here, right? >> Yeah, I mean, they took the CNCF logos and probably, I think they broke them into three categories now. I'm not exactly sure what that means. >> John: A whole new sponsorship level for-- >> Architecture? I'm not sure. (John and Ed laughing) But, Ed, maybe you could provide some clarity here. >> Well, I mean, there is a certain risk in being loved to death, right? Kubernetes is full blown into what I will sometimes call crises of success, which is, you are succeeding so wildly that it's beginning to be a problem. And that's good to see. But I think you're starting to see certain categories of things that are emerging. And there was a good set of readouts from the various SIGs to Kubernetes yesterday in the developer summit. So you've got a bunch of stuff around networking. You have a bunch of things around storage. These are sort of fundamental infrastructure issues. But you have a bunch of things, literally, about how so we expand the Kubernetes platform. How does that work? How do we produce the constructs we need to solve the various problems that are arising, and those things are all sort of progressively moving forward. And we're getting to sort of the interesting point where the people who did the original turn of the APIs are being really blunt and honest saying, "Look! "These are the things we got right, "and these are the things we got wrong." And there's a lot to be said for having that level of honesty with yourself on stage in public, right? When you're the guy who wrote the code, it's unequivocally your mistake. And being able to stand up and say, "Look, "we got this one wrong." >> But that's the community trust that you have, and that's what makes the community. >> And that trust goes both ways. It's the trust of the community in that leader standing on the stage, but it's also the trust of that leader that we're going to move fast, we're going to do things right, but there's always a turn of the crank to do things better. And we got to be straightforward about that. >> And their self-awareness around the iteration is key. They're putting their egos at the door, checking it at the door, focusing on the advancement. I got to get your thoughts, from both of you guys, I want to ask you guys both a question. I know that you're doing a lot a work with some start-ups, and you with Cisco, the big company. What's interesting about this ecosystem is, the balance between the big players and the enablement for the small start-ups to be successful. We had a variety of start-ups here with news on theCUBE. This is the give get between sharing in projects where there's a balance and everyone can thrive and survive and grow together. Thoughts on that balance. Start-ups have needs, but they're not as big as the big guys. So what's your thoughts on-- >> Why don't you start, Ed. >> Well, to begin with, we can't do everything much as we would like to. Back to the self-honesty, you have to be honest with yourself about that. And nobody has a monopoly on the good ideas. And so you really have to engage with the ecosystem and figure out how different aspects of the problem knit together. I've had a lot of interesting conversations. I, personally, have some interest in what I sort of call unified IO. So converged networking storage. So I'm talking to a lot of folks who are doing storage stuff, lot a little start-ups that are doing really cool things with storage about things we can do to help them there from the network side, and they're excited about that, right? And it's that, that's the sort of open source spirit that makes it possible to have all these start-ups because, I'll be really frank, most of these start-ups, if they were having to try and build the thing themselves, they're simply not resourced to do it. But with so much support from the community in the broad, on a relatively thin start-up budget, you can move mountains. >> Yeah, if you tap the formula properly, that's the key. >> The start-ups are getting more and more sophisticate about tapping that formula because only... Getting a good product is only a very small part of the equation. You also have to get the connection with the community because you have to make sure, even if you're entirely self-interested, if you build a thing, there will be a thing in the open source that does that. And it is a fundamental truth in the modern era that 80% of the value or more of all software is its connection to everything else in the ecosystem. >> Lauren, I want to get your thoughts on this. You're doing this now as a new start-up, you're a founder of and running, but you've built programs. Modern architectures at play here. You're seeing microservices growth phenomenal. Cloud Native is just whole nother ball game, going to a whole nother level. As you're engaging out there, what are you seeing for this modern community formula playbook, whatever you want to call it. There's a way to do things now at a whole nother level that this is going. >> No, I-- >> Your thoughts. >> I definitely agree. I think the developer experience is really key, making it simple, making it just seamless, right? So folks don't have to wait to download something, or they don't have to wait for, you know. They can just click a couple buttons through a GUI and make it really, really simple, especially those on-boarding. What I see from the start-up side is a lot of... This is interesting because I think it's important. A lot of start-ups coming from companies that wouldn't allow them to do open source inside the companies. So they're leaving these larger companies, and they're doing start-ups. They're raising pretty good capital for seed rounds and A rounds. And I think, this is something that's pretty hot right now and we want to take a look at. And the VCs are definitely looking. >> What about the big companies that we all know, obviously Cisco, IBM, you see Amazon here. They have huge scale. Even Microsoft has had developer programs been successful over the years, we all know that. What's the modern tweak that they're making that you're seeing work? >> Oh, I think it's the small teams. Adrian was on here earlier talking about microservices and micro-teams, and I think he's absolutely right. You have to have teams that are building these services that are moving quite quickly and doing it in a way that's rapid enough to keep up or be ahead of the market. >> The micro-team point, I think, is actually really apropos because... This is going to sound very engineering propellor-head, but the management overhead gets to be quite steep when you try and do anything with big teams, right? So you got to have very loose coupling to everything else in the system, which is exactly what Cloud Native is about. And that's what you see not only in the start-ups but you see these sort of hybrid approaches emerge, where you have a start-up that has a small team and another start-up that has a small team that's nearby and a large company like Cisco that has a small team, and there's an interaction between all of these. And we're sort of operating as the growing up of this larger team completely across boundaries. It'll resolve actual user problems. >> I think it's a historic time. I think you guys are right on. This is such an exciting time for, if you're an engineer, software developer, or anyone in large-scale systems, and building applications is going to a whole nother level. Look at blockchain right around the corner, decentralized applications is coming soon. We won't go there in this interview 'cause it's KubeCon, but I got to get your take. What's your view so far of what's working here, hallway conversations you're having? What are some of the things going on here that someone who's not here might want to know about? >> I tend to be very focused on networking things, so the thing that I'm most excited about that's happening here is, the entire world seems to be getting meshy, right? So there's a huge excitement around service mesh and Istio, which I think is extremely well-placed. The fundamental thing that's really happening there is, they're progressively taking parts of the problem that you're not good at if you're writing a microservice, and they're pulling them out into a sidecar envoy so that you don't have to worry about service discovery and service routing. You don't have to worry about the policies for how you're going to figure out what things you do about getting to the next guy in the chain of the work. You don't have to worry about even things as simple as making sure that you respond to faults well, right? And there's a whole new set of ways that you think about problems in this space that's emerging there. One of the things that I'm actually really excited about that's also meshy is when you get to things like people who have less common network problems. So the operators with NFV, people who have more sophisticated network needs. We're starting to reimagine that stuff in the language of service mesh, right? So rather than trying to force all the legacy thinking about networking into Cloud Native where it's not wanted, we try and recast the problems we have into Cloud Native ways of thinking about them. And I think that ends up being intensely powerful. It's, frankly, almost overwhelming because there's so much conceptually going on in this space that you want to be able to draw on for the palette for the things that you're painting. >> Yeah, I mean, it's your point earlier about, and you were kind of joking but serious. This is a mind melt, you got to buy in to the philosophy of this new era of... (Ed laughing) Yeah, just kind of buy into, the Cloud Native is a global platform. It is a fundamental new thing. It's not just a methodology, it's a new way. >> It's a new way of thinking about things. The C in Cloud Native does not stand for container. Container is the smallest possible chunk of this. If you just slap all your applications into containers and try and do a lift and shift, you're going to fall on your face really hard. >> John: In what areas? Just like, what? >> Well, I'll give you a really simple example. Let's say that I have an application that I'm running in vApps, right? And I've got my big database VM. I've got my big web front VM. So I pick them up, I containerize them, I drop them into Kubernetes. So I've got one replica of my database VM and one replica of my web front VM, and that's going to break sometime in the first 24 hours. Because I need to, basically, pick them up and say, "OK, I need a bunch of replicas that are dynamically coming up for all of these things. I need the services to wire mesh them together." So for whatever reason, I lose some number of my replicas, that everything comes back up and goes forward and we never even notice, right? In some sense, the ideal situation is, you have a major bug in your code, right? Let's say you have a piece of code that's leaking memory and it dies every 24 hours. You want, if you think about it right and you deploy it 'cause you don't know you have this bug, you won't even notice that you screwed up that bug because the infrastructure will protect you from it. But if you just try and lift and shift, you're not going to have a happy experience because it's not going to work the way you expect it to. >> And then monitoring tools are getting better, too, and so if you're coming in on the other side you get that. Well, and thanks so much for the commentary. Great, great summary of the event. Any surprises here for you? Any ah-ha moments or revelations or epiphanies or any kind of surprises, good or bad or ugly? >> One of the things I was very impressed with is, I'm very impressed with what you can do with no code. I don't know if you saw that keynote this morning. >> Lauren: With Kelsey. >> In response to Dan Kohn's point about all the sort of total attack surface area. Kelsey got on stage and did the no code project, which has perfect security for whatever it is that you deploy it for. The fact that you can get on code, do something like that, move an entire audience of thousands of people, that's impressive. You don't see speakers who do that very often. That was, I wouldn't say shocking, but very much a pleasant surprise. And it speaks very much to the code of the community. The keynotes today were some of the best I've ever seen. I am not a keynote person, I seldom attend them. The keynotes today were extremely well-done. They had good energy and they were relevant. The walking through of the evolution of the community in brief punctuated explanations of what's going on and why they're important, I've never seen it done better. >> Yeah, they were hitting their marks well. Well, great, thanks for coming on, Ed. Great to see you. >> Yep. >> Thank you, Ed. >> This is commentary from Copenhagen, Denmark. It's theCUBE coverage of the CNCF, Cloud Native Compute Foundation, part of the Linux Foundation, KubeCon 2018 in Europe. I'm John Furrier, Lauren Cooney. Thanks for watching. Be right back. (electronic musical flourish)

(cheerful music) >> Announcer: Live from Los Angeles, it's theCUBE! Covering Open Source Summit North America 2017. Brought to you by The Linux Foundation and Red Hat. >> Welcome back, and we're live here in Los Angeles. This is theCUBE's special coverage of Open Source Summit North America. I'm John Furrier with Stu Miniman. Two days of wall-to-wall coverage. Our next guest, Ed Warnicke, who is a distinguished consulting engineer with Cisco. Welcome to theCUBE. >> Glad to be here! >> Thanks for coming on. Love to get into it. We love infrastructure as code. We love the cloud developers. The young generation loves it. Making things easy to use all sounds great, but there's still work to get done. The networking... So what's going on here at the Open Source? So this is the big tent event where there's a lot of cross-pollination around projects. Obviously the networking side, you guys at Cisco are doing your share. Give us the update. Networking is still a lot more work to be done. It's a very strategic part of the equation. Certainly making it easier up above makes it programmable. >> Yeah, you have to make the networking invisible even to the DevOps layer. There are certain things that you need from the network. They need isolation and reachability. They need service discovery and service routing. But they don't want to have to think about it. They don't want to be burdened with understanding the nitty gritty details. They don't want to know what subnet they're on, they don't want to have to worry about ACL's, they don't want to think about all of that. And the truth is, there's a lot of work that goes into making the network invisible and ubiquitous for people. And in particular, one of the challenges that we see arising as the world moves more cloud-native, as the microservices get smaller, as the shift happens toward serverless, as Kubernetes is coming on with containers, is that the network is really becoming the run time. And that run time has the need to scale and perform like it never has before. So the number of microservices you'd like to put on a server keeps going up, and that means you need to be able to actually handle that. The amount of traffic that people want to push through them continues to go up. So your performance has to keep up. And that brings a lot of distinct challenges, particularly when you're trying to achieve those in systems that were designed for a world where you had maybe two NIC's on the box, where you weren't really thinking when the original infrastructure was built about the fact that you were actually going to have to do a hell of a lot of routing inside the server because you now have currently hundreds, but hopefully someday thousands and tens of thousands of microservices running there. >> Ed, you know, I think when we've been talking about the last 15 or 20 years or so, I need to move faster with my deployment. It always seemed that networking was the thing that held everything up. It's like, okay, wait, when I virtualized, everything's great and everything, and I can just spit up a VM and do that. Oh, but I need to wait for the network to be provisioned. What are the things you've been working on, what open source projects? There's a lot of them out there helping us to really help that overall agility of work today. >> Absolutely. So one of the things I'm deeply involved in right now is a project called FD.io, usually pronounced Fido, because it's cute. And it means we can give away puppies at conferences. It's great. What FD.io is doing, is we have this core technology called VPP that gives you incredibly performant, incredibly scalable networking purely in user space. Which means from a developer velocity point of view, we can have new features every three months. From an extensibility point of view, you can bring new network features as separate plugins you drop as .so's into a plugin directory instead of having to wait for the kernel to rev on your server. And the revving process is also substantially less invasive. So if you need to take a microservice network as a user space thing and rev it, it's a restart of a process. You're talking microseconds, not 15-minute reboot cycles. You're talking levels of disruption where you don't lose your TCP state, where you don't lose any of those things. And that's really crucial to having the kind of agility that you want in the network. And when I talk about performance and scalability, I'm not kidding. So one of the things we recently clocked out with VPP was being able to route a terabyte per second of traffic with millions of routes in the forwarding tables on commodity servers with no hardware existence at all. And the workloads are starting to grow in that direction. It's going to take them a while to catch up, but to your point about the network being the long pull, we want to be far ahead of that curve so it's not the long pull anymore. So you can achieve the agility that you need in DevOps and move innovative products forward. >> Ed, one of the things that comes up all the time, I wanted to get your reaction to this because you're an important part of it, is developers say, look, I love DevOps. And even ops guys are saying, we want to promote DevOps, so there's a mind meld there if you will. But then what they don't want is a black box. They want to see debugging, and they want to have ease of manageability. So I don't mind pushing dev, if I'm an ops guy, send the dev down, but they need a path of visibility. They need to have access to debug fast. Get access to some of those things. What do you see as gates if you will, that we got to get through to make that seamless and clean right now? Obviously Kubernetes, lot of stuff going on with orchestration. And containers are providing a path. But still, the complaint and nervousness is okay, you can touch and program the infrastructure, but if something happens, you're going to be reactive. >> Yeah, that gets exactly to the point. Because the more invisible the network is, the more visibility you need when things go wrong. And for general operational use. And one of the cool things that's happening in FD.io around that, is number one, it's industrial scale. So you have all sorts of counters and telemetry information that you need from an historical point of view in networks to be able to figure out what's going on. But beyond that, there's a whole lot of innovation that's been happening in the network space that has yet to trickle down all the way to the server edge. A really classic example on the visibility front has to do with in-band iOAM. So we now have the technology, and this is present today in VPP, to be able to say, hey, I would like an in-band trace on the flow though the network of this flow for this customer who's giving me a complaint, where I can see hop by hop through the network including in the edge where VPP is, what's the latency between hops? What path it actually passed through. And there's even a feature there where you could say, at each hop, please send the packet capture at that hop to a third-party point where I can collect it so I can look at it in something like Wireshark. So you can look in Wireshark and say, okay I see where this went into that node and came out that node this way. Node by node by node. I don't know how much more visibility than that is actually physically possible. And that's one of the kinds of things that the velocity of features that you have in VPP has made very possible. That's the kind of thing that would take a long time to work into the traditional development line for networking. >> What's the Cisco internal vibe right now? Because we covered the DevNet Create event that Susie Wee put on, which was kind of like a cloud-native cool event. Kind of grassroots, kind of guerrilla. I love the mojo there. But then you've got the DevNet community at Cisco, which is a robust killer developer community on the Cisco side. How are those worlds coming together? I can imagine that the appetite for the Cisco DevNet teams, the DevNet developer community, is looking at cloud-native as an opportunity. Can you share some insight into what's the sentiment, what's the community vibe, what's going on? For folks that just got to run the networks, I mean this is serious stuff. In the past, they've been like, cloud-native, when you're ready we'll get there. But now there seems to be an onboarding of cloud-native. Talk about the dynamic. >> There has to be, because cloud-native won't wait. And there's a lot of things that the network can do to help you as the run time. The iOAM example is one, but there are a ton more. Again, cloud-native won't wait. They will find a way, and so you have to be able to bring those features at the pace at which cloud-native proceeds. You can't do it on six-month product cycles. You can't do it on 12-month product cycles. You have to be able to respond point by point as things more forward. A good example of this is a lot of the stuff that's happening with server meshes in Insteon. Which is coming really fast. Not quite here, but coming really fast. And for that, the real question is, what can the network do for DevOps? Because there's a synergistic relationship between DevOps and NetOps. >> So you were saying... Just to try to get at the point. So yes, are you seeing that the DevNet community is saying hey we love this stuff? Because they're smart, they know how to adapt. Moving from networks to DevOps. To me it seems like they're connecting the dots. You share some-- Are they, yes no maybe? >> They're absolutely connecting the dots, but there's a whole pipeline with all of this. And DevNet is at the short pointy end where it touches the DevOps people. But to get there, there's a lot of things that have to do with identifying what are the real needs, getting the code written to actually do it, figuring out the proper innovations, engaging with open source communities like Kubernetes so that they're utilized. And by the time you get to DevNet, now we're at the point where you can explain them to DevOps, where they can use them really cleanly. One of the other things is, you want it to come through transparently. Because people want to be able to pick their Kubernetes Helm charts off the web, take the collection of containers for the parts of their application they don't want to have to think about, at least right now, and have it work. So you have to make sure you're supporting all the stuff that's there, and you have to work to be able to take advantage of those new features in the existing API's. Or better yet, just have the results of those API's get better without having to think about new features. >> So they're in great shape. It's not a collision, it's not friction. >> No, no no. >> It's pretty much synergistic. Network guys get the DevOps equation. >> No, we get the DevOps equation, we get the need. There is a learning process for both sides. We deeply need each other. Applications without networking are completely uninteresting. And this is even more true in microservices where it's becoming the run time for the network. On the same side, networks without applications are completely uninteresting because there's no one to talk. And what's fascinating to me is how many of the same problems get described in different language and so we'll talk past each other. So DevOps people will talk about service discovery and service routing. And what they're really saying is, I want a thing, I don't want to have to think about how to get to it. On the network side, for 15 years now, we've been talking about identifier/locator separation. Basically the having an IP address for the thing you want, and having the ability to transparently map that to the location where that thing is without having to... It's the classic renumber your network problem. They're at a very fundamental level the same problem. But it's a different language. >> The game is still the same. There's some language nuances that I think I see some synergies. I see people getting it. It's like learning two languages. Okay, the worlds come together. It's not a collision. But the interesting thing is networking has always been enabling opportunity. This is a fundamental nuance. If you can get this right, it's invisible, as you said. That's the end game. >> Absolutely. That's really what you're looking for. You want invisibility in the normal mode, and you want total transparency when something has to be debugged. The classic example with networks is, when there's a network problem it's almost never the network. It's almost always some little niggle of configuration that went wrong along the way. And so you need that transparency to be able to figure out okay, what's the point where things broke? Or what's the point where things are running suboptimally? Or am I getting the level of service that I need? Am I getting the latency I need, and so forth. And there's been a tendency in the past to shorthand many of those things with networking concepts that are completely meaningless to the underlying problem. People will look at subnets, and say for the same subnet, we should have low latency. Bullshit. I mean basically, if you're on the same subnet, the guy could be on the other end of the WAN in the modern era with L2 overlays. So if you want latency, you should be able to ask for a particular latency guarantee. >> It felt to me that it took the networking community a while to fix things when it came to virtualization. (Ed laughs) but the punch line is, when it comes to containers, and what's happening at Kubernetes, it feels like the networking community is rallying a lot faster and getting ahead of it. So what's different this time? You've got kind of that historical view on it. Are we doing better as an industry now, and why is it? >> So a couple of things. The Kubernetes guys have done a really nice job of laying out their networking API's. They didn't get bogged down in the internal guts of the network that no DevOps guy ever wants to have to see. They got really to the heart of the matter. So if you look at the guarantees that you have in Kubernetes, what is it? Every pod can talk to every other pod at L3. So L2 isn't even in the picture. Which is beautiful, because in the cloud, you need to worry about subnets like you need a hole in the head. Then if you want isolation, you specify a network policy. And you don't talk about IP addresses when you do that. You talk about selectors on labels for pods, which is a beautiful way to go about it. Because you're talking about things you actually care about. And then with services, you're really talking about how do I discover the service I want so I never have to figure out a pod IP? The system does it for me. And there are gaps in terms of there being things that people are going to be able to need to do that are not completely specified on those API's yet. But the things they've covered have been covered so well, and they're being defended so thoroughly, that it's actually making it easier because we can't come in and introduce concepts that harm DevOps. We're forced to work in a paradigm that serves it. >> Okay, great. So this'll be easy, so we'll be ready to tackle serverless. What's that going to mean for the network? >> Serverless gets to be even more interesting because the level of agility that you want in your network goes up. Because you can imagine something in serverless where you don't even want to start a pod until someone has made a request. So there's an L7 piece that has to be dealt with but then you have to worry about the efficiency of how do you actually move that TCP session to the actual instance that's come up for serverless for that thing, and how do you move it to the next thing? Because you're working at an L7, where from the client's point of view, they think it's all the same server, but it's actually been vulcanized across all these microservices. And so you have to find an efficient way of making that transparent that minimizes the degree to which you have to hairpin through things all over the cluster because that just introduces more latency, less throughput, more load on the cluster. You've got to be able to avoid that. And so, by being able to bring sophisticated features quickly to the data plain with something like FD.io and VPP, you can actually start peeling those problems off progressively as serverless matures. Because the truth of the matter is, no one really knows what those things are going to look like. We all like to believe we do, but you're going to find new problems as you go. It's the unknown unknowns that require the velocity. >> So it sounds like you're excited about serverless, though. >> Ed: Usually, yes, definitely. >> So I love serverless too, and I always talk about it. So what is in your opinion the confusion? There are some people who are like, oh it's bullshit. I don't think it is personally. I think it's nirvana. I think it's what people want, what most developers want. There's a server behind it. It's not serverless per se. It's just from a developer standpoint, you don't have to provision hardware. >> Or containers, or VM's, or any of that. >> I personally think it's a good thing. Is it just a better naming convention? Give the people, what's the nuance? Why are people confused? >> I think it's much more fundamental than just the naming convention. Because historically, if you look at the virtualization of workloads, every movement we've had to date has been about some workload run time technology. VM's were about virtual machines. Containers are about containers to run technology. When you get to microservices and serverless, we've made the leap from talking about the underlying technology that most developers don't care about to talking about the philosophy that they do. >> Their run time is their app. Their run time assembly is their code sandwich, not to say the network. >> Just as in serverless, I don't think anyone doubts that the first run of serverless is going to be built on containers. But the philosophy is completely divorced for them. So I'll give you an example. One of the things that we have in VPP is we have an ultra high performance, ultra high scalability userspace TCP stack. We're talking the kind of thing that can trivially handle ten million simultaneous connections with 200,000 new connections coming in every second. And right now, you can scope that to an isolation scope of a container. But there's no reason, with the technology we have, you can't scope it all the way down to a process. So you control the network access at the level of a process. So there's a lot of headroom to go even smaller than containers, even lighter weight than containers. But the serverless philosophy changes not a wit as you have that improvement come in. >> That's beautiful. Ed, thanks so much for coming on theCUBE. We really appreciate your perspective. I'd like you to get one final word in to end the segment. Describe what's happening here because the OS Summit, or the Open Source Summit, is the first of its kind, a big tent event. What's your take on it? What's the purpose of the event? What's your experience? Share with the folks who aren't here what this event is all about. >> It's really exciting, because as much as we love The Linux Foundation, and as much as we've all enjoyed things like LinuxCon in the past, the truth is, for years it's been bleeding beyond just Linux. I don't see the OS Summit so much as a shift in focus, as a recognition of what's developed. Last year we had the Open Source Summit here. We just called it LinuxCon. The year before we had the Open Source Summit here. We just called it LinuxCon. And so what's really happening is, we're recognizing what is. There's actually no new creation happening here. It's the recognition of what's evolved. >> And that is open source as a tier one reality that goes way beyond Linux, which is by the way super valuable at the kernel. >> Ed: Oh, we all love Linux. >> All Linux apps... The only apps are Linux apps. But it's a bigger thing. The growth and scale that's coming is unprecedented. I think a lot of people still are pitching themselves, Stu and I were commenting, that what's coming is going to change the face of software development for generations to come. There's an exponential scale of software libraries coming on board. Up to 400 million was forecast by 2026? >> That sounds conservative to me. (laughs) >> You think so? Well, I mean, just to get the scale. So there's going to be some leadership opportunities for the community, in my opinion. >> Absolutely. And this is where the Open Source Summit actually... I mean, words matter because they shape the way we think about things. So where I think the shift to the Open Source Summit has huge value is that it starts to shift the thinking into this broader space. It's not just a recognition of what's happened. It's a new load of software here for the community. >> This is not a marking then, it's a recognition of what's actually happening. I love that quote. Open Source Summit, brilliant move by The Linux Foundation. Create a big tent event for cross-pollination, sharing of ideas. This is the ethos of open source. Ed, thanks so much for coming on theCUBE. This is theCUBE with live coverage from the Open Source Summit in North America, formerly LinuxCon and all the other great events here in Los Angeles. I'm John Furrier with Stu Miniman. More live coverage after this short break. (electronic music)

>> Narrator: Live, from Copenhagen, Denmark, it's theCube. Covering KubeCon and Cloud Native Con Europe 2018. Brought to you by the Cloud Native Computing Foundation and its ecosystem partners. >> Hello, everyone, welcome back to theCUBE exclusive coverage of CNCF. The Cloud Native Foundation, Compute Foundation, part of the Linux Foundation of KubeCon 2018 here in Copenhagen, Denmark. I'm John Furrier co-host of theCUBE here with analyst this week Lauren Cooney, who is the founder of Spark Labs, brand new start up that she founded to help companies bring innovation to Cloud Native, bring in all of her expertise to companies. Also, here on theCUBE, Lauren, great to have you this week. >> Thanks, John. >> Here in Europe, you've done so much work in the area of open source over the years. You've done, you were radical renegade, progressive, pushing PHP, bringing that to Microsoft. Doing a lot of great things, and now we're in a new modern era, and you're bringing that expertise, but you're also on the front lines of the new wave. >> Lauren: Definitely. >> Cloud Native, so what's your take? What's your analysis? I mean, there's so much going on. You can't just retrofit old school open source, but it's got to build on the next generation. What's your thoughts? >> It has to build on the next generation, but you also have to look back at what has happened in the past. I think what is incredibly important to see is the mistakes that have been made in the past, so that people don't repeat them. One of the things that I'm seeing here and hearing a lot about is multiple distributions of Kubernetes out there, and when I hear multiple distributions I get worried that they're going the open sack route and there is going to be too many distributions out there. I would rather see one or two standard become kind of more standard and people building on top of that. I think it's the right way to go versus the splintering of the community. If the community is going to stay together you're going to have to narrow that down. >> What's the rationale for the distribution? Because, we've seen this before. Certainly at Hadoop, we saw people come out with distros and then abandon them, and then people coalesce around. >> Oh, they'll just die on the vine. I mean, fundamentally they just will die on the vine. It won't be, if it's not de facto already you're probably not going to get it de facto. >> John: What should companies do? Should they have a distro down. >> They should map to one of the key distros right now. They should, basically, use what is out there already. The one that they feel is right, and for their users, and for their company long term. >> I really enjoyed a couple of interviews we had yesterday. I want to just kind of revisit a couple of them. Tyler and Dirk, we had Tyler on from the new programming language ballerina that was launched. He's part of WSO2. Dirk is from Vien, where former early Linux guy, Linux foundation guy, worked with Linux tarballs in the early days. These guys know up the source. So you look at some of those leaders, and they say, "Hey, this is about the people" What are the things that we can draw from the past that are still relevant today? As the new formula of Kubernetes horizontally scalable cloud, Cloud Native thousands and, potentially, millions of micro-services coming online, new kinds of dynamic policy based infrastructure software, everything's coming. >> Service mesh, can't forget service mesh. >> Service meshes are going to be huge. What do we have to keep and preserve, and what is being built out that's new? >> Well, I think that you need to preserve the feeling of the community and what's going on there. I mean, these communities, actually it's communities not community, and these folks are coming along for the wave right? And I think it's important to make sure that people are aware of that, and there's lots of different personalities and lots of different goodness that can be brought to the table with that and the recognition of that. I also think that, for the most part, I do believe that this is one of the strongest communities out there, and it will continue to be for a number of years. >> I want to get your thoughts on something Ed Warnicke said from Cisco because he was very complimentary of the CNCF as are other people, and we have been complimentary as well about keeping everything tight to the core and allowing people to innovate. So you have, and we have commented on theCUBE and other KubeCons about this, and they've been doing it, which is let the innovation foster on the technical side as well as let people flex their business model opportunities. >> Lauren: Definitely. >> Not so much just for the sake of commercialization because if you have too much commercialization you might stunt the community of growth organically so there's a balance, and I think CNCF has done a good job there, but they've kept the core of Kubernetes really tight which has allowed the de facto standard approach to be Kubernetes. That has created great opportunity, and people are super excited by that. What's your analysis of what happens next? What needs to happen? What's the momentum phase two of this? >> I think part of it is, how do you monetize, right? It's looking at, and this is part of what Spark Labs actually does, is we actually work with companies, some that are in the CNCF, and we work on them in different ways to monetize. Is it a services wrapper that's going to work? Is it additional features or functionality? The innovation comes with the technology, but with that technology you have to have the business model kind of in mind when you're building this out so you can figure out how to make money. As these smaller companies especially are looking to do and some of the bigger companies as well. >> I really think it's important for the CNCF and the Linux foundation and I know they're on this so its not critical analysis so much as it is more of an observation. You have a long tail of start ups and kind of a fat tail if you will, that are out there, and you have the big whales out there Google, Microsoft, Amazon, and others at the top. There was a comment in Austin, a snarky comment. I won't say by who, but I was looking at the logo board of the sponsors, and the guy said, "All those start-ups, they might be dead in 18 months" and it made me pause and say okay, that's an observation because they were brand new companies. >> Lauren: Mm hmm. >> That can't happen. We need to have a model of preservation for start-ups to experiment, to grow. This is something you're doing at Spark Labs so what's your view of this? And, reaction to the fact that this has to happen. What can we do as an industry and community to make sure the start ups-- >> I think the Linux foundation is doing one of the best things that can be done out there. Other open source foundations do too. Is they create the infrastructure so that folks have the support for marketing, or legal, or something along those lines, but so companies are allowed to innovate and then the Linux Foundation basically bets on the innovation and they bet on multiple innovations with multiple companies so they allow these companies to thrive while giving them the support inside of that. >> John: Yeah. >> And I think that's really helping a lot of these companies along. >> Well, Dave Collins always says is the membership organization, so no members no business model so I mean they're incented to make sure that, or hope, that these guys can survive, and certainly there's going to be some misfires and people will natural evolution. So what are you most excited about? I got to ask ya, I mean you're out on your own now. Congratulations, you started up. >> Thank you. >> Super exciting for you and I'm happy that you're going to go out on your own. What are some of the things you're excited about? What are you digging your teeth into, in terms of projects? Share what you're doing. >> I'm super excited about these companies that are coming out with true multi-cloud. So, allowing applications to run across multiple environments, public, private, et cetera. And we've been saying we can do it for a decade or something like that, but fundamentally that wasn't the case. You did have to re-write code. You did have to do a lot of underlying things to make that occur. One of the things that I'm super excited about is being able to take those companies and figure out how to actually get their product to market faster. Some of these guys are still in stealth. They need to move really fast if they want to catch up. I also love working with them on figuring out how to build out their teams, figuring out how to monetize. What are the next steps? What are the business plans, really, behind this? What is the one, three, five year model that they're going to use? I also love helping them get the money, of course. I think that's the fun part too. >> Yeah, it's always fun. Start-ups are great. What I'm excited about, I got to tell ya, I got to share with you just some personal feelings. I love this market right now because I've seen many waves of innovation and I think this wave of cloud native, whatever you want to call it this massive wave or sets of waves coming in and you got blockchain and other things going on behind it these centralized applications which I think is part of this set coming in, is that it's bigger than all the other waves combined and because there's so much value creation on the horizon and I think historically, this moment in time, historically is going to be a point we're going to look back and say the Kubernetes de facto standard galvanized a set of industry, a new card of players who are going to establish a new way methodology of doing things, and we're documenting it. Secondly, the role of community, as you pointed out, is so important here, and it's strong, but now we're living in a new age of digital. We're seeing formations of new kinds of community engagement digitally, not just the events, so I'm excited with theCUBE and what we're doing here, and what the Linux Foundation is doing because there's now going to be, potentially, exponential growth and acceleration around the combination of community. >> Yup. >> The community growth with this new modern commercialization on digital. >> It's definitely increasingly important, and you have to look at it from the technologies making it happen. The technology is looking at, edge computing is going to make digital happen really when you look at all the end points and things along those lines. And, I think that it's going to be great for everyone involved in that. >> Yeah, and we can learn a lot from looking at the Facebook example of how fake news swayed the election. How people were weaponizing content for bad things. There's also an opposite effect, we believe that you can do the for good. >> Lauren: Totally agree. >> I think digital will have a big role in the next generation community formations, community growth, short cuts to the truth, really that's what it's all about. It's about the people, so certainly we're going to be documenting it. Thanks for your commentary. >> Lauren: Definitely. >> Appreciate it, great to work with you this week. Day two of exclusive coverage, here at the Linux Foundation's Cloud Native Compute Foundation's, CNCF's KubeCon 2018. This is where Kubernetes, service mesh, Istio a lot of great projects, from a lot of smart people. We're here on the ground covering it live. Day two, we'll be back with more coverage. Stay with us for day two coverage, after this short break. (electronic music)