>>From our studios in the heart of Silicon Valley. Palo Alto, California myth is a cute conversation. >>Hello and welcome to the cube studios in Palo Alto, California. For another cube conversation. We go in depth with thought leaders driving innovation across the tech industry. I'm your host, Peter Burris. It's a well known fact of life at this point in time. We're going to the cloud in some manner, way, shape or form. Every business that intends to undertake a digital transformation is going to find themselves in a situation where they are using cloud resources to build new classes of applications and accelerate their opportunities to create new markets that are more profitable. What folks haven't fully internalized yet though is what it means to govern those activities. What does it mean to use data that is in the cloud in a compliant and reliable way? What does it mean to allow rapid innovation while at the same time ensuring that our businesses are not compromised by new classes of risk, new classes of compliance issues as a result of making certain liberties, uh, with how we handle governance. So that's what we're going to talk about today and we've got a great conversation for you. Toby Knapp is a co founder and CTO of day two IQ and Charlie Betts is the principal analyst at Forrester. Toby. Charlie, welcome to the cube theater. All right, so Charlie, I'm going to start with you. I kind of outline the overall nature of the problem, but let's get it very specific. What is the problem that enterprises face today as they try to accelerate their use of technology in a way that doesn't compromise the risk and compliance concerns? >>Well, we are hearing the same story over and over again. Peter, uh, companies are starting on the cloud native journey and perhaps a dev ops journey. You know, there's some similarities there. You know, one leads to the other in many cases and they S they do a proof of concept and they do a pilot and they like the results. But both of those efforts had what from monopoly, we would call it a get out of jail free card. You know, they had a pass to bypass certain regulatory or governance or compliance controls. Now they want to scale it. They want to roll it out across the enterprise and you can't give every team a get out of jail free card. >>Well, let me dig into this because is it that the speed with which we're trying to create new things, is that the key issue? Is it that the new technologies like Coobernetti's lend themselves to new style that doesn't necessarily bring good governance along with it? What is, what are those factors that are driving this problem? >>I think the central factor, Peter, is the movement from stage gated governance to governance of continuous flow. We could unpack this in various ways, but really if you look at so many governance models and people ship them to us and we comb through them and it's getting, you know, doing a lot of out lately, what we see is over and over again, this idea that delivery pauses experts come in from their perspective with a checklist they go through, they check the delivery against the checklist, and then the Greenlight is given to move on. And this is how we've run digital systems for a long time now. But now we're moving towards continuous flow, continuous iteration, >>agile, agile, DevOps, >>dev ops, all the rest. And these methods are well suited to be supported by architectures like Coobernetti's. And there are certain things you can do with automation that are very beneficial in cloud native systems, but you're up against, you know, decades of policy that assume this older model is based on older guidance like ITIL and PIM, Bach and, and COBIT and all the rest. COBIT 2019 is still based on a plan build run model, >>which is not, is not necessarily a bad thing in the grand scheme of things, but it doesn't fit into a month long sprint. >>It doesn't fit. And more and more what we're seeing when I say stage Gates are going away, what we're seeing is that the life cycle becomes internalized to the team. You still plan, build, run. But it's not something that you can put controls >>on at the high level. And so the solution seems to be is that we need to be able to foster this kind of speedy acceleration that encourages the use of agile, uh, leads to a dev ops orientation. And somehow fold good solid governance practices right into the mix. What do you think the, let's take a look at 2025, what's it going to look like? And uh, even if we're not ready for it yet? >>Well, I think you were going to govern a lot more at the level of the outcome. You're going to govern what not how as much, but there are a lot of things that still are essential and just basic solid good practice such as not having 15 different ways or a hundred different ways to configure major pieces of infrastructure. You know, there's a, in the, some of the reports, uh, the state of DevOps report that came out, there was a, uh, a note in there or a finding in there that it was best to let the developers have a lot of choice. And I understand that developer autonomy is very important, but every time a development team chooses a new technology or a new way to configure an ex, an existing technology, that's an expansion of attack surface. And I'm very concerned about that, especially as we see things like Equifax with the, uh, the struts exploit, you know, we, we have to keep our environment secure, well patched up to date. And if you only have one or two ways that things are configured, that means your staff are more likely to do the right thing as opposed to, you know, infinite levels of variation, you know, on a hundred different ways of configuring. Coobernetti's >>well, presumably we don't want the infinite levels of variation to be revealed at the business level and not down at the infrastructure level. I think one of the things that folks mean or folks aren't intending or hope to be able to do with digital business you're alluding to this is creating a digital asset, a software based asset because ultimately it's going to be more integratable, but you lose the opportunity to integrate those things if you're increasing the transaction costs by introducing a plethora of discordant governance models. Is that what you're seeing as well, Toby? >>Absolutely. And I think, uh, you know, some aspects of cloud native that make this problem a lot bigger is actually, you know, cloud native encourages sort of a self service model for infrastructure. And also we're seeing our shift, um, off, uh, power and decision making towards developers, right? So you have developers introducing a lot of these new stacks, often in a very, you know, sort of bottoms up, um, organic way. So very quickly and enterprise finds themselves with, you know, 10, 15 different ways to provision infrastructure to provision communities, clusters. Um, and often, you know, the teams that are in charge of governance aren't even aware of these things, right? Yes. So, uh, I think it starts actually with that and you know, how can we find, uh, this balance of giving developers the flexibility they want, uh, you know, having them leverage the benefits of cloud native, but at the same time making the folks that are in charge of governance, uh, aware of what's going on in, in their enterprise, uh, making them aware of the different stacks that are provisioned. Uh, and then finding the right balance between that flexibility and enforcing governance. Uh, there's ways to do that. Um, you know, there what we see a lot is, is, uh, waste, uh, people building one stack on cloud provider, a different stack on cloud provider B, a third stack, you know, at the edge or in their data center. And so when it comes to patching, security issues, upgrading versions, you know, you, you're doing three, five times the, the amount of work. >>Well, let me ask you a question because we can see that the problem is this explosion in innovation at the digital level, uh, that is running into this, uh, the, the stricture of historical practices. And as a result, people are in running governance. What is it, I mean, if I think about this, it sounds to me like the developer tooling is getting better, faster than the governance tooling. Where are we in the marketplace in terms of thinking about technologies that can improve the productivity on the governance side so that we can bring governance models to the developers so they don't have to make decisions at that level? >>Right. I think where we are in the market is, um, so obviously cloud native and Kubernetes specifically has seen rapid adoption Indiana price, right? And I think, um, you know, the governance and tools are just now catching up. Right? Right. Um, so the typical journey we see is, uh, you know, folks try out Kubernetes, they try out cloud native technologies to have a very good first experience. It's easy. And so they kind of, uh, you know, forget some of the best practices that we've learned over the years for how to secure a production stack, how to make it upgradable, maintainable, how to govern workloads and versions, um, because they'll still, schools just simply didn't exist. Uh, so far we're now seeing these tools emerge. Um, and, and really it's the same approaches that have worked for us in the past for, for running these types of infrastructure. It's, um, you're having a central pane of class for visibility. What versions am I running? Uh, you know, first being aware of what's out there and then you'll centralizing management of these, of these stacks. Um, how do I, you know, lifecycle manage my, my Kubernetes clusters and all the related technologies. Those are the tools that are just now showing up in the market, >>but it's also got to be, I presume that, uh, a degree of, uh, presuming that the tooling itself does bring forward good governance practices into a modern world. If I got that right. >>Yeah, absolutely. I think this is one of the key things that the updated INO team, uh, the infrastructure and operations and our, our view is that these become platform teams. So we've maybe relieved the INO term behind we go with the platform teams. This is one thing that they should be doing is creating reference implementations. You know, the, you know, here's your hello world stack and it's perfectly compliant. Go solve your business problem and leave the undifferentiated heavy lifting to us. You know, and this is I think, uh, going should be a welcome message. Uh, assuming that the stack is providing all the services that the developer expects. >>Well it certainly suggests that there is a reasonable and rational separation of duties and function within a business. So the people that are close to the business of building the function that the business needs are out there doing it. Meanwhile, we've got infrastructure developers that are capable of building a platform that serves as multitude of purposes with the specificity required for each workload and in compliance with the overall organization. >>There's a key message that I want to reinforce with the audience as we think about the future of INO. I, we've been thinking a lot about it at Forester. What is the future of the traditional INO organization? If I say infrastructure that implies application and I'm talking about a stack that doesn't go away, you know, there will always be a stack, a layered architecture. What is being challenged is, when I say operations, that implies dev and I'm talking now about a life cycle. That's what's merging together. And so well, the life cycle becomes something that is held internally within your feature or component team and is no longer a suitable topic of governance. Absolutely. In terms of the layered infrastructure, this is where we, it's still a thing, you know, because yes, we will platform teams, component teams, feature teams facing the business or the end user. >>Well, it's all back to the idea that a resource is a reasonably well bound, but nonetheless with the appropriate separation, uh, of, of function that delivers some business outcome. And that's gonna include both infrastructure at a software level, an application at a software level. So look, we, you spent a lot of time talking to customers about these issues when they come back to you. Uh, where are you seeing successes most obviously and why? >>Yeah, so where we see successes is where, um, you know, organizations, um, figure out a way to give developers what they want, which is in the cloud native spaces. Every development team wants to own their own communities cluster. They want to, it is their sandbox. They want to install their own applications on there. They don't want to talk to different team when they install applications. So how can you give them that while at the same time enforcing the standards that you need to, right? How do you make sure those clusters follow a certain blueprint that have the right access control rules? Um, you know, sensitive information like, like credentials are distributed in the right way. The right versions of workloads are available. Organizations that figure out how to do that, uh, they are successful at this. So the government from a central place, they have um, you know, essential pane of glass. >>Um, you know, like our product commander where they essentially set up blueprints for teams. Um, each individual team can have their own cluster. It gets provisioned with this blueprint. And then from the central place I can say, all right, here is what my production clusters should look like. Right? Here are the secrets that should be available. Here are the access control rules that need to be set. And so you find the right balance that way, right? You can enforce your governance standards while at the same time giving developers their individual clusters that development their staging of production clusters. >>And here's the options and what is an edible option and what is not. Right. Yeah. So it seems to me as if I, I mentioned this earlier, if I think about digital business, it's the opportunity to not only turn process, we're increasingly digitized process, but the real promise also is to then find ways of bringing these things together, integrate the business in response to new opportunities or new, uh, competitive factors or regulatory factors, whatever else it might be, and literally reconfigure the business quickly. That has to be more difficult if we have a wide array of, of governance models and operational principles. Trolley is, you think about customer success, uh, what does it mean for the future to be able to foster innovation with governance so that the whole thing can come together when it needs to come together? >>Well, I think that we need to move to governing again, as I said earlier, governing >>what not. How uh, >>I believe that, uh, you know, teams should be, should be making certain promises and there's a whole idea of the theory that's out there. A guy named Mark Burgess who is, you know, well known in certain certain infrastructure as code circles. So what are the promises that the team makes within the larger construct of the team of teams and is that team being accountable to those promises? And I think this is the basis of some of the new operating models we're seeing like Holacracy and teal. I think we're in very early days of looking at this. But you know, yeah, you will be held accountable for you know, objectives and key results. But how you get there, you have more degrees of freedom and yet at an infrastructure level, this is also bounded by the fact that if this is a solved problem, if this is not interesting to the business, you shouldn't be burning brain power on solving it. You know, and maybe it was interesting, you know, a couple of years ago and there was a need to explore new technologies, but really the effort should be spent solving the customer's problems. Charlie Betts, principal analyst at Forrester, Toby not co founder and CTO of D to IQ. Thanks very much for being on the cube. Thank you. Thank you, Peter, and thank you for joining us for another cube conversation. Once again, I'm Peter Burris. See you next time..

>> Announcer: Live from San Diego, California, it's theCUBE. Covering KubeCon and CloudNativeCon. Brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome back, I'm Stu Miniman and my Co-host is John Troyer. And you're watching theCUBE here in day two of our coverage of KubeCon and CloudNativeCon. And joining me is Tobi Knaup who is the co-founder and CTO of D2iQ. See what I did there, Tobi? >> That's right, I love it. >> Alright. So Tobi, first of all, KubeCon, of course D2iQ, last year when we were here it was Mesosphere, so give us a little bit, you've been to lots of customer meetings, 12,000 people in attendance, tell us a little bit about the energy and how your team's finding the show so far. >> Yeah, obviously biggest KubeCon so far and it's just amazing how far this community has come, how it's grown. How many projects are part of it now, how many vendors here, too. You know two expo halls with different booths and you know, I think it just shows how important this community, this ecosystem is. When customers come to us and say they want to work with Kubernetes the community's why they're really doing it. >> Yeah, it is a great community, great vibe for people that aren't already in it. It's easy to get started, but one of the big themes we're hearing here is simplicity, how to make it easier to get going and once they get going, what happens after day one? That's some of the rebranded pieces. So for our audience, explain a little bit, why the rebrand focus of the company, Day 2 operations, absolutely something that I hear a lot of discussion on and why is your team specifically well positioned for that environment. >> No absolutely, so the rebrand we did because obviously our old company named Mesosphere has Mesos in it. That's the open source product we started with. But we've been doing a lot more than that actually for many years, right? We help customers run Apache Kafka and Spark and Cassandra. We've been doing a lot with Kubernetes also for some time now and even more so now. So having one particular technology in the company name was holding us back, right. People just put us in that box but we're doing so much more. So that was the reason for the rebrand and so, we wanted a name that doesn't have a particular technology in it and so we're looking for what is really expressed, what we do, what we help our customers with? And we've always been focused on Day 2 operations, so everything that happens after the initial install. How do you monitor things properly, upgrade them and so on? So that's why we loved that Day 2 concept. And then the IQ really stands for a couple of things. First of all we try to put a lot of automation into our products, so make those products smart to help our customers. But more importantly too, when we look at the ecosystem as a whole, where are most customers at, where are most companies at. Well, they're still early in their cloud-native journey and they need to get up to speed, they need to get smart about cloud-native and about Day 2 operations and so that's the IQ piece. We want to help our customers become smart about this space, get educated and then learn to do cloud-native. >> So Tobi, one of the things that fascinates me about the Kubernetes ecosystem is that people bring stuff to the table. Kubernetes is here, that's evolving. Other companies, entities, projects are coming to the table with other open source concepts and solving problems that they have in the field. At D2iQ, when you were Mesosphere, you have years of experience dealing with production issues, scaling management, all these sort of really, really fascinating cloud-native problems, so you bring a lot of experience to the table. So one of the projects that you are now working on and working with your customers and partners and the bigger ecosystem on is a way of approaching operators. The concept of bringing this kind of lifecycle automation to applications and helping with all these Day 2 problems. Can you talk a little about so KUDO is the name of the framework, I guess. Can you talk a little bit about that and how you're bringing that here to sit at the table and what some people's experiences with that are and what they are using it for? >> Absolutely, yeah, so these data services, these stapler workloads like Kafka, Cassandra and Spark, that's been in our DNA for a very long time. In fact, a little known fact, Apache Spark was originally a demo application for Apache Mesos. That's how it started originally. Obviously, it took off. So, we've been doing that since even before we were a company. And we've been helping our customers on top of Mesos with running these complex data stacks and there's some equivalent of operators on top of Mesos called frameworks. So we've been building these frameworks and we realized it's a little too hard to build these things. We typically had to write thousands of lines of code, 10, 20,000 sometimes and it took too long. So what we actually did on Mesos many years ago is we extracted the common patterns from those frameworks and built it into a library and made it so you can actually build a framework with just configuration, with just YAML, so it's a language that allows you to essentially sequence your operations into phases and steps. kind of like you would write a run book that a human operator takes and then goes through, right? So when we looked at the Kubernetes Operator space, we saw some of those same challenges that we had faced years ago. Building a Kubernetes Operator requires to write a lot of code. Not every company has Go programmers, people that are skilled enough in Kubernetes that they can write an operator. And more importantly too, once you write those 10,000 lines of code or more, you also have to maintain it. You have to keep up with API changes and so, a lot of folks we talked to at KubeCon last year and to customers, said it's just too hard to build operators. The other side of that too, is folks said it's a little too hard to use those operators too because very common use cases, you build a data pipeline. That means you'll be using multiple different operators, say Kafka, Cassandra and Spark. So if those all have different APIs, that's pretty hard to manage. So we wanted to simplify that. We wanted to create an alternative way for building operators that doesn't require you to learn Go, doesn't require you to write code, it works with just this orchestration language that KUDO offers and then for the KUDO users, the API is the same across these different operators. It has a plugin for Kube Cuddle, so you can interface with all the different operators through that. So yeah, simplicity and a great developer experience are the keys here. >> Tobi, I was wondering maybe you bring us inside the personas you target with this type of solution. As we've seen the maturation of this space, first couple of years I came, it felt very infrastructure heavy. The last year or two, there's more of the AppDev discussion there. They don't always speak the same languages. Looks like you've got some tooling here to help simplify that environment and make it easier because of course your application developers don't want to worry about that stuff. That's the promise of things like serverless, or just we're going to take care of that and stats and whatnot, so where specifically do you target and what are you hearing from customers as to how they're sorting through these organizational changes? >> Yeah, so I think ultimately, everybody kind of wants a platform as a service in some way, right? If you're building an app for your business, you don't want to think about, how do I provision this database, how to do that? And obviously, I can go to a public cloud and I can use all those public cloud services but what a lot of folks are doing now is they're running on various different types of infrastructure. They're running on multiple public clouds. They're running on the Edge. We work with a lot of customers that have a need to deploy these data services, these operators in Edge locations, on the manufacturing floor in a factory, for instance. Or on a cruise ship, that's one company we're working with. So, how do you bring this API-driven deployment of these services to all these different types of locations? And so that's what we try to achieve with KUDO for the data services and then with our other products too, like Kommander, which is a multi-cluster control plane. It's about when organizations have all these different clusters. And very typically they get into the dozens or even hundreds of clusters fast. How do you then manage that? How do you apply configuration consistently across these clusters? Manage your secrets and RBAC rules and things like that? So those are all the Day 2 things that we try to help customers with. There's a little bit of a tension there sometimes, right? Because the great thing about Kubernetes is it's great for developers. It has a nice API, people love the API. People are very quick to adopt it, right? They try it out on their laptop, they setup their first cluster. That typically goes very fast and they very quickly have their first app running. So it happens organically, right? But every large organization also has a need to put the right governance in place, right? How I keep those clusters secure? How do I meet my regulatory requirements? How do I make sure I can upgrade those clusters fast, if I need to fix a security issue and so on? So there's that tension between the governance, the central IT and what the developers want to do. We try to strike a balance there with our products to give developers the agility that cloud-native promises but at the same time, give the IT folks the right controls so they can meet their requirements. >> Tobi, here at the show this year, obviously bigger and a lot more folks at different parts of their cloud-native journey. Again, with the experience you all have, as you talk to folks this year, obviously people are clearly in production. You talk about some of the governance issues, is there anything you can say about either what you think is going to make for a successful partnership with you and a successful customer? What qualities do you need to have by the time you're growing up in production and then also as they're making choices here, what should the end users be looking at? >> Right, so one of the things we realized over the years is actually cloud-native is a journey. Every organization is somewhere else on that journey. And you said partnership, I think that's the key word here. We want to partner with our customers because we realize that this stuff is complicated, right? And it's actually for us as a company, our journey has been kind of interesting because we started at this large scale spot, right? Before we were even a company, we were running these clusters with tens of thousands of notes. These large online services at Twitter and other companies, that's where we started and that's where our first product kind of landed. It's at that large scale is what we're known for but most organizations out there are much earlier in their journey to cloud-native. As so, what we realized is that we really need to partner with folks to even at the very first steps, where they're just getting educated about this space, right? What are containers? How are they different from VMs? What is this cluster management thing, right? How does this all fit together? So we try to hold our customers' hands, catch them where they are. Besides all of the software that we're building, we also offer trainings for example. And so we just try to have the conversation with the customer. Figure out what their needs are, whether that's training, whether that's services or different products. And the different products that come together in our Kubernetes product line, they're really designed to meet the customer at these different stages. There's Konway, that's our Kubernetes distribution, get your first project up and running. Then once you get a little bit more sophisticated, you probably want to do CI/CD. So we have an upcoming product for that, it's called Dispatch. Pretty excited about it. The data services with KUDO. Folks typically add that next and then very quickly you have these dozens of hundreds of clusters. Now, you need Kommander, right? So we try to fit that all together. Meet the customer where they are and I think education is a big piece of that. >> All right, Tobi, we want to give you the final word. You talked about some of the things coming out here, so just give us your viewpoint of the ecosystem broader as to what next things need to be done to help even further the journey that we're all on? >> Yeah, I think in terms of next things, there's a lot of interest around operators. Well, operators as the implementation but really what's happening is, people are running more and more different workloads on top of Kubernetes, right? And I think that's where a lot of the work is going to happen over the next year. There's some discussions in the CNCF now even. What is an operator? How do we define that? Is it something fairly broad? Is it something fairly specific? But Kubernetes is definitely the factor standard for doing cloud-native and people are putting it in a lot of different environments. They're putting it in Edge locations. So I think we need to figure out how do you have a sane sort of development workflow for these types of deployments? How do you define an application that might actually run on multiple different clusters? So I think there's going to be a lot of talk. Operators obviously, but also on the developers side, in a layer above Kubernetes, right? How can I just define my application in a way where I say maybe just run this thing at a highly available way on two different cloud providers, instead of saying specifically it needs to go here, it needs to go there? Or deploy this thing in a follow the sun model or whatever that is. So I think that's where a lot of the conversations are going to happen, is that level above. >> All right well Tobi, appreciate the updates. Congratulations on the progress and definitely look forward to catching more from you and D2iQ team in the near future. >> Thank you very much for having me. >> All right, for John Troyer, I'm Stu Miniman, lots more to come. Thanks for watching theCUBE. (light music)

(informative tune) >> From San Francisco, it's The Cube. Covering D2 iQ. Brought to you by D2 iQ. (informative tune) >> Hey, welcome back everybody! Jeff Frick here with theCUBE. We're in downtown San Francisco at D2 iQ Headquarters, a beautiful office space here, right downtown. And we're talking about customers' journey to cloud data. We talk about it all the time, you hear about cloud native, everyone's rushing in, Kubernetes is the hottest thing since sliced bread, but the at the end of the day, you actually have to do it and we're really excited to talk to the founder who's been on his own company journey as he's watching his customers' company journeys and really kind of get into it a little bit. So, excited to have Tobi Knaup, he's a co-founder and CTO of D2 iQ. Tobi, great to see you! >> Thanks for having me. >> So, before we jump into the company and where you are now, I want to go back a little bit. I mean, looking through your resume, and your LinkedIn, etc. You're doing it kind of the classic dream-way for a founder. Did the Y Combinator thing, you've been at this for six years, you've changed the company a little bit. So, I wonder if you can just share form a founder's perspective, I think you've gone through four, five rounds of funding, raised a lot of money, 200 plus million dollars. As you sit back now, if you even get a chance, and kind of reflect, what goes through your head? As you've gone through this thing, pretty cool. A lot of people would like this, they think they'd like to be sitting in your seat. (chuckles) What can you share? >> Yeah, it's definitely been, you know, an exciting journey. And it's one that changes all the time. You know, we learned so many things over the years. And when you start out, you create a company, right? A tech company, you have you idea for the product, you have the technology. You know how to do that, right? You know how to iterate that and build it out. But there's many things you don't know as a technical founder with an engineering background, like myself. And so, I always joke with the team internally, this is that, you know, I basically try to fire myself every six months. And what I mean by that, is your role really changes, right? In the very beginning I wrote code and then is tarted managing engineers, when, you know, once you built up the team, then managed engineering managers and then did product and, you know. Nowadays, I spend a lot of time with customers to talk about our vision, you know, where I see the industry going, where things are going, how we fit into the greater picture. So, it's, you know, I think that's a big part of it, it's evolving with the company and, you know, learning the skills and evolving yourself. >> Right. It's just funny cause you think about tech founders and there's some big ones, right? Some big companies out there, to pick on Zuckerberg's, just to pick on him. But you know, when you start and kind of what your vision and your dream is and what you're coding in that early passion, isn't necessarily where you end up. And as you said, your role in more of a leadership position now, more of a guidance and setting strategy in communicating with the market, communicating with customers has changed. Has that been enjoyable for you, do you, you know, kind of enjoy more the, I don't want to say the elder states when you're a young guy, but more kind of that leadership role? Or just, you know, getting into the weeds and writing some code? >> Yeah. Yeah, what always excites me, is helping customers or helping people solve problems, right? And we do that with technology, in our case, but really it's about solving the problems. And the problems are not always technical problems, right? You know, the software that is at the core of our products, that's been running in production for many years and, you know, in some sense, what we did before we founded the company, when I worked at Airbnb and my co-founders worked at, you know, Airbnb and Twitter, we're still helping companies do those same things today. And so, where we need to help the most sometimes, it's actually on education, right? So, solving those problems. How do you train up, you know, a thousand or 10 thousand internal developers at a large organization, on what are containers, what is container management, cluster management, how does cloud native work? That's often the biggest challenge for folks and, you know, how did they transform their processes internally, how did they become really a cloud native organization. And so, you know, what motivates me is helping people solve problems in, whatever, you know, shape or form. >> Right >> It's funny because it's analogous to what you guys do, in that you got an open-source core, but people, I think, are often underestimate the degree of difficulty around all the activities beyond just the core software. >> Mm-hmm. >> Whether, as you said, it's training, it's implementation it's integration, it's best practices, it's support, it's connecting all these things together and staying on top of it. So, I think, you know, you're in a great position because it's not the software. That's not the hard part, that's arguably, the easy part. So, as you've watched people, you know, deal with this crazy acceleration of change in our industry and this rapid move to cloud native, you know, spawned by the success of the public clouds, you know, how do you kind of stay grounded and not jump too fast at the next shiny object, but still stay current, but still, you know, kind of keep to your kneading in terms of your foundation of the company and delivering real value for the customers? >> Yeah. Yeah, I know, it's exactly right. A lot of times, the challenges with adopting open-sourcing enterprise are, for example, around the skills, right? How do you hire a team that can manage that deployment and manage it for many years? Cause once software's introduced in an enterprise, it typically stays for a couple of years, right? And this gets especially challenging when you're using very popular open-source project, right? Because you're competing for those skills with, literally, everybody, right? A lot of folks want to deploy these things. And then, what people forget sometimes too is, so, a lot of the leading open-source projects, in the cloud native space, came out of, you know, big software companies, right? Kubernetes came from Google, Kafka came from LinkedIn, Cassandra from Facebook. And when those companies deploy these systems internally, they have a lot of other supporting infrastructure around it, right? And a lot of that is centered around day-two operations. Right? How do you monitor these things, how do you do lock management, how do you do do change management, how do you upgrade these things, keep current? So, all of that supporting infrastructure is what an enterprise also needs to develop in order to adopt open-source software and that's a big part of what we do. >> Right. So, I'd love to get your perspective. So, you said, you were at Airbnb, your founders were at Twitter. You know, often people, I think enterprises, fall into the trap of, you know, we want to be like the hyper-scale guys, you know. We want to be like Google or we want to be like Twitter. But they're not. But I'm sure there's a lot of lessons that you learned in watching the hyper-growth of Airbnb and Twitter. What are some of those ones that you can bring and hep enterprises with? What are some of the things that they should be aware of as, not necessarily maybe their sales don't ramp like those other companies, but their operations in some of these new cloud native things do? >> Right, right. Yeah, so, it's actually, you know, when we started the company, the key or one of the drivers was that, you know, we looked at the problems that we solved at Airbnb and Twitter and we realized that those problems are not specific to those two companies or, you know, Silicon Valley tech companies. We realized that most enterprises in the future will have, will be facing those problems. And a core one is really about agility and innovation. Right? Marc Andreessen, one of our early investors, said, "Software is eating the world." he wrote that up many years ago. And so, really what that means is that most enterprises, most companies on the planet, will transform into a software company. With all of that entails, right? With he agility that software brings. And, you know, if they don't do that, their competitors will transform into a software company and disrupt them. So, they need to become software companies. And so, a lot of the existing processes that these existing companies have around IT, don't work in that kind of environment, right? You just can't have a situation where, you know, a developer wants to deploy a new application that, you know, is very, you know, brings a lot of differentiation for the business, but the first thing they need to do in order to deploy that is file a ticket with IT and then someone will get to it in three months, right? That is a lot of waste of time and that's when people surpass you. So, that was one of the key-things we saw at Airbnb and Twitter, right? They were also in that old-school IT approach, where it took many months to deploy something. And deploying some of the software we work with, got that time down to even minutes, right? So it's empowering developers, right? And giving them the tools to make them agile so they can be innovative and bring the business forward. >> Right. The other big issue that enterprises have that you probably didn't have in some of those, you know, kind of native startups, is the complexity and the legacy. >> That's right. >> Right? So you've got all this old stuff that may or may not make any sense to redeploy, you've got stuff (laughing) stuff running in data centers, stuff running on public clouds, everybody wants to get the hyper-cloud to have a single point of view. So, it's a very different challenge when you're in the enterprises. What are you seeing, how are you helping them kind of navigate through that? >> Yeah, yeah. So, one of the first thongs we did actually, so, you know, most of our products are sort of open-core products. They have a lot of open-source at the center, but then, you know, we add enterprise components around that. Typically the first thing that shows up is around security, right? Putting the right access controls in place, making sure the traffic is encrypted. So, that's one of the first things. And then often, the companies we work with, are in a regulated environment, right? Banks, healthcare companies. So, we help them meet those requirements as well and often times that means, you know, adding features around the open-source products to get them to that. >> Right. So, like you said, the world has changed even in the six or seven years you've been at this. The, you know, containers, depending who you talk to, were around, not quite so hot. Docker's hot, Kubernetes is hot. But one of the big changes that's coming now, looking forward, is IOT and EDGE. So, you know, you just mentioned security, from the security point of view, you know, now you're tax services increased dramatically, we've done some work with Forescout and their secret sauce and they just put a sniffer on your network and find the hundreds and hundreds of devices (laughs)-- >> Yeah. >> That you don't even know are on your network. So do you look forward to kind of the opportunity and the challenges of IOT supported by 5G? What's that do for your business, where do you see opportunities, how are you going to address that? >> Yeah, so, I think IOT is really one of those big mega-trends that's going to transform a lot of things and create all kinds of new business models. And, really, what IOT is for me at the core, it's all around data, right? You have all these devices producing data, whether those are, you know, sensors in a factory in a production line, or those have, you know, cars on the road that send telemetry data in real time. IOT has been, you know, a big opportunity for us. We work with multiple customers that are in the space. And, you know, one fundamental problem with it is that, with IOT, a lot of the data that organizations need to process, are now, all of a sudden generated at the EDGE of the network, right? This wasn't the case many years for enterprises, right? Most of the data was generated, you know, at HQ or in some internal system, not at the EDGE of the network. And what always happens is when, with large-volume data is, compute generally moves where the data is and not the other way around. So, for many of these deployments, it's not efficient to move all that data from those IT devices to a central-cloud location or data-center location. So, those companies need to find ways to process data at the EDGE. That's a big part of what we're helping them with, it's automating real-time data services and machine-learning services, at the EDGE, where the EDGE can be, you know, factories all around the world, it could be cruise ships, it could be other types of locations where working with customers. And so, essentially what we're doing is we're bringing the automation that people are used to from the public cloud to the EDGE. So, you know, with the click of a button or a single command you can install a database or a machine-learning system or a message queue at all those EDGE locations. And then, it's not just that stuff is being deployed at the EDGE, I think the, you know, the standard type of infrastructure-mix, for most enterprises, is a hybrid one. I think most organizations will run a mix of EDGE, their data centers and typically multiple public cloud providers. And so, they really need a platform where they can manage applications across all of those environments and well, that's big value that our products bring. >> Yeah. I was at a talk the other day with a senior exec, formerly from Intel, and they thought that it's going to level out at probably 50-50, you know, kind of cloud-based versus on-prem. And that's just going to be the way it is cause it's just some workloads you just can't move. So, exciting stuff, so, what as you... I can't believe we're coming to the end of 2019, which is amazing to me. As you look forward to 2020 and beyond, what are some of your top priorities? >> Yeah, so, one of my top priorities is really, around machine-learning. I think machine-learning is one of these things that, you know, it's really a general-purpose tool. It's like a hammer, you can solve a lot of problems with it. And, you know, besides doing infrastructure and large-scale infrastructure, machine-learning has, you know, always been sort of my second baby. Did a lot of work during grad-school and at Airbnb. And so, we're seeing more and more customers adopt machine-learning to do all kinds of interesting, you know, problems like predictive maintenance in a factory where, you know, every minute of downtime costs a lot of money. But, machine-learning is such a new space, that a lot of the best practices that we know from software engineering and from running software into production, those same things don't always exist in machine-learning. And so, what I am looking at is, you know, what can we take from what we learned running production software, what can we take and move over to machine-learning to help people run these models in production and you know, where can we deploy machine-learning in our products too, internally, to make them smarter and automate them even more. >> That's interesting because the machine-learning and AI, you know, there's kind of the tools and stuff, and then there's the application of the tools. And we're seeing a lot of activity around, you know, people using ML in a specific application to drive better performances. As you just said,-- >> Mm-hmm. >> You could do it internally. >> Do you see an open-source play in machine-learning, in AI? Do you see, you know, kind of open-source algorithms? Do you see, you know, a lot of kind of open-source ecosystem develop around some of this stuff? So, just like I don't have time to learn data science, I won't necessarily have to have my own algorithms. How do you see that,-- >> Yeah. >> You know, kind of open-source meets AI and ML, of all things? >> Yeah. It's a space I think about a lot and what's really great, I think is that we're seeing a lot of the open-source, you know, best-practice that we know from software, actually, move over to machine-learning. I think it's interesting, right? Deep-learning is all the rage right now, everybody wants to do deep-learning, deep-learning networks. The theory behind deep-networks is actually, you know, pretty old. It's from the '70s and 80's. But for a long time, we dint have that much, enough compute-power to really use deep-learning in a meaningful way. We do have that now, but it's still expensive. So, you know, to get cutting edge results on image recognition or other types of ML problems, you need to spend a lot of money on infrastructure. It's tens of thousands or hundreds of thousands of dollars to train a model. So, it's not accessible to everyone. But, the great news is that, much like in software engineering, we can use these open-source libraries and combine them together and build upon them. There is, you know, we have that same kind of composability in machine-learning, using techniques like transfer-learning. And so, you can actually already see some, you know, open-community hubs spinning up, where people publish models that you can just take, they're pre-trained. You can take them and you know, just adjust them to your particular use case. >> Right. >> So, I think a lot of that is translating over. >> And even though it's expensive today, it's not going to be expensive tomorrow, right? >> Mm-hhm. >> I mean, if you look through the world in a lens, with, you know, the price of compute-store networking asymptotically approaching zero in the not-to-distant future and think about how you attack problems that way, that's a very different approach. And sure enough, I mean, some might argue that Moore's Law's done, but kind of the relentless march of Moore's Law types of performance increase it's not done, it's not necessarily just doubling up of transistors anymore >> Right >> So, I think there's huge opportunity to apply these things a lot of different places. >> Yeah, yeah. Absolutely. >> Can be an exciting future. >> Absolutely! (laughs) >> Tobi, congrats on all your successes! A really fun success story, we continue to like watching the ride and thanks for spending the few minutes with us. >> Thank you very much! >> All right. He's Tobi, I'm Jeff, you're watching The Cube, we're at D2 iQ Headquarters downtown in San Francisco. Thanks for watching, we'll catch you next time! (electric chime)