 This is great to be here. Actually, I originally was going to give the VC-like talk about trends and this and that, and do a high-level talk. But I realized that it's almost been 10 years to date since we started Nasera, almost to the date. And a few months ago, they announced that NSX, which is kind of a ventral product that was created, reached a billion-dollar run rate. And so that kind of got me to be a little nostalgic and started looking back. And I thought, you know, it would kind of be interesting to do kind of more of a personal narrative of what I learned during all of that. Because I really did change the way that I thought. And so what I'd like to do is I'd like to talk about kind of a personal arc on making SDN real. So for those of you that don't know, so I was at Stanford from 2003 to 2007. I did some original work that became OpenFlow. I was working with Guru and Nick and Scott and so forth. And when I graduated in 2007, we decided to start Nasera, which was a company in the SDN space. And so I started to dig through our early slide deck. So this is one of our early slides. We were working networking for a pitch deck to pitch to VCs, which I am now. This is one of our old logos. I think we went through four logos. And the original pitch was very much the original SDN pitch. We're like, OK, there's two problems here. So problem number one is that if you look at the industry, we tie specific, even customer level functionality down to hardware. Take, for example, security. Every time we have, like, say, a new security thing, we're changing the frame format, and then all of a sudden we need a hardware refresh. And so this just goes against these massive trends toward software, for many aspects. And then the second problem is when it comes to operational control from an operator standpoint, not an innovator, but an operator standpoint, it's very box-centric. And in broad networks, this doesn't make a lot of sense. So let's go ahead and tackle that as well. And of course, our solution, we were academics. We popped out of Stanford. Was like, OK, we're going to solve this problem in generality. We're going to build this network-wide operating system. And these functions, these customer-facing functions that were in hardware now become applications. If you want security, we'll build a security application. You want virtual networking? We'll build a virtual networking application and so forth. All right, so to distill it down, features tied to hardware, operation tied to a box, build a general platform. As far as an initial entree point, we thought we were going to go into the virtual data center. The reason for this is the operational problem was particularly acute. I mean, VMs had a very different lifecycle than hardware servers. And so the network operators there were a lot less happy than in other parts of the network. And they were greenfield. We're getting a lot of these being built out. They would signal early adopters. And then we figured we'd go into campus and WAN and everything else. All right, so like good computer scientists, we figured, OK, we're going to build this general platform and then build on top of it. And so we built this thing called NOX, which is this kind of open-swersy, general SDN controller. And our idea for an abstraction was like, OK, we'll give programmers a graph. And then we're going to give them all of these great tools to operate on that graph. They'll have routing protocols. They'll have state management stuff. And so we gave them all of these things. And then they can build really interesting functions on top of that. And I would say about six months into this, we came up with two realizations. The first one, and this one never left. It still hasn't left me, which is networking is not computing. Computing solves science. And it solves entertainment. And it solves all of these broad physical problems. Networking is fundamentally about distributed state management. Like almost any network function that you look at, that's what it does. And so I think that we've taken an approach to the problem where we're like, OK, we want to help developers solve general computing problems when really the complexity is distributed state management. And I think as a result of, or almost a corollary of this, we're like, OK, so I'm going to give you kind of a centralized, or we use logically centralized, which didn't really even mean anything. We're going to kind of somehow reduce the complexity of distributed computing by maybe giving you one server. Maybe there's kind of some cheats we can do. Maybe can you use two or three servers, but that's good enough. And what we soon realize is because this problem is about distributed state management. And for networking is inherently an n cubed problem. You've got n things talking to n things, so you need to scale. So if you're going to handle a network of any size, you're going to have to really distribute. And it seems to us that if you solve n equals 3, your code complexity is equivalent to n. I mean, there's almost kind of in the general sense, not in a special case sense, but if you're building a general platform, you need to solve the full complexity of distribution in the platform. All right, so we're like, OK, fine. Here's what we're going to do. We're going to build a new platform. And this new platform is focused just on the problem of distributed state management and distribution. So this is another slide deck. I think this one is from 2008. When you're doing a startup, by the way, you're always fundraising and always pitching. So I've got this nice chronology of all of our pitch decks from the 10 years that we did this. And so the idea of ONIX was to say, OK, here's what we're going to do. We're building this platform. And then this platform, all of the support to the developer is to make it easier to do distributed state management. Now, the graph was a good idea. That was a great idea from ONIX. So you get a graph. Developers get a graph. And then that graph could be stored in a number of distributed data structures. And it's your choice. You can use a DHT. You can use some NoSQL-y thing. You can use an RDBMS. And it's fully distributed. And that will, the distribution, be handled by those mechanisms. And then to operate on that graph, we're going to give you a bunch of tools. We'll give you locking, and leader election, and so forth. And so now, you can have whatever you need to implement what you want. So there is definitely some value there. And I think the primary value is you have a number of networking people that are used to basically only eventual consistency and protocols. And you've introduced them to a number of new tools. So there's a lot of value there. But the reality is, and again, this is another one of these lessons that's really stuck with me, there really is no networking problem, per se. It's like almost every aspect of the network is different. Like, the data center problem is entirely different than the mobile problem is entirely different than, let's say, the WAN problem. And all of these have different requirements and trade-offs when it comes to consistency and scalability. So it's very difficult to fundamentally reduce complexity in this type of platform. So you can package up tools for people. You can make a nice development library. You can introduce people to new concepts. But the actual code complexity stays the same, because you have to surface the same level of generality. Does that make sense? Like, you can't reduce the set of options that you give to the developer, because if you're building a general platform, they need all of them. So I do think that there was value there, but it was mostly around introducing these distributed systems concepts to developers. So all along, we were kind of building this product. And so as I mentioned before, our goal was to solve the operations problem in the virtual data center. Here's a slide deck probably, I don't know, say early 2009 or late 2008, where we're saying, OK, we're going to build this thing called the virtual network control. I think our product went through seven iterations of names. And the idea is you're going to have some high-level interface to the virtual data center and your operations problems go away. So about this time, we realized that there was a change that was happening in the industry, and that was the evolution of this concept of a v-switch. So because we were focused on virtualization, we would go and see customers running VMs, and you'd be like, wow, this one server is running 80 VMs, which is 80 machines, which is more than we're on the floor of Stanford where I work. And you need networking to connect these types of things. Not only do you need networking to connect these, they're running on x86, so you can put networking on x86 and do interesting stuff there. And so we kind of had this idea that, well, this is actually a fairly strategic, fairly interesting thing. And also, from a startup in networking, the key problem is insertion. It's very difficult to get things inserted. And now, as a pure software player, we are a software company. We had this ability to kind of put networking functionality that was core infrastructure on the data path. And I think this is one of those things that turn out to be like a fundamentally good idea. I mean, if I look back, the entire set of ideas, we got a lot wrong, but I think this was one of the right ideas. On the other hand, hardware never worked for us. I can't tell you how much R&D effort, how much PM personal time I spent trying to find out ways to get, as a software player, functionality into the physical network. So as a pure software player, often we'd go and we'd have these meetings with the IHVs, and we'd be like, we would love to have this functionality. They say, great, we can do anything. And then we'd ask for an extra bit, no, TLVs, no. So it's very difficult to get the functionality we needed. But I think actually probably the hardest thing for a software player, a software player, and when it comes to the hardware supply chain, is hardware refresh takes five to seven years. Now I was actually just at a customer that I've been talking to for probably seven years. I remember in 2012, we had a conversation about hardware acceleration. That was actually available in Nixon that time. They still haven't got the refresh in their standard supply chain. And they're not gonna change their supply chain just because of some software company. Okay, so we want to go and solve the operations problem in the data center. We had a general idea of what we wanted to do, but we weren't exactly sure how that would look like. So again, as good computer scientists, we wanted to solve the problem in generality. We're like, okay, so we want to kind of solve this operations problem. How about we do this? We're gonna do a domain-specific language because you get the best of both worlds. You get all the expressibility of a language, so you don't lose anything there, but it's high-level and topology and specific so you get simplicity. That was the goal. So very, very quickly, we realized that this was a bad idea for two reasons. The first one is, so it turns out networking is actually pretty complex, what people need out of it. It's not just a connectivity matrix. It's not just A talks to B or does not talk to B. It's broadcast, it's multicast. It's things like PV lands, it's static routes, it's service chaining. I mean, there's so much that people want to do and do. It was never really clear that, given all the languages we did, that we could actually reproduce it correctly. But much, much more fundamental was that as soon as you change abstractions, you change the entire world in which a system lives in. All of the tools, all of the training material, even the way that people think about it. It's almost like detonating an explosion for everything that's happened before and you have to recreate it again. And it was pretty clear to us that this would be like the biggest adoption hurdle you can ever have if you want to teach somebody else how to use a high level language. So at this point, we stepped back and we're like, okay, we believe in the problem. We believe there's this operations problem fundamentally and we believe in the types, the pieces of a solution. We believe you need something topology independent. We believe that you need something that's kind of global. And so we said, well, why don't we have those abstractions just be networks? Because it solves both of these previous problems, right? It solves the semantics problem. People can create whatever network they want. And it solves the topology independent problem because we're gonna make these as the actual virtual abstractions. And by the way, I think virtualization may be the most over-learned term in all of computer science. So at Nesira, virtualization meant something very specific, which is it was true virtualization. You should start with any type of hardware, with any addressing model and any service model. And then on top of that, you create any other network with any topology and energy addressing model and any service model. I mean, at the time, there was kind of a lot of popularity around things like slicing, which is very useful, but slicing is segmentation. That's where you take a network and you give a subset of it to somebody else. That's not virtualization. Virtualization is you have L3 and I give you L2, or you have L3, IPv4 and I give you IPv6. And I'll say this is the piece that made everything finally fit. And not just product market fit, and not just development, and not just customers. I mean, it's like everything became easier when we made this decision. For example, what's our roadmap? Became easier because you had something to point to. What features do you implement? How do you organize an ecosystem? Because all of this stuff had happened in the physical world and now you're just replicating it. And when you wanted to divert from that, it was a deviation from something everybody understood. So operational tool support, customer support, everything became a lot easier. All right, so I think we were acquired in 2012. So NSX had been in a market for about two years at that time, and then probably lost a year to the acquisition, and then we went through pretty aggressive revenue ramp. So NSX ended up being used for three primary use cases. So I left in last year, 2015, it was about a $600 million run rate. And the three use cases at the time were about 40% was for automation. So just automating those virtual network abstractions. About 40% was for security. So basically automating security on those abstractions. And I'll say about 10, 15% was interdata center stuff. Another reason why I wanted to show this slide is because independent of how much R&D you do in product market fit, it still takes a long time. I mean, say six years of this case to actually get the significant revenue. All right, so I think it's worth stepping back and saying, okay, did we achieve what we set out to? If you look at the early slide, so that's the slide from one of the first pitch decks and the later slide, they look entirely different, right? One's this, I'm gonna create this network OS, and the other one is, I'm gonna, we're gonna do virtual networking. And I think the answer to that is just kind of qualified sort of. I mean, if you look at the high-level goals, I think we nailed those, right? You decouple Harbor from software, absolutely. You provide network-wide control over high-level abstractions, yes. We didn't know how we were gonna get there, and we certainly had these ideas of we're gonna move to campus in one, which never happened. I'm gonna explain later why I think that is. But I definitely think like, with respect to the original goals, you know, we kind of fit it in there. All right, so I wanna talk about things that in retrospect may be obvious, but the time I wish I would have known them. And the first one is, you know, if I had to do it all over again, I think I would focus just on the application. And the thing is it's actually not, there's not actually not a lot of complexity in building one of these general platforms, and I'm kind of more and more of the opinion that it doesn't even make sense to have a general SDN platform, because the problems are so different that it may make sense to have a WAN platform and a data center platform and, you know, something like that, but one that tries to solve all of these, the problem is, is in order to be really useful, you have to be sufficiently general, and then you end up basically becoming like a library of protocol wrappers or something like that. So there's some value, but it's not something to over-rotate on, especially from an R&D side, and this is something we just simply got wrong. I mean, the vast majority of our time was spent on this. Another thing is, if you look at kind of the minimum time to get something done, it's almost always dwarfed in market category-creating situations from changing consumer behavior. Like, if you know what to build, and that takes a long time to figure out, if you know what to build, like network virtualization, that took us two and a half years, doesn't take that long often to get into market, but then to actually train the market to use it takes a really long time. And so a big takeaway that I have is, you know, instead of like kind of dithering around on a platform, you wanna get into market about as quickly as possible in order to kind of get that feedback, start the education process. And to kind of put a finer point on this, like we often talk about how fast software is and how slow hardware is, but at the end of the day, this all comes down to basically the speed in which an industry moves. So in as much as you're planning anything, you need to be realistic about how long it takes for the industry to move along. Okay, so very quickly, so the key lessons for me, product before platform, the second line, if you're doing some category creation thing, virtualize before changing abstraction, changing abstraction really does change the world. Software before hardware, I guess that's pretty straightforward. And then, and I didn't have time to talk to this, but over time, the majority of resources in an enterprise company actually goes to sales and go to market. It dwarfs everything. If you looked back at the revenue slide that I showed before, the majority of time in investment actually is that sales ramp. And you know, if you don't focus on that early and get that dialed down, I think that's one of the biggest failure mode of a lot of early startup companies. All right, so I just want to give one final thought before setting things up for Q and A. So the first one is, success is over-determined. I'm a venture capitalist now. I'm an Andreessen Horowitz and you hear many success, sorry. So what does over-determining mean? Over-determined is a mathematical expression and an over-determined system is one where you have more variables than equations. Okay, so if you have more variables than equations, you don't really know what the right answer is because it's over-determined, right? So a number of solutions will solve the equation, right? And success is one of those things. If you have a successful outcome, everybody will tell you like why this is the case, right? Because it's an over-determined system. I mean, there's many things that went into it. And for me, it's very difficult to know kind of what makes a successful journey through this kind of crazy, crooked life and path that we have. But it does share one thing in complement with venture capital doing a startup, which is you can make an awful lot of bad decisions, but a few key decisions really drive all of the outcomes. I mean, if I look back at all the things that we got wrong, there's a lot, but there's a few things we got really, really right. But unlike venture, you can't take a portfolio approach to this, right? Unlike venture, you make these bets in serial, right? So you acknowledge that failure is a total requirement. Like there's no way to get there without failing. And actually, I think the failures will probably outweigh the successes. But you can't place them all in parallel like you can't in venture. So it seems to me like ultimately, being an entrepreneur and driving something to market, the fundamental trick is you're balancing two pieces or two types of kind of human nature. The first one is self-delusion, which is you're trying to do something and you can see how it needs to be done. And so you believe it's happening when it may not be happening. So you need to kind of be able to kill your darlings. It turns out like a general controller platform may be not that successful. On the other hand, you've got to balance the human nature for impatience, which it actually, as I showed you before, it takes five to seven years for a market to mature. And so I think like the entire key is to try and figure out like, how do you know when to stay the course and how do you know when to hit? And again, to go back to it, I think that without actually being piped into the nervous system of the product market fit, it's very difficult to do that. And so with that, I would love to open up to questions, but thank you so much for your time this morning. Hi, Martin. Hey, how are you? I'd like to ask you a personal question like I did just in yesterday and that is, I always thought that you were having watched you and actually I learned about SDN meeting with this stealth startup, Nicera, seven, eight, however many years ago. But I've watched you then as the entrepreneur and then now as a VC, it seems like you're really happy in your new role, but I always thought that you'd had this entrepreneurial drive in you that would make you get back into something. And I thought maybe sitting in the seat you are now, you're always watching for the next event that Martin's gonna put his full energy into. Yeah, that's a good question. So listen, I devoted 10 years of my life to going about as deep as anybody can go into one thing and it was amazing. It was a great experience. You pay collateral in other ways, right? I kind of scorched earth my personal life while I did that, but I feel like I've done it and I feel very good about that. And now this is a kind of a fantastic opportunity for me to go broad. And I do think some of the shifts that are going on in the industry right now are broad, right? I mean, things that are industry broad, like the movement to the developer and the disruption of open source. And so, I mean, listen, how many decades does one have in a life? I've already used one and so I'm really excited to be doing something that still draws from what I've learned in the past and my experiences, but is a very, very different skill set for me to apply to. So I'm actually very happy with the decision to change. Great question, thanks. Hi, Martin, Marco Canini. Hey, Marco. So thanks for the, you know, very nice retrospective of your drawing. Thank you. However, as an academic, right? Yeah. Ultimately, the talk and the message that you draw seems intellectually not really rewarding. Okay. I remember six years ago, around this time, Scott Schenker came to this Fox and was trying to convince us that we now got the right obstructions and that we should not, you know, be able to ever do that exercise anymore because these are the right obstructions. So today, if I were to, you know, walk away, what is it that I should take from your talk in terms of, you know, this type of failure that you are admitting to, in a sense, at the level of the obstruction? Is it really the case that there is a nice set of obstructions that we have but they don't really apply in practice or is it something that we could do as researchers and go back and see if we got the obstructions also wrong? Yeah, no, no, it's a good question. So I think that there's two primary takeaways. One of them is like, until you really try and kind of change like deployment practices, you don't really realize how much technology isn't in a bubble. Like you really don't. And so much of the type of technology that we need to create, we need to create it in a way that people understand it. You have to, right? Because ultimately people are paying dollars for this and they're putting their job on the line and they've got existing training. And if you don't take that outside view in, I think it's very difficult to actually have impact. And so as a result of that, it's much better from an extraction standpoint to be incremental because it's almost like inserting that level of indirection into the world. So one of the very key takeaways is you really want to virtualize before you change abstractions because exactly as it doesn't change the abstractions. What's interesting though is once you do that actually, you have the opportunity to change abstractions. If you look at modern uses of network virtualization solutions today, they actually have high level policy languages built on top of them. And the reason is because you've educated the customer base on that you can do all of this new operation stuff, albeit with old abstractions. And then now you can start incrementally adding these abstractions on top. So you've got an insertion point and you've also changed the customer behavior. And so I think the two takeaways are, listen, you've got a real world that you've got to snap into but that's not necessarily a bad thing. I just think that you want to solve that problem first, otherwise you get nowhere, you go to zero. And then after that, you want to solve kind of the broader issues. I thought, actually we're out of time but thank you so much for the time. Thank you.