>> 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. >> Okay, welcome back everyone. We're live here in Copenhagen, Denmark. It's theCUBE's exclusive coverage of KubeCon 2018 Europe. I'm John Furrier with Lauren Cooney, my cohost this week. Our next guest Shiv Ramji, VP of Product at DigitalOcean, fast growing startup, now growing company. Congratulations, welcome to theCUBE. >> Thank you very much. >> So you guys got some hard news, you got product, Kubernetes product, and you guys just upgraded your status on CNCF. Let's jump into the product news real quick. What's the hard news? >> Yeah, so we just announced a Kubernetes product and service on our platform. And you know, we've had a lot of customers who've actually have been deploying Kubernetes on our platform, either themselves or through a managed provider. And a lot of customers, specifically businesses, have been asking us to provide native support for Kubernetes. So now this is native support for Kubernetes on the DigitalOcean platform. >> What does native support for customers mean specifically? Is it managing the workload down to, how, what level of granularity, I guess, is the question. Be specific about this support. >> Yeah, yeah. So essentially, typically developers who are deploying container workloads or Kubernetes workloads do this themselves. Now we make it very, very easy. So you can come into our platform and, within a few clicks, deploy a Kubernetes cluster with your typical integrations of monitoring or container registry and the Kubernetes dashboard. >> So you basically just select a couple features and they can go from there? It's just run a gun? >> It's just a few clicks and you are running. And the reason why we did that, and sort of the history of the company has really focused on removing friction for developers to get started. So we make it very, very easy from a product experience perspective, and also from a cost perspective. So we remove all the barriers for any team size to get started. And so that's why we've made the product very, very easy to use, very simple. And then we also plan to have a lot of tutorials around containers or containerizing an application and scaling in the microservices work. >> Lauren: That's great. >> Talk about the security aspect of it. It's been a big topic here. We were talking about it on our intro, Lauren and I, around, you know, that it's evolving in real time. Things are moving fast. Up front work needs to get done. How do your customers think about security in context of the Kubernetes offering? >> So we have a story for that. We are trying to essentially deploy some native integrations and some open source projects that help us do security scanning, so the goal is to essentially let our customers know of vulnerabilities that they may have based on the images that they are deploying. And you know, all of us are guilty of it. We will get a public container image and launch it, and then realize that there are some security flaws. So that's something we do want to address as we continue to roll out additional features throughout this year. >> I know we've interviewed you guys before, but I want you to just take a minute and explain, for the folks watching who might not know DigitalOcean, what you guys do, your value proposition, who you guys target, how you sell the product, what's the service, all that good stuff. Share a one minute update on what you guys do. >> So we are a New York based company that were founded in 2012 out of Techstars. And the value proposition is very simple in that we want to be the cloud platform for developers and their teams, so that they're focused on software that changes the world. And what that means is we take all the complexity in our product development process, essentially to make it very easy for a developer to go from concept or idea to production as fast as they can. Once they get there, we want to also enable them to scale reliably on our platform. And essentially, all of the features that we've launched have been driven by customer demand. So they tell us that, hey, we're scaling on your platform, we really need these additional features, and that's how we respond. So we're very developer-obsessed, and focus on that specific persona, and help them get to the cloud as quickly as possible. >> So you're solving the problem for the developer. Bait pain points are, what? >> So there are three. We think of learning as the first one, as a barrier to developers. So this is why we've built a library of tutorials. There are about 1400 plus tutorials. We get about three million unique visitors on our platform. And about 80% of our customers actually came from one of the tutorials. Right, so that's such a great source of >> Lauren: Documentation is so important. >> Documentation. So important. So that's our first one. The second one is building. This idea of let's remove all friction for you to go from zero, essentially an idea, to production as fast as possible. So there're two things we do there. One, we try to make the product very simple and easy to use. And two, we are very price competitive. So we have a very competitive price to performance ratio in the market, with the idea that, if you want to keep your total cost of operations as low as possible. And so, that's another reason why developers, teams, and also businesses are now, we are in their consideration set, because they're like, well developers love this product, and I can get a cost benefit. Why would I not do that? And then the last one is scaling, which is once you're growing your application, you're going to need ability to scale and support. And so we provide free support to all of our customers, regardless of the size of your workload or size of customer or business. And I think that's a very important value proposition for us. >> So who do you compete against? Like, who are a couple of your competitors? >> So, the best way to answer that is to see, so we go to our customers and see who they compare us with. And typically we are compared against AWS and Google. >> Lauren: Okay, okay. >> And so, they are the ones who will come to us and say, "Hey, we're about to launch an app, or we're considering moving our workloads, you know, here's what our setup looks like in Google or AWS. You know, can you provide us similar capabilities?" And a lot of the times tends to be, you know, our developers already love you. If you have this capabilities and features set, we would love to move our workloads. >> Well I think you've got a tremendous amount of active developers as well, correct? >> Yes, yes. >> So, and you're growing that exponentially. What is, kind of your growth look like, year over year? >> Yeah, so last year we signed the one millionth developer on our platform. There's essentially one million developers that have created an account on our platform. And we sometimes have developers who come in and out of our platforms, if you're done with your project, right, if you're a student. But we have about half a million active developers on our platform, and growing rapidly. And we also foster a community which is growing tremendously. So we've got about three and a half million active developers in our communities, reading articles, and going through Q&A, and posting very interesting projects. >> Those are some great numbers. I mean, they're up there with Salesforce growth. So that's tremendous. >> And also the other news is you're upgrading your membership. Cloud Native Compute Foundation, CNCF. Talk about that dynamic, why? Size, did you fall into new bucket or you guys are increasing your participation? What's the news? >> Yeah, I mean, we were founded really on this idea of we believe in helping the community, and so free and open source software is what we've built our business on. And so, as we got active with Kubernetes ourselves, and we've been using Kubernetes for two years internally, so we have lots of lessons of our own. And as we were bringing this product to market, it was only the right, it was the right time for us to really upgrade our membership to gold with the CNCF, with the goal of getting to their platinum level where we can contribute to standards and bodies and really influence the evolution of all the tooling around containers and microservices. So, it was the right, the timing was right, and it's the right evolution of us continuing to support the community. >> Making some good profit, contribute that, and help out CNCF. >> Shiven: Absolutely. >> As the VP of Product, you have the keys to the kingdom as they say, in the product management world. (laughing) You got to balance engineering management with product, and you got to look to the market for the, you know, the needs of the customers, and of course they're helping you. Big time developers aren't afraid to share their opinion of what they need. >> Shiven: Never. >> Pain points, that's a good, good, good, good job there. What is on the road map for you? What's next? How are you looking at short, mid, long-term evolution of DigitalOcean's product strategy? >> Yeah, so I'll break it down in three different areas. The first part is really having a core complete feature set for a modern application that's being built in the cloud. So this is where, over the last 12 months, we've developed, we've deployed, developed and deployed load balancers, cloud firewalls, object storage, block storage, a new control panel experience, and a bunch of networking features that we have released. And so, we have some new features coming this year, which allow you to do, you know, the VPC feature, specifically, that allows businesses to have private networking and peering. That's been a top requested feature, so that's something that's going to come later this year to round out our core platform. And then, beyond that, we have two or three different things that we're doing. So the first category is just having a better developer experience. So this is everything from the experience you have when you are launching any cloud resource, whether it's for a control panel, or API, or CLI. So, continue to make that frictionless. So we have a few updates coming there to our control panel, improvements to our API, and adding a bunch of integrations so that, if you're using different products to manage your cloud infrastructure, we make that very, very easy. The second thing is marketplaces. So, a lot of, as you know, lots of other providers have marketplaces and different versions of marketplaces. A lot of our customers and vendors are now coming to us saying, "You have a really big audience and customer base. We really want to integrate our products so we can make it easy for them to spin up those resources." So marketplaces is the second large category that we're working on later this year. We'll have a lot of updates on that. And the third one is tied to developer experience, but it's essentially the Kubernetes product that we're launching. We also have plans to enable a marketplace-like integrations, and a lot of the CICD integrations, so that once you're up and running with your cluster, you got to get your CICD pipelines and tooling working, so that's an area. >> I want to ask you about multicloud, and where you guys are at with multicloud, and kind of connecting to the other cloud providers that are competitors, but, you know, your users are going to want to use as well as your solution. >> Yeah, this is where I think Kubernetes fits really, really well with the multicloud story for us, which is why, sort of, why now for us. If your workloads are in Kubernetes, and this is why we are going to support all of the latest community versions that are available. If your workloads are in Kubernetes, it becomes very easy for you to move those over to our platform, and so. I think we're going to see a combination of sometimes customers will have split workloads, sometimes they'll run different types of workloads in our platform, and so I think Kubernetes really opens up that possibility >> Lauren: That's great. To do that. There's still some more tooling to be done, but that's essentially where we're at. >> How many employees you guys have now? What's the number? >> We are roughly north of 400. So still very small. >> Well, congratulations. You guys are a growing company. Great to have you on theCUBE. Thanks for sharing the news. >> Thank you very much. >> Absolutely. >> Great job. DigitalOcean. You know, hot startup, growing rapidly, I'm sure they're hiring like crazy. >> We are. >> So go check 'em out. The news here at KubeCon is positive industry. Rising tide floats all boats. That's a philosophy we have seen on theCUBE and great ecosystems, of course that's happening here. More live coverage here in Copenhagen, Denmark after this short break. Stay with us. (upbeat music)

(upbeat music) >> Welcome back to Supercloud 2 this is Dave Vellante. We're here exploring the intersection of data and analytics and the future of cloud. And in this segment, we're going to look at the evolution of cloud, and try to test some of the Supercloud concepts and assumptions with Brian Gracely, is the founder and co-host along with Aaron Delp of the popular Cloudcast program. Amazing series, if you're not already familiar with it. The Cloudcast is one of the best ways to keep up with so many things going on in our industry. Enterprise tech, platform engineering, business models, obviously, cloud developer trends, crypto, Web 3.0. Sorry Brian, I know that's a sore spot, but Brian, thanks for coming >> That's okay. >> on the program, really appreciate it. >> Yeah, great to be with you, Dave. Happy New Year, and great to be back with everybody with SiliconANGLE again this year. >> Yeah, we love having you on. We miss working with you day-to-day, but I want to start with Gracely's theorem, which basically says, I'm going to paraphrase. For the most part, nothing new gets introduced in the enterprise tech business, patterns repeat themselves, maybe get applied in new ways. And you know this industry well, when something comes out that's new, if you take virtualization, for example, been around forever with mainframes, but then VMware applied it, solve a real problem in the client service system. And then it's like, "Okay, this is awesome." We get really excited and then after a while we pushed the architecture, we break things, introduce new things to fix the things that are broken and start adding new features. And oftentimes you do that through acquisitions. So, you know, has the cloud become that sort of thing? And is Supercloud sort of same wine, new bottle, following Gracely's theorem? >> Yeah, I think there's some of both of it. I hate to be the sort of, it depends sort of answer but, I think to a certain extent, you know, obviously Cloud in and of itself was, kind of revolutionary in that, you know, it wasn't that you couldn't rent things in the past, it was just being able to do it at scale, being able to do it with such amazing self-service. And then, you know, kind of proliferation of like, look at how many services I can get from, from one cloud, whether it was Amazon or Azure or Google. And then, you know, we, we slip back into the things that we know, we go, "Oh, well, okay, now I can get computing on demand, but, now it's just computing." Or I can get database on demand and it's, you know, it's got some of the same limitations of, of say, of database, right? It's still, you know, I have to think about IOPS and I have to think about caching, and other stuff. So, I think we do go through that and then we, you know, we have these sort of next paradigms that come along. So, you know, serverless was another one of those where it was like, okay, it seems sort of new. I don't have to, again, it was another level of like, I don't have to think about anything. And I was able to do that because, you know, there was either greater bandwidth available to me, or compute got cheaper. And what's been interesting is not the sort of, that specific thing, serverless in and of itself is just another way of doing compute, but the fact that it now gets applied as, sort of a no-ops model to, you know, again, like how do I provision a database? How do I think about, you know, do I have to think about the location of a service? Does that just get taken care of for me? So I think the Supercloud concept, and I did a thing and, and you and I have talked about it, you know, behind the scenes that maybe the, maybe a better name is Super app for something like Snowflake or other, but I think we're, seeing these these sort of evolutions over and over again of what were the big bottlenecks? How do we, how do we solve those bottlenecks? And I think the big thing here is, it's never, it's very rarely that you can take the old paradigm of what the thing was, the concept was, and apply it to the new model. So, I'll just give you an example. So, you know, something like VMware, which we all know, wildly popular, wildly used, but when we apply like a Supercloud concept of VMware, the concept of VMware has always been around a cluster, right? It's some finite number of servers, you sort of manage it as a cluster. And when you apply that to the cloud and you say, okay, there's, you know, for example, VMware in the cloud, it's still the same concept of a cluster of VMware. But yet when you look at some of these other services that would fit more into the, you know, Supercloud kind of paradigm, whether it's a Snowflake or a MongoDB Atlas or maybe what CloudFlare is doing at the edge, those things get rid of some of those old paradigms. And I think that's where stuff, you start to go, "Oh, okay, this is very different than before." Yes, it's still computing or storage, or data access, but there's a whole nother level of something that we didn't carry forward from the previous days. And that really kind of breaks the paradigm. And so that's the way I think I've started to think about, are these things really brand new? Yes and no, but I think it's when you can see that big, that thing that you didn't leave behind isn't there anymore, you start to get some really interesting new innovation come out of it. >> Yeah. And that's why, you know, lift and shift is okay, when you talk to practitioners, they'll say, "You know, I really didn't change my operating model. And so I just kind of moved it into the cloud. there were some benefits, but it was maybe one zero not three zeros that I was looking for." >> Right. >> You know, we always talk about what's great about cloud, the agility, and all the other wonderful stuff that we know, what's not working in cloud, you know, tie it into multi-cloud, you know, in terms of, you hear people talk about multi-cloud by accident, okay, that's true. >> Yep. >> What's not great about cloud. And then I want to get into, you know, is multi-cloud really a problem or is it just sort of vendor hype? But, but what's not working in cloud? I mean, you mentioned serverless and serverless is kind of narrow, right, for a lot of stateless apps, right? But, what's not great about cloud? >> Well, I think there's a few things that if you ask most people they don't love about cloud. I think, we can argue whether or not sort of this consolidation around a few cloud providers has been a good thing or a bad thing. I think, regardless of that, you know, we are seeing, we are hearing more and more people that say, look, you know, the experience I used to have with cloud when I went to, for example, an Amazon and there was, you know, a dozen services, it was easy to figure out what was going on. It was easy to figure out what my billing looked like. You know, now they've become so widespread, the number of services they have, you know, the number of stories you just hear of people who went, "Oh, I started a service over in US West and I can't find it anymore 'cause it's on a different screen. And I, you know, I just got billed for it." Like, so I think the sprawl of some of the clouds has gotten, has created a user experience that a lot of people are frustrated with. I think that's one thing. And we, you know, we see people like Digital Ocean and we see others who are saying, "Hey, we're going to be that simplified version." So, there's always that yin and yang. I think people are super frustrated at network costs, right? So, you know, and that's kind of at a lot of, at the center of maybe why we do or don't see more of these Supercloud services is just, you know, in the data center as an application owner, I didn't have to think about, well where, where does this go to? Where are my users? Yes, somebody took care of it, but when those things become front and center, that's super frustrating. That's the one area that we've seen absolutely no cost savings, cost reduction. So I think that frustrates people a lot. And then I think the third piece is just, you know, we're, we went from super centralized IT organizations, which, you know, for decades was how it worked. It was part of the reason why the cloud expanded and became a thing, right? Sort of shadow IT and I can't get things done. And then, now what we've seen is sort of this proliferation of little pockets of groups that are your IT, for lack of a better thing, whether they're called platform engineering or SRE or DevOps. But we have this, expansion, explosion if you will, of groups that, if I'm an app dev team, I go, "Hey, you helped me make this stuff run, but then the team next to you has another group and they have another group." And so you see this explosion of, you know, we don't have any standards in the company anymore. And, so sort of self-service has created its own nightmare to a certain extent for a lot of larger companies. >> Yeah. Thank you for that. So, you know, I want, I want to explore this multi-cloud, you know, by accident thing and is a real problem. You hear that a lot from vendors and we've been talking about Supercloud as this unifying layer across cloud. You know, but when you talk to customers, a lot of them are saying, "Yes, we have multiple clouds in our organization, but my group, we have mono cloud, we know the security, edicts, we know how to, you know, deal with the primitives, whether it's, you know, S3 or Azure Blob or whatever it is. And we're very comfortable with this." It's, that's how we're simplifying. So, do you think this is really a problem? Does it have merit that we need that unifying layer across clouds, or is it just too early for that? >> I think, yeah, I think what you, what you've laid out is basically how the world has played out. People have picked a cloud for a specific application or a series of applications. Yeah, and I think if you talk to most companies, they would tell you, you know, holistically, yes, we're multi-cloud, not, maybe not necessarily on, I don't necessarily love the phrase where people say like, well it happened by accident. I think it happened on purpose, but we got to multi-cloud, not in the way that maybe that vendors, you know, perceived, you know, kind of laid out a map for. So it was, it was, well you will lay out this sort of Supercloud framework. We didn't call it that back then, we just called it sort of multi-cloud. Maybe it was Kubernetes or maybe it was whatever. And different groups, because central IT kind of got disbanded or got fragmented. It turned into, go pick the best cloud for your application, for what you need to do for the business. And then, you know, multiple years later it was like, "Oh, hold on, I've got 20% in Google and 50% in AWS and I've got 30% in Azure. And, you know, it's, yeah, it's been evolution. I don't know that it's, I don't know if it's a mistake. I think it's now groups trying to figure out like, should I make sense of it? You know, should I try and standardize and I backwards standardize some stuff? I think that's going to be a hard thing for, for companies to do. 'cause I think they feel okay with where the applications are. They just happen to be in multiple clouds. >> I want to run something by you, and you guys, you and Aaron have talked about this. You know, still depending on who, which keynote you listen to, small percentage of the workloads are actually in cloud. And when you were with us at Wikibon, I think we called it true private cloud, and we looked at things like Nutanix and there were a lot of other examples of companies that were trying to replicate the hyperscale experience on Prem. >> Yeah. >> And, we would evaluate that, you know, beyond virtualization, and so we sort of defined that and, but I think what's, maybe what's more interesting than Supercloud across clouds is if you include that, that on Prem estate, because that's where most of the work is being done, that's where a lot of the proprietary tools have been built, a lot of data, a lot of software. So maybe there's this concept of sending that true private cloud to true hybrid cloud. So I actually think hybrid cloud in some cases is the more interesting use case for so-called Supercloud. What are your thoughts on that? >> Yeah, I think there's a couple aspects too. I think, you know, if we were to go back five or six years even, maybe even a little further and look at like what a data center looked like, even if it was just, "Hey we're a data center that runs primarily on VMware. We use some of their automation". Versus what you can, even what you can do in your data center today. The, you know, the games that people have seen through new types of automation through Kubernetes, through get ops, and a number of these things, like they've gotten significantly further along in terms of I can provision stuff really well, I can do multi-tenancy, I can do self-service. Is it, you know, is it still hard? Yeah. Because those things are hard to do, but there's been significant progress there. I don't, you know, I still look for kind of that, that killer application, that sort of, you know, lighthouse use case of, hybrid applications, you know, between data center and between cloud. I think, you know, we see some stuff where, you know, backup is a part of it. So you use the cloud for storage, maybe you use the cloud for certain kinds of resiliency, especially on maybe front end load balancing and stuff. But I think, you know, I think what we get into is, this being hung up on hybrid cloud or multi-cloud as a term and go like, "Look, what are you trying to measure? Are you trying to measure, you know, efficiency of of of IT usage? Are you trying to measure how quickly can I give these business, you know, these application teams that are part of a line of business resources that they need?" I think if we start measuring that way, we would look at, you know, you'd go, "Wow, it used to be weeks and months. Now we got rid of these boards that have to review everything every time I want to do a change management type of thing." We've seen a lot more self-service. I think those are the things we want to measure on. And then to your point of, you know, where does, where do these Supercloud applications fit in? I think there are a bunch of instances where you go, "Look, I have a, you know, global application, I have a thing that has to span multiple regions." That's where the Supercloud concept really comes into play. We used to do it in the data center, right? We'd had all sorts of technologies to help with that, I think you can now start to do it in the cloud. >> You know, one of the other things, trying to understand, your thoughts on this, do you think that you, you again have talked about this, like I'm with you. It's like, how is it that Google's losing, you know, 3 billion dollars a year, whatever. I mean, because when you go back and look at Amazon, when they were at that level of revenue where Google is today, they were making money, you know, and they were actually growing faster, by the way. So it's kind of interesting what's happened with Google. But, the reason I bring that up is, trying to understand if you think the hyperscalers will ever be motivated to create standards across clouds, and that may be a play for Google. I mean, obviously with Kubernetes it was like a Hail Mary and kind of made them relevant. Where would Google be without Kubernetes? But then did it achieve the objectives? We could have that conversation some other time, but do you think the hyperscalers will actually say, "Okay, we're going to lean in and create these standards across clouds." Because customers would love that, I would think, but it would sub-optimize their competitive advantage. What are your thoughts? >> I think, you know, on the surface, I would say they, they probably aren't. I think if you asked 'em the question, they would say, "Well, you know, first and foremost, you know, we do deliver standards, so we deliver a, you know, standard SQL interface or a SQL you know, or a standard Kubernetes API or whatever. So, in that, from that perspective, you know, we're not locking you into, you know, an Amazon specific database, or a Google specific database." You, you can argue about that, but I think to a certain extent, like they've been very good about, "Hey, we're going to adopt the standards that people want." A lot of times the open source standards. I think the problem is, let's say they did come up with a standard for it. I think you still have the problem of the costs of migration and you know, the longer you've, I think their bet is basically the longer you've been in some cloud. And again, the more data you sort of compile there, the data gravity concept, there's just going to be a natural thing that says, okay, the hurdle to get over to say, "Look, we want to move this to another cloud", becomes so cost prohibitive that they don't really have to worry about, you know, oh, I'm going to get into a war of standards. And so far I think they sort of realize like that's the flywheel that the cloud creates. And you know, unless they want to get into a world where they just cut bandwidth costs, like it just kind of won't happen. You know, I think we've even seen, and you know, the one example I'll use, and I forget the name of it off the top of my head, but there's a, there's a Google service. I think it's like BigQuery external or something along those lines, that allows you to say, "Look, you can use BigQuery against like S3 buckets and against other stuff." And so I think the cloud providers have kind of figured out, I'm never going to get the application out of that other guy's cloud or you know, the other cloud. But maybe I'm going to have to figure out some interesting ways to sort of work with it. And, you know, it's a little bit, it's a little janky, but that might be, you know, a moderate step that sort of gets customers where they want to be. >> Yeah. Or you know, it'd be interesting if you ever see AWS for example, running its database in other clouds, you started, even Oracle is doing that with, with with Azure, which is a form of Supercloud. My last question for you is, I want to get you thinking about sort of how the future plays out. You know, think about some of the companies that we've put forth this Supercloud, and by the way, this has been a criticism of the concept. Charles Fitzer, "Everything is Supercloud!" Which if true would defeat the purpose of course. >> Right. >> And so right with the community effort, we really tried to put some guardrails down on the essential characteristics, the deployment models, you know, so for example, running across multiple clouds with a purpose build pass, creating a common experience, metadata intelligence that solves a specific problem. I mean, the example I often use is Snowflake's governed data sharing. But yeah, Snowflake, Databricks, CloudFlare, Cohesity, you know, I just mentioned Oracle and Azure, these and others, they certainly claim to have that common experience across clouds. But my question is, again, I come back to, do customers need this capability? You know, is Mono Cloud the way to solve that problem? What's your, what are your thoughts on how this plays out in the future of, I guess, PAs, apps and cloud? >> Yeah, I think a couple of things. So, from a technology perspective, I think, you know, the companies you name, the services you've named, have sort of proven that the concept is viable and it's viable at a reasonable size, right? These aren't completely niche businesses, right? They're multi-billion dollar businesses. So, I think there's a subset of applications that, you know, maybe a a bigger than a niche set of applications that are going to use these types of things. A lot of what you talked about is very data centric, and that's, that's fine. That's that layer is, figuring that out. I think we'll see messaging types of services, so like Derek Hallison's, Caya Company runs a, sort of a Supercloud for messaging applications. So I think there'll be places where it makes a ton of sense. I think, the thing that I'm not sure about, and because again, we've been now 10 plus years of sort of super low, you know, interest rates in terms of being able to do things, is a lot of these things come out of research that have been done previously. Then they get turned into maybe somewhat of an open source project, and then they can become something. You know, will we see as much investment into the next Snowflake if, you know, the interest rates are three or four times that they used to be, do we, do we see VCs doing it? So that's the part that worries me a little bit, is I think we've seen what's possible. I think, you know, we've seen companies like what those services are. I think I read yesterday Snowflake was saying like, their biggest customers are growing at 30, like 50 or 60%. Like the, value they get out of it is becoming exponential. And it's just a matter of like, will the economics allow the next big thing to happen? Because some of these things are pretty, pretty costly, you know, expensive to get started. So I'm bullish on the idea. I don't know that it becomes, I think it's okay that it's still sort of, you know, niche plus, plus in terms of the size of it. Because, you know, if we think about all of IT it's still, you know, even microservices is a small part of bigger things. But I'm still really bullish on the idea. I like that it's been proven. I'm a little wary, like a lot of people have the economics of, you know, what might slow things down a little bit. But yeah, I, think the future is going to involve Supercloud somewhere, whatever people end up calling it. And you and I discussed that. (laughs) But I don't, I don't think it goes away. I don't think it's, I don't think it's a fad. I think it is something that people see tremendous value and it's just, it's got to be, you know, for what you're trying to do, your application specific thing. >> You're making a great point on the funding of innovation and we're entering a new era of public policy as well. R and D tax credit is now is shifting. >> Yeah. >> You know, you're going to have to capitalize that over five years now. And that's something that goes back to the 1950s and many people would argue that's at least in part what has helped the United States be so, you know, competitive in tech. But Brian, always great to talk to you. Thanks so much for participating in the program. Great to see you. >> Thanks Dave, appreciate it. Good luck with the rest of the show. >> Thank you. All right, this is Dave Vellante for John Furrier, the entire Cube community. Stay tuned for more content from Supercloud2.

>>Hey everyone. Welcome back to Chicago. The Cube is excited to be live on day two of Ansible Fest, 2022. Lisa Martin and John Fur. You're here having some great conversations, a lot of cube alumni, a lot of wisdom from the Ansible community coming at you on this program this week. You know, John, we've been, we've been hearing stories about the power and the capabilities and the collective wisdom of the Ansible community. You can feel it here. Yeah, there's no doubt about that. It's, Ansible is nothing, as Stephanie Chair said yesterday, if not a community and the significant contributions that it makes over and over again, or it's fuel. >>I mean the power of the community is what drives Ansible is gonna drive the future of, I think, cloud in our next generation modern application environment. And it's collective intelligence. It's a production system at the end of the day. And I think these guys have harnessed it. So it should be a really great segment to talk about all the contributor work that's been done. So I'm looking forward to it. >>We've got two great alumni here to talk about the contributor work, how you can get involved. Please welcome back to the cube. Carol Chen, principal community architect at Red Hat. Adam Miller joins us as well, fresh from the keynote stage senior principal software engineer at Red Hat. Guys, great to have you on the cube. Great to be here. Yeah, thank you. So we, we talked, we enjoyed your keynotes, Adam, and what you were talking about on stage, the Ansible contributor summit. That's, you guys have been doing what, this is the seven you've had seven so far in just a couple of years. >>Well, we had seven virtual contributor summits. >>Seven virtual. This is the first Monday was the first in person in. >>First in person since the pandemic and actually the 15th contributor summit overall >>15th overall. Talk about the contributor summits, what the contributors are able to do and the influence that it's having on Ansible Red Hat and what people are able to do with cloud. At the Edge automation. Yeah. >>So our community contributors have always had ways to influence and contribute to the project. But the contributor Summit is really a place where we can get people together, preferably in the same place so that we can, you know, have a really great dynamic conversations and interactions. But we also want to make sure that we don't leave out people who have been constantly online joining us. So this year we are so happy to be here in Chicago in person. We've had about 60 to 70 here joining us. And at first I thought maybe we'll have one third of the attendees joining online because about 30 to 40 people signed up to join online. But in the end, we have more than 100 per people watching our live stream. So that's more than half of the attendees overall, were joining us online. So that really shows where, you know, the contributors are interested in participating for >>Develop. Right. Yeah, it's been, it's been interesting. It's been since 2019, since the in-person Ansible Fest in Atlanta. Now we're in Chicago, we had the pandemic. Couple interesting observations from our side that I wanna get your reaction to Adam Carol. And that is one Ansible's relevance has grown significantly since then. Just from a cloud growth standpoint, developer open source standpoint, and how people work and collaborate has changed. So your contributor based in your community is getting more powerful in scope, in my opinion. Like in, as they become, have the keys to the kingdom in the, in their respective worlds as it gets bigger and larger. So the personas are changing, the makeup of the community's changing and also how you guys collaborate is changing. Can you share your, what's going on with those two dynamics? Cause I think that power dynamic is, is looking really good. How are you guys handling >>That? Yeah, so I mean, I, I had the opportunity to represent the community on stage yesterday as part of the keynote and talk to this point specifically is one of the things that we've seen is the project has had the opportunity to kind of grow and evolve. There's been certain elements that have had to kind of decompose from a technology perspective. We actually had to kind of break it apart and change the architecture a little bit and move things into what are called Ansible collections, which, you know, folks here are very familiar with No One Love. And we've seen a lot of community work in the form of working groups coalesce around those organically. However, they've done so in kind of different ways. They, they pick tools and collaboration platforms that are popular to their subject matter expertise audience and things like that. So we find ourselves in a place where kind of the, the community itself had more or less segmented naturally in a way. And we needed to find ways to, you know, kind of ke that >>Fragmentation by demographics or by expertise or both as >>A Mostly, mostly expertise. Yeah. And so there was a open source technology called Matrix. It is a open source, standardized, federated messaging platform that we're able to use to start to bridge back some of those communities that have kind of broken off and, and made their their own home elsewhere on the internet. So now we're able to, for example, the right, the docs organization, they had a, a group of people who was very interested in contributing to the Ansible documentation, but they'd already self-organized on Discord. And what was interesting there is the existing team for the Ansible documentation, they were already on internet Relay Chat, also known as irc. And Matrix allowed us to actually bring those two together and bridge that into the other matrix cha chat channels that we had. So now we're able to have people from all over the world in different areas and different platforms, coalesce and, and cross. It's like a festival cross pollinate. Yeah. >>And you're meeting the contributors exactly where they are and where they want to be, where they're comfortable. >>Yes. Yeah, we always say we, we reach out to where they are. So, >>And, and, and much in the way that Ansible has the capability to reach out to things in their own way, Right. And allow that subject matter expertise to, you know, cause the technology has the potential and possibility and capability to talk to anything over any protocol. We're able to do, you know, kind of the same thing with Matrix, allowing us to bridge into any chat platform that it has support for bridging and, and we're able to bring a lot of people >>Together. Yeah. And how's that, how's the feedback been on that so far? >>I, I think it has been very positive. For example, I want to highlight that the technical writers that we have contributing via Discord is actually a group from Nigeria. And Dave also participated in the contributor summit online virtually joining us in, in, you know, on the matrix platform. So that, that bridge that really helps to bring together people from different geographical regions and also different topics and arenas like that. >>So what were some of the outcomes of the contributor summit? The, the first in person in a while, great. That you guys were able to do seven virtually during the pandemic. That's hard. It's hard to get people together. You, there's so much greatness and innovation that comes when we're all together in person that just can't replicate by video. You can do a lot. Right. But talk about some of the outcomes from Monday. What were some of the feedback? What were some of the contributions that you think are really going to impact the community? >>I think for a lot of us, myself included, the fact that we are in person and meeting people face to face, it helps to really build the connections. And when we do talk about contribution, the connection is so important that you understand, well this person a little bit about their background, what they've done for the SPO project and or just generally what, what they're interested in that builds the rapport and connection that helps, you know, further, further collaboration in the future. Because maybe on that day we did not have any, you know, co contributions or anything, but the fact that we had a chance to sit together in the same place to discuss things and share new ideas, roadmaps is really the, the kind of a big step to the future for our community. Yes, >>Yes. And in a lot of ways we often online the project has various elements that are able to function asynchronously. So we work very well globally across many time zones. And now we were able to get a lot of people in the same place at the same time, synchronously in the same time zone. And then we had breakout sessions where the subject matter, you know, working groups were able to kind of go and focus on things that maybe have been taking a little while to discuss in, in that asynchronous form of communication and do it synchronously and, you know, be in the same room and work on things. It's been, it's been fantastic >>Developers there, like they, they take to asynchronous like fish to water. It's not a problem. But I do want to ask if there's any observations that you guys have had now that we're kind of coming out of that one way, but the pandemic, but the world's changed. It's hybrid, hybrid work environment, steady state. So we see that. Any observations on your end on what's new that you observed that people are gravitating to? Is there a pattern of styles is or same old self-governing, or what's new? What do you see that's coming out of the pandemic that might be a norm? >>I I think that even though people are excited to get back in person, there are, things have changed, like you said, and we have to be more aware of, there are people who think that not be in person, it's okay. And that's how they want to do it. And we have to make sure that they, they are included. So we, we did want to make a high priority for online participation in this event. And like I said, even though only 4 30, 40 people signed up to join us online initially, so that it was what we were expecting, but in the end, more than 100 people were watching us and, and joining participation in >>Actually on demand consumption be good too, >>Right? Yeah. So, you know, I think going forward that is probably the trend. And as, as much as we, we love being in person, we, we want this to continue that we, we take care of people who are, has been constantly participating online and contributing you >>Meaning again, meaning folks where they are, but also allowing the, the, those members that want to get together to, to collaborate in person. I can only imagine the innovation that's gonna come even from having part of the back, Right. >>And, and not to continue to harp on the matrix point, but it, it's been very cool because Matrix has the ability to do live video sessions using open source another to open source technology called jy. So we're able to actually use the same place that we normally find ourselves, you know, congregating and collaborating for the project itself in an asynchronous and, you know, somewhat synchronous way to also host these types of things that are, are now hybrid that used to be, you know, all one way or all the other. Yeah. And it's been, it's >>Been incredible. Integration is, the integration is have been fascinating to watch how you guys do that. And also, you know, with q we've been virtual too. It's like, it's like people don't want another microsite, but they want a more of a festival vibe, a hub, right? Like a place to kind of check in and have choice, not get absolutely jammed into a, you know, forum or, you know, or whatever. Hey, if you wanna be on Discord, be on Discord, right? Why >>Not? And we still, you know, we do still have our asynchronous forms of >>Work through >>Our get GitHub. We have our projects, we have our issues, we have our, you know, wiki, we have various elements there that everybody can continue to collaborate on. And it's all been, it's all been very good. >>Speaking of festivals, octoberfest that's going on, not to be confused with Octoberfest, that was last month. Talk about how the Ansible project and the Ansible community is involved in Octoberfest. Give us the dates, Carol. So >>YesTo Fest is a annual thing in October. So October Octoberfest, I think it's organized by Digital Ocean for the past eight or nine years. And it's really a, a way to kind of encourage people to contribute to open source projects. So it's not anal specific, but we as an Ansible project encourage people to take this opportunity to, you know, a lot of them doing their first contributions during this event. And when, when we first announced, we're participating in Octoberfest within the first four days of October, which is over a weekend actually. We've had 24 contributions, it, 24 issues fixed, which is like amazing, like, you know, just the interest and the, the momentum that we had. And so far until I just checked with my teammates this morning that we've had about 35 contributions so far during the month, which is, and I'm sorry, I forgot to mention this is only for Ansible documentation. So yeah, specifically. And, and that's also one thing we want to highlight, that contributions don't just come in code in, you know, kind of software side, but really there's many ways to contribute and documentation is such a, a great way for first time users, first time contributors to get involved. So it's really amazing to see these contributions from all over the world. And also partly thanks to the technical writers in Nigeria kind of promoting and sharing this initiative. And it's just great to see the, the results from that. Can >>You double click on the different ways of contribution? You mentioned a couple documentation being one, code being the other, but what is the breadth of opportunities that the contributors have to contribute to the project? >>Oh, there's, there's so many. So I actually take care more of outreach efforts in the community. So I helped to organize events and meetups from around the world. And now that we're slowly coming out of the pandemic, I've seen more and more in person meetups. I was just talking to someone from Minneapolis, they're trying to get, get people back together again. They have people in Singapore, in Netherlands from pretty much, you know, all corners of the globe wanting to form not just for the Ansible project, but the local kind of connection with the re people in the region, sometimes in their own language, in their local languages to really work together on the project and just, >>You know, you to create a global Yeah. Network, right? I mean it's like Ansible Global. >>Exactly. >>Create local subnets not to get all networking, >>Right? >>Yeah. >>Yeah. One, one quick thing I want to touch on Theto Fest. I think it's a great opportunity for existing contributors to mentor cause many people like to help bring in new contributors and this is kind of a focal point to be able to focus on that. And then to, to the the other point we, you know, it, it's been, it's been extremely powerful to see as we return these sub communities pop up and, and kind of work with themselves, so on different ways to contribute. So code is kind of the one that gets the most attention. I think documentation I think is a unsung hero, highly important, great way. The logistical component, which is invaluable because it allows us to continue with our adoption and evangelization and things like that. So specifically adoption and evangelize. Evangelization is another place that contributors can join and actually spawn a local meetup and then connect in with the existing community and try to, you know, help increase the network, create a new subject. Yeah. >>Yeah. Network affects huge. And I think the thing that you brought up about reuse is, is part of that whole things get documented properly. The leverage that comes out of that just feeds into the system that flywheel. Absolutely. I mean it's, that's how communities are supposed to work, right? Yep. Yes. >>That's what I was just gonna comment on is the flywheel effect that it's clearly present and very palpable. Thank you so much for joining John, me on the program, talking about the contributors summit, the ways of contribution, the impacts that are being made so far, what Octoberfest is already delivering. And we're, we still have about 10 days or so left in October, so there's still more time for contributors to get involved. We thank you so much for your insights and your time. Thank >>You. Thank you so much for having us. >>Our pleasure. For our guests and John Purer, I'm Lisa Martin. You're watching The Cube Live from Chicago, day two of our coverage of Red Hat Ansible Summit 22. We will see you right n after this short break with our next guest.

>>Welcome back to Los Angeles, Lisa Martin and Dave Nicholson here on day three of the cubes, coverage of coop con and cloud native con north America, 21, Dave, we've had a lot of great conversations. The last three days it's been jam packed. Yes, it has been. And yes, it has been fantastic. And it's been live. Did we mention that it's inline live in Los Angeles and we're very pleased to welcome one of our alumni back to the program. David Stephanie is here. The CEO of Trulio David. Welcome back. It's good to see you. >>Thanks for having me. It's good to be here. Isn't it great to be in person? Oh man. It's been a reunion. >>It hasn't been a reunion and they have Ubered been talking about these great little, have you seen these wristbands that they have? I actually asked >>For two, cause I'm a big hugger, so >>Excellent. So, so here we are day three of coupon. That's actually probably day five, our third day of coverage. I'm losing track to it's Friday. I know that, that I can tell you, you guys announced two dot five a couple of weeks ago. Tell us what's in that. What's exciting. Before we crack open Twilio, uh, choy. >>Sure, sure. Well, it's been exciting to be here. Look, the theme right of resiliency realize has been it's right up our wheelhouse, right? To signal that more people are getting into production type of environments. More people require data protection for cloud native applications, right? And, uh, there's two dot five releases. It is as an answer to what we're seeing in the market. It really is centered predominantly around, uh, ransomware protection. And uh, you know, for us, when we look at this, I I've done a lot of work in, in cybersecurity, my career. And we took a hard look about a year ago around this area. How do we do this? How do we participate? How do we protect and help people recover? Because recovery that's part of the security conversation. You can talk about all the other things, but recovery is just as important. And we look at, uh, everything from a zero trust architecture that we provide now to adhering, to NIST standards and framework that's everything from immutability. Uh, so you can't touch the backups now, right? Uh, th that's fine to encryption, right? We'll encrypt from the application all the way to that, to the storage repository. And we'll leverage Keem in that system. So it's kind of like Bitcoin, right? You need a key to get your coin. You as an end-user only have your key to your data alone. And that's it. So all these things become more and more important as we adopt more cloud native technology. And >>As the threat landscape changes dramatically. >>Oh yeah. I got to tell you right. Every time we, you, you publish an application into another cloud, it's a new vector, right? So now I'm living in a multi-cloud world where multiple applications in my data now lives, right? So people are trying to attack backups through, uh, consoles and the ministry of consoles to the actual back of themselves. So new vectors, new problems need new solutions. >>And you mentioned, you mentioned something, you, you, you asked the question, how do we participate? And we are here at KU con uh, w uh, cloud native foundation. So what about, what's your connection to the open source community and efforts there? How do you participate in that? >>Yeah, so it's a really great question because, you know, uh, we are a closed source solution that focuses all of our efforts on the open source community and protecting cloud native applications. Our roots have been protecting cloud native applications since 2013, 2014, and with a lot of very large logos. And, um, you know, through time there are open source projects that do emerge, you know, in this community. And for example, Valero is an open source data protection platform, um, for all of its goodness, as a, as a community-based project, they're also deficiencies, right? So Valero in itself is, uh, focuses only on label based applications. It doesn't really scale. It doesn't have a UI it's really CLI driven, which is good for some people and it's free. But you know, if you need to really talk about an enterprise grade platform, this is where we pick up, you know, we, in our last release, we gave you the ability to capture your Valero based backups. And now you want to be an adult with an enterprise caliber, you know, backup solution and continue to protect your environment and have compliance and governance needs all satisfied. That's where, that's where we really stand out. >>Well, when you're talking to customers in any industry, what are the things that you talk about in terms of relief, categorizing the key differentiators that really make Trulia stand out above the competition? >>Yeah. Cause there, there a bunch of, they're a bunch of great competitors out there. There's no doubt about it. A lot of the legacy folks that you do see perhaps on those show floor, they do tuck in Valero and under the, under the covers, they can check a box or you can set aside some customer needs some of the pure play people that, that we do see out there, great solutions too. But really where we shine is, you know, we are the most flexible agnostic solution that there is in this market. And we've had people like red hat and Susa and verandas, digital ocean and HPS morale. And the list goes on, certify, say, Trulio is the solution of choice. And now no matter where you are in this journey or who you're using, we have your back. So there's a lot of flexibility. There we are complete storage agnostic. >>We are cloud agnostic in going back to how you want to build our architecture application. People are in various phases in their, in their journey. A lot of times, many moons ago, you may have started with just a label based application. Then you have another department that has a new technique and they want to use helm, or you may be adopting open shift and you're using operators to us. It doesn't matter. You have peace of mind. So whether you have, you have to protect multiple departments or you as an end user, as one single tenant are using various techniques, we'll discover or protect and we can move forward. >>So if you looked at, if you look at it from a workload basis, um, and you look at your customers are the workloads that you're protecting. What's, what's the mix of what you think of as legacy virtualized things versus containerized things. And then, and then, and then the other kind of follow on to that is, um, are you seeing a lot of modernization and migration or are you seeing people leave the legacy things alone and then develop net new in sort of separate silos? >>Yeah. So that's a great question. And I, to tell you the answer varies, that's, that's the honest answer, right? You end up having, you may have a group or a CIO that says, look, your CTO says, we're moving to this new architecture. The water's great, bring your applications in. And so either it's, we're going to lift and shift an application and then start to break it apart over time and develop microservices, or we're gonna start net new. And it really does run, run the gambit. And so, you know, as we look at, for some of those people, they have peace of mind that they can bring their two on applications in and we can recover. And for some people that say, look, I'm going to start brand new, and these are gonna be stateless applications. Um, we've seen this story before, right? Our, our, uh, uh, I joke around, it's kinda like the movie Groundhog's day. >>Uh, you know, we, we started many moons ago within the OpenStack world and we started with stateless to stateful. Always, always, always finds a way, but for the stateless people, um, when you start thinking about security, I've had conversations with CSOs around the world who say, I'm going to publish a stainless application. What I'm concerned about things like drift, you know, what's happening in runtime may be completely different than what I intended. So now we give you the ability to capture that runtime state compare. The two things identify what's changed. If you don't like what you see, and you can take that point in time recovery into a sandbox and forensically take it apart. You know, one of our superpowers, if you will, is the, our point in time, backups are all in an open format. Everyone else has proprietary Schemos. So the benefit of an open format is you have the ability to leverage a lot of third party tooling. So take a point in time, run scanners across it. And it, God forbid Trulio goes away. You still have access and you can recreate a point in time. So when you start thinking about compliance, heavy environments, think about telcos, right? Or financial institutions. They have to keep things for 15 years, right? Technologies change, architectures change. You can't have that lock-in >>So we continue to thrive. And on that front, one of the marketing terms that we hear a lot, and I want to get your opinion on this as a feature proofing, how do you, what does, what does it mean to you and Trillium and how do you enable that for organizations, like you said, for the FSI is I have to keep data for 15 years and other industries that have to keep it for maybe even longer. >>I mean, right. The future proof, uh, you know, terminology, that's part of our mantra actually, when I talked about, you know, a superpower being as agnostic and flexible as can be right, as long as you adhere to standards, right? The standards that are out here, we have that agnostic play. And then again, not just capturing an applications, metadata data, but that open format, right? Giving you that open capability to unpack something. So you're not, there is no, there is no vendor lock-in with us at all. So all these things play a part into, into future-proofing yourself. And because we live and breathe cloud native applications, you know, it's not just Kubernetes right? Over the course of time, there'll be other things, right. You're going to see mixed workloads too. They're gonna be VM based in the cloud and container based in the cloud and server lists as well. But you, as long as you have that framework to continuously build off of it, that's, that's where we go. You know, uh, it shouldn't matter where your application lives, right? At the end of the day, we will protect the application and its data. It can live anywhere. So conversations around multi-cloud change, we start to think and talk across cloud, right? The ability to move your application, your data, wherever it, wherever it needs to be to. >>Well, you talked about recoverability and that is the whole point of backing up video. You have to be able to recover something that we've seen in the last 18, 19 months. Anyone can backup >>Data. >>That's right. That's right. If you can't recover it, or if you can't recover it in time. Yeah. We're talking like going on a business potential and we've seen the massive changes in the security landscape in the last 18, 19 months ransomware. I was looking at some, some cybersecurity data that showed that just in the first half of this calendar year, January one to June 30, 20, 21, ransomware was up nearly 11 X DDoS attacks are up. We've got this remote workforce. That's going to probably persist for a while. So the ability to recover data from not if we get hit by ransomware, but when we get hit by ransomware is >>When you're, you're absolutely right. And, and, and to your plate anyway. So anyone can back up anything. When you look at it, it's at its highest form. We talk about point time where you orchestration, right. Backup is a use case. Dr. Is a use case, right? How do you, reorchestrate something that's complex, right? The containers, these applications in the cloud native space, there are morphous, they're living things, right? The metadata is different from one day to the next, the data itself is different from when one day the net to the next. So that's, what's so great about Trillium. It's such an elegant solution. It allows your, reorchestrate a point in time when and where you need it. So yes. You have to be able to recover. Yes. It's not a matter of if, but when. Right. And that's why recovery is part of that security conversation. Um, you know, I I've seen insurance companies, right? They want to provide insurance for ransomware. Well, you're gonna have enough attacks where they don't want to provide that insurance anymore. It costs too much. The investment that you make with, with Trulio will save you so much more money down the road. Right. Uh, who's our product manager actually gave a talk about that yesterday and the economics were really interesting. >>Hmm. So how has the recovery methodology who participates in that changed over time? As, as we, you know, as we are in this world of developer operators who take on greater responsibility for infrastructure things. Yeah. Who's, who's responsible for backup and recovery today and how, how has that changed >>Everyone? Everyone's responsible. So, you know, we rewind however many years, right? And it used predominantly CIS admin that was in charge of backup administrator, but a ticket in your backup administrator, right. Cloud native space and application lifecycle management is a team sport. Security is a team sport. It's a holistic approach. Right? So when you think about the, the team that you put out on the field, whether your DevOps, your SRE dev sec ops it ops, you're all going to have a need for point in time, we orchestration for various things and the term may not be backup. Right? It's something else. And maybe for test dev purposes, maybe for forensic purposes, maybe for Dr. Right. So I say it's a team sport and security as a holistic thing that everyone has to get on board with >>The three orchestration is exactly the right way to talk about absolute these processes. It's not just recovery, you're rebuilding >>Yeah. A complex environment. It's always changing. >>That's one of the guarantees. It's always going to be changing >>That much. >>Can you give us a, leave us with a customer example that you think really articulates the value of what Trulio delivers? >>Yeah. So it's interesting. I won't say who the customer is, but I'll tell you it's in the defense agency, it's a defense agency. Uh, they have developers all over the place. Uh, they need self-service capabilities for the tenants to mind their own backups. So you don't need to contact someone, right. They can build, they have one >>Dashboard, single pane of glass or truth to manage all their Corinthians applications. And it gives them that infrastructure to progress whether your dev ops or not your it ops, uh, this, this group has rolled it out across the nation and they're using in their work with very sensitive environments. So now we have they're back. And what are some of the big business outcomes that they're achieving already? >>The big business outcomes? Well, so operational efficiencies are definitely first and foremost, right? Empowering the end user with more tools, right? Because we've seen this shift left and people talking about dev ops, right. So how do I empower them to do more? So I see that operational efficiency, the recoverability aspect, God forbid, something goes wrong. How do you, how do you do that in the cost of that? Um, and then also, um, being native to the environment, the Trillium solution is built for Kubernetes. It is built on go. It is a Qubit stateless Kubernetes application. So you have to have seamless integration into these environments. And then going back to what I was saying before, knowing peace of mind, the credibility aspect, that it is blessed by, you know, red hat and suicide Mirandas and all these other, other folks in the field, um, that you can guarantee it's going to work >>Well, that helps to give your customers the confidence that there, and that confidence might sound trivial. It's not, especially when we're talking about security, it's not at all that, that's a, that's a big business outcome for you guys. When a customer says, I'm confident I have the right solution, we're going to be able to recover when things happen, we try, we fully trust in the solution that we're, >>And we'll bring more into production faster that helps everyone out here too. Right? It feels good. You have that credibility. You have that assurance that I can move faster and I can move into different clouds faster. And that's, we're gonna continue to put, we're gonna continue to push the envelope there. You know, coming a, as we look into, you know, going forward, we're going to come out with other capabilities. That's going to continue to differentiate ourselves from, from folks. Uh, we'll, we'll talk about in time, the ability to propagate data across multiple clouds simultaneously. So making RTOs look at the split seconds and minutes. And so I hope that we can have that conversation next time we were together, because it's really exciting. >>Any, any CTA that you want to give to the audience, any, any, uh, like upcoming or recent webinars that you think they would be really benefit from? >>I guess one thing I put out there is that, um, I understand that people need to continuously learn. There is a skillset hole in, in this market. We can, we understand that, you know, and people look to us as not just a vendor, but a partner. And a lot of the questions that we do get are how do I do this? Or how do I do that? Engage us, ask us to consume our product is really, really easy. You can download from the website or go to an, you know, red hats operator hub, or go to the marketplace over at Susa, and let's begin to begin and we're here to help. And so reach out, right? We want everyone to be successful. >>Awesome. trillium.io. David, thank you for joining us. This has been an exciting conversation. Good >>To see you all. >>Likewise. Good to see you in person take care. We look forward to the next time we see you when unpacking what other great things are going on on Trulia. We appreciate your >>Time. Thank you so much. Good to be here >>For David's fie and David Nicholson, the two Davids I'm going to sandwich. I'm Lisa Martin, you we're coming to you live from Los Angeles. This is Q con cloud native con north America, 2021. Stick around our next guest joins us momentarily.

>> From theCUBE studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are cloud native insights. >> Welcome to another episode of Cloud Native Insights. I'm your host Stu Miniman and of course with Cloud Native Insights will really help understand you know, where we have gone from cloud, how we are taking advantage of innovation, a real driver for what happens in the spaces of course developers. You think back to the early days, it was often developers that were grabbing a credit card, using cloud services and then it had to be integrated into what was being done and the rest of the organization saw the large rise of DevOps and all the other pieces around that, that help bring in things like security and finance and the like. Happy to welcome to the program first time guest, William Janssen. He is the CEO of DeltaBlue. Deep in this discussion of cloud native DeltaBlue is a European company helping with continuous deployment across cross cloud providers in the space. William, thanks so much for joining us, nice to see you. >> Glad to be on the show, thank you Stu. >> All right, so one of the reasons I'm glad to have you on is because of some of the early episodes here, you know we were discussing really what cloud native is and what it should be. I had my first interview on the program, Joep Piscaer, who you know, had given the analogy and said when you talked about DevOps, DevOps isn't something you could buy. But it's something that lots of vendors would try to sell you. And we're trying to dispel, lots of companies out there, they're like, "Oh, cloud native, well we support Kubernetes. "And we have this tool and you should buy our cloud native, "you know, A, B, C or D." So, want to start a little first with what you see out there and what you think the ultimate goal and outcome of cloud native should be? >> I think cloud native, to start with your last question, I think cloud native should make life fun again. We have a lot of technical problems, we solve them in technical things. You mentioned Kubernetes but Kubernetes is solving a technical problem. And introducing another technical problem. So what I think cloud native should do is focus on what you're actually good at. So a developer should develop. Someone from the infrastructure, an operator, should focus on their key points and not try to mix it up. So, not Kubernetes, Kubernetes is again introducing another technical issue. Our view on cloud native is that people should have fun again and should be focusing on what they're good at. And so it's not about technology, it's about getting the procedures right and focusing on the things you love to do. And not to talk to the cross border, talk to a lot of developers and solve operational kind of things. That's what we try to solve and that's our view of cloud native. >> Yeah, I'll poke that a little bit because one thing you say, people should do what they're good at. It's really what is important for the business, what do we need to get done? There's often new skills that we need to do. So it's really great if we could just keep doing the same thing we're doing. We know how to do it. We optimize it, we play with all of our geek knobs. But the drumbeat that I hear is, we need to be agile, we need to be able to create new applications. IT needs to be responsive for the business and rather than in the past it was about, building this beautiful stack that we could optimize and build these pieces together. Today, the analogy I hear more is, there's layers out there, there's lots of different tooling, especially if you look at the developer world. There is just too many options out there. So, maybe bring us a little bit as to you know, what DeltaBlue does. How you look at allowing developers to build what they, new things that they need but not be, I guess the word, locked into a certain place or certain technology. >> Yes, I've been on IT for 20 years. So I've seen a lot of things go around. And when we started out with DeltaBlue, the only thing we had in mind is how could we make the lifecycle of applications and all the things you had to do, the government around applications way more easy. Back in the days, we already saw that containerization solved some of the issues. But it solves technical issues. So like when you start coding, you don't need to go to the network card anymore. We took the same approach to our cloud native approach. So we started on the top level. We started with applications in mind. And the things back in the day you had Bitnami already had the option to have a VM or standard installation of an application. So what we see is that nowadays, many developers and many organizations try to focus on that specific part, how to get your code into some kind of under configuration solution. We take that for granted. There are so many great solutions out there, already tried to solve that problem. So instead of reinventing that wheel again, we take that for granted. But we take another approach. We think that if the application is there, you need to test it. You need to take it into production. You want to have several versions of a specific application into the production environment. So what we've tried to solve with our platform is to make that part of the life cycle, let's call it horizontal version of your application lifecycle, not getting an application built or running up different stuff, we take that for granted. We take the horizontal approach. How to get your traditional application from your development environment to your testing, acceptance. That's a different kind of people test your application, security testing before you take it into production. And that should be all be done from a logical point of view. So we built one web interface, a logical portal. And you can simply drag and drop any type of application, not just a more than micro service oriented or Kubernetes based application but any type of application from your acceptance environment to your production environment. That's going to solve the real problem. So now, any business can have 10 different acceptance environments for even your old legacy SAP or your Intershop environment. That's going to get your business value. So going back to your definition of cloud native, getting that kind of abstraction between getting your and code your application and get it get somewhere up and running and all the stuff that's needs to be done from your development environment into the production environment. That's going to add to your business value. That's going to speed up your time to market, that's going to make sure that you have a better cloud quality because now you can test even your legacy application from 10 different points of view and 10 different types of different branches, all in a parallel environment. So, when we started with DeltaBlue, we took a different approach, took the technical stuff for granted, and focus on all the government around applications and the governance that's the thing, I think that's the most important part in the cloud native discussion. >> So governance, especially in Europe, has a lot of importance there. If you could, bring us inside a little bit, customers you're talking to, where they are in this journey. If you've got an example of something you're doing specifically we'd love to hear how that happens in real world. >> Yes we have many different customers but I think one of our best examples, for example is Wunderman Thompson, a big eCommerce party across the globe but also here in the Netherlands. And we made a blueprint of their development environment the way they develop application and the way they host applications. So, now they started a new project, 40 developers go to the new big eCommerce application. In the past, everyone had to install their own Intershop environment on their own laptop, Java, Oracle, that kind of stuff. It took me a day and a half. Since we abstracted that into like a simple cell, like you would do in any serverless environment nowadays, they can now simply click on a button. And since they made their laptop or their development environment part of our platform, they can now simply drag and drop the complete initial environment to the laptop and they can send development in 10 minutes instead of a day and a half. That's just the first step that makes their life easier. But also imagine, we have an application up and running for two, three months and our security patch, we all know the trouble of getting a patch installed in production but also then install it into the acceptance environment, test environment, development environment, all those kind of different versions. With our platform, since we have the application in mind, we can, with simple one simple click of the button, we can propagate that security patch across all the different environments. So from a developer point of view, there's no need to have any kind of knowledge of course they need to configure a port or something like that but no need of knowledge of any type of infrastructure anymore. We have made the same blueprint for the complete development environment. So with a single click of the button, they have a complete detail environment, known over the need to go to their infrastructure to get the service to their operating guys, they have them installed, industrial Nexus, very book of repository, all that kind of stuff. It's all within one blueprint. So again, we think that the application should come first. That should be abstracted, and not abstracted just in a single spin up a container or spinning up a VM. Now, the complete business case, application, complete environment should be up and running with a single click of a button. So now they can start if they have a demo tomorrow, for example, and they want to have a demo setup. With a single click, they have a complete environment up and running, instead of having to wait three weeks, four weeks before they can start coding. And the same comes with a production environment. We now have an intelligent proxy in front of it. So they can have three different versions of the same shot in their production environment. And based on business rules, we can spread the load against the different versions of a business application, eCommerce application. We signed a new contract with New Relic last week. And the next thing we're going to do, and it's going to be there in two weeks, is fit New Relic data, I mean, an eCommerce application is about performance. A longer response time of a page page load time will drop your drop your revenue. So what we're going to do with New Relic is feed it's performance data back into that the intelligent proxy in front of their application. So now they're going to drop the new version of their intershop application on a Thursday evening, they go to sleep. Friday morning, they wake up and from the three versions, and the best performing website will be up and running. That's the kind of intelligence and that's the kind of feedback we can put into our platform since we started with applications in mind first. It's getting better quality, because you can do better testing. I mean, we all want to test, but we never want to wait for those different kinds of setups, they want to have fast development cycles. That kind of flexibility where you do the functional deployment, the functional release, not the technical stuff. What we now see in the market is that most people, when they go to the cloud, try to solve the technical release problems of getting the application up and running in a technical way into the production time, we try to focus on the functional level. >> So, William, being data driven, a very important piece of what you talked about there. What I want to help our audience understand is concerns about if you talk about abstractions, or if you want to be able to live across different environments, is can you take advantage of the full capabilities of the underlying platform? Because, that is, one of the reasons we go to cloud isn't just because it's got limitless compute Pricing comes down. But there's only new features coming out, or I want to be able to go to, a cloud provider and take advantage of some specific feature. So help us understand how I can live across these environments, but still take advantage of those cloud native features and innovations as they come out. >> Great. There are actually two ways. For most alternatives, we also have an alternative component in our platform as well. We have complete marketplace with all kinds of functionality like AWS has, but I can imagine that people want to develop an AWS and get our AWS lambda functions or s3 buckets or that that kind of specific functionality. And going back to the Intershop example, they run their application as a CaaS solution on Azure. So when you went to Azure DevOps, or that kind of specific functionality included, our platform connects over 130 different data centers across the globe and Azure and AWS, and Oviedo Digital Ocean are all part of the huge mix of different cloud providers. For every provider, we have what we call gateway components. We deploy natively, mostly bare metal or equivalents of bare metal within those cloud providers. And we made an abstraction layer on the network layer. So now we can include those kind of specific services like they were part of our platform natively. Because if we would have just build a layer and couldn't use the specific components of an AWS or an Azure or that kind of stuff, we would just be another hosting provider. I haven't liked VMware. So that kind of stuff. We want to and we are aware that we need to include a specific stuff, functionality. And what we do with this with what we call gateway components. So we have AWS, gay components, educators, but also for IBM, or Google specific environment. So we can combine the network of AWS, with our specific network. And that's possible, because we made a complete abstraction layer between the network of the infrastructure provider and our network. So we can complete IP subnets DNS resolver as if it was running on their local environment. And thereby, since we have that abstraction layer, we can even move the workloads on AWS to Azure. And since we have the abstraction layer network, we can even make sure that you don't need to reconfigure your application. I think that's the flexibility that people are looking for. And if they have a specific workload and Azure and it's getting too expensive, for the ones that includes AWS stuff, they want to shift the workload to different kind of cloud providers based on the characteristics of a specific worker, or even if you want to have the cheapest option, you can even use your on premise data center. >> William, do that there absolutely is interest in doing that. One of the barriers to being able to just go between environments is of course that the skills required to do this. So, there's something to be said about, if I use a single provider, I understand how to do it, I understand how to optimize it, I understand the finances of it. And while there may be very similar things in another cloud, or in my own data center, the management tools are different and everything. So how do we overcome, that skill set challenge, between different environments. >> We had a different approach the same as we do it on application level, we took it also in data center level, so we're going to handle most cannot say all because there's always specific components. But from our interface, you can simply go to a specific application and select the type of data center you want to run on your application. And if your application is running on an AWS, you get the gateway components with the components, like an s3 bucket or a lambda or an RDS, based on the data center you're running in. So we took that abstraction layer even on that level. But I got to be honest, I think 80% of our customers is not interested in the data center, they run their application in unless they have specific functionality, and which is not available on our platform, or they have a long running application, or use a specific or they bought a specific application. Otherwise, they don't care. Because from a traditional application, there is no difference between running on Azure or Google Cloud or an IBM cloud or whatever. The main difference is that we can make a guarantee about the SLA. I mean, IBM has a better uptime guarantee. A better performance and a better network compared to let's say, digitalocean. Kind of set this up. But there is a huge difference. But it's more like the guarantee that we can give them. So we have this abstraction layers, and we try to put as many as possible as much as possible into our portal interface. There will no way that we're going to redesign and we work about the complete AWS interface, or we're not going to include 100% of their functionality. That's not possible. We're, small company. AWS is somewhat more developers in place. But the main components and people are asking for like RDS or these kind of specific setups, that's where we have the gateway components for available and they can include them into their own application. But we also going to advise them why they were looking for those specific AWS components. Is it within the application architecture or is it something gauges right? Isn't there a better solution or an other solution? And I think, since we have that objection that one of the biggest benefits is, and what we see our customers also do is we incorporate that data center into our platform. And we have one huge network across all the cloud providers and including their own data center. So in the past, they had to have two different development teams, one specialized in AWS development, with all that kind of specific stuff. And all one development team which had more like a traditional point of view, because their internal system and data which was not allowed to go outside the company or had to stay within the firewall. And since we have now one big network, which is transparent to them, we can make sure that their code for their internal systems stays internal and is running on internal systems. But we could still use some kind of functionality from the outside. We do it all unencrypted today, and we have one big platform available. So with our gateway components, we can make sure that that data and application data is really staying internally. And only is allowed to grow internal data access and that kind of stuff, but still use external functionality or price. But again, I would say 80% of our customers, they don't care because they just want to get rid of the burden. I think going back to what we think cloud native means is just getting rid of the burden. And you shouldn't be concerned about what type of cloud we're actually using. >> Absolutely, William, the goal of infrastructure support, my applications and my data and we want companies to be able to focus on what is important for the business and not get bogged down and certain technical arguments introduction. So William, thank you so much for joining us. Really great to hear about Delta blue. Looking forward to hearing more in the future. >> Thank you. >> I'm Stu Miniman. And look forward to hearing more of your cloud native insights.

>> Narrator: Live from Austin, Texas. It's theCUBE, covering KubeCon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Hey, welcome back everyone, we're here live at theCUBE in Austin, Texas for KubeCon 2017, 2nd annual conference of the Kubernetes Conference, I'm John Furrier, here with my co-host, Stu Miniman, Ben Sigelman, who's the CEO of LightStep, welcome to theCUBE. >> Thank you so much. >> So you're also involved in open tracer, all this stuff with service mesh, really instrumental tech work going on right now. >> Mmhmm, yep. >> With this KubernetesCon, I mean Kubernetes has been successful. People are now learning for, the first time in mainstream, but it's really galvanized the community. At many levels, and I haven't seen this much action and so fast, up and down the stack. You know, you got the infrastructure plumbing guys, and you got the app plumbing guys all building really, really fast. What's the state of the union? Give us a peak of what's happening, what's solid, what's foundational? What are the building blocks that are being built on and what's the current task of jobs being worked on projects and what not? >> Yeah, and that's a great question. I was, emerged my hotel room yesterday just to get on the elevator and Kelsey Hightower emerged from his hotel room, turns out two doors down from me, and we're walking to the elevator together, I'm like, "Hey! You know, so, what's your big announcement?" He's so good on stage, he's a brilliant communicator, and he's like, you know, honestly, the big news right now, is that actually there's not that much news from a release standpoint about Kubernetes, which is actually a really big deal. It's gotten to the point where it's feature set is actually appropriate and somewhat stable. And now we finally are at the point where it's, I think, it has a really natural architecture for plugins and extensions and now we can build this entire ecosystem around it, instead of building around something that's a bit of a moving target. I think it's incredible how, it is truly incredible, to see this conference over the last couple of years. >> So Pete's foundational elements are in place. >> Yeah. >> That's his, kind of his... >> Yeah, exactly. And it's incredible to see how much of, not just a commercial ecosystem, but a technology ecosystem, that's built around those primitives, and so I think those really are the right primitives, to democratize the pieces that should be democratized, and to centralize the pieces that should be centralized. So to me, this year is really about going a level up in the stack, and delivering value that's beyond, you know, the container, Kubernetes level, and that's what a lot of the projects that I'm excited about are doing. >> Yeah, so Ben, and that leads right into one of the things that we've been talking about all week here, service meshes. >> Ben: Yeah. >> So, you gave a keynote yesterday, maybe give our audience a little bit about service meshes, servibility, and there's something about a pigeon? >> (laughs) Yeah that was very funny. Just the reference about the pigeon, the first slide in my talk was a picture of a murmuration of starlings, this beautiful cloud of birds moving in harmony, and while I was waxing on about how this represented microservices, an actual bird flew above me on stage. There was a pigeon trapped in this room `(laughter) and so everyone started laughing, I didn't know what was so funny, I'm like... >> Jeez. What a great demo. >> ...like what did I do wrong? Do I have a note on my back or something? And then the hilarious thing is the second slide was actually the operational experience of deploying this sort of microservice technology is actually very difficult, and so it was this slide from Alfred Hitchcock's "The Birds," with these birds attacking this poor child. And so, and the bird is still circling around above me. It was perfect stagecraft, I wish I had tried to do it, it would have been amazing to take credit for arranging an actual live animal as part of my presentation. But in terms of the actual material in the presentation, which may be less entertaining than the bird flying around my head, but the material of the presentation is something I feel very strongly about, and I alluded to this a moment ago, I think that containers are incredibly important, I think Kubernetes is incredibly important, and I am extraordinarily confident that in ten years, they're going to be everywhere. That said, they're not something an application developer really should care that deeply about as part of their job of writing business logic for the service that they are maintaining and developing. That shouldn't be a layer that they care about. And there are a lot of really, really important problems that crop up at the application layer. At Google, the way we addressed this, was by having not a monolithic architecture, but a monolithic software repository where everyone developed the same code base, but one of the things that I thought was interesting was being at Google, if you wanted to deploy an application, even something that just printed out 'Hello, world' or something, it was like a 150 megabyte binary, because there's so much stuff that was crammed in to level 7, user level stuff, and that was right for Google, it's not really the best architecture for a lot of enterprises out there and I think what's so cool about service mesh, is that it's taken a bunch of really, genuinely hard computer science problems, like service discovery, connection, and load balancing, and reconnection, health checks, security and authentication, observability and tracing, these are really hard things to do well, and it's factored them off into a side car that you can run alongside ordinary applications that were not even developed with that in mind and take advantage of these application level, level 7 primitives. We've had people who are trying to build solutions for any number of managerial and monitoring tasks at the container level, where often that stuff is completely obscured. Like by the time you're at the kernel that you can't see any of this stuff. If you're up at level 7 in the service mesh, you have easy access to application level data, which makes everything a lot more elegant and straightforward for developers, so it's like, to me, it's this single point of integration that removes a bunch of hard computer science problems from ordinary application development. >> And so people were stuffing containers basically and trying to overdrive that. Makes total sense architecturally and I want you to take a step back and kind of unpack that a little bit. We didn't get here by accident. We got here through real hard work, I mean people were out there building from open-source large-scale systems. >> Yeah. >> Uber, Lyft, there's a handful of other examples. What was the driver around this, because you're talking about a really elegant architecture that allows for solving a problem for the guys that solve their own problems. Thousands, hundreds of thousands of transactions, services, millions of transactions per second. >> Yup. >> So this was not like "Hey, let's just design a new system!" It was some scar tissue. >> Yeah. >> How does that connect to like, reality now for, whether it's a start-up saying "Hey, you know, we're a couple of years old, we're on AWS, and we're growing, and I want to add more value, but I don't want to relearn machine learning, I want to build on all this stuff and create business value from my enterprise, growing an enterprise. Or, big enterprises, trying to be cloud enabled. So that's, how should someone think about that? And what specifically was the problem that was solved? >> Yes. Well, I'm an obsessive person, I'll admit that. And I'm personally obsessed with performance, and so when I think about this, I actually think about profiling the engineers who are building this stuff. You have developers, let's profile them, like what are they spending their time on? 'Cause that's really a precious resource right now, right? It's like, it's hard to even hire people fast enough, right? So if you think about profiling people, you have folks that are spending a lot of time trying to get their services communicated properly, to authenticate, to observe these systems, in a way that's sane. And so it's only natural you try to factor that out and make that factored out. You try to amortize the cost of solving that problem across your entire organization. And I think that you've seen people who've been at other companies, and want to recreate something like what they had at Google or Facebook or Twitter or what have you, but they want to do it in a way that meshes with their existing systems. I'm actually not surprised that super, super young companies that are starting with the true green field code base, move in this direction. What has been interesting to me, and although I shouldn't say surprising, this is actually very rational, but you also have companies that are much larger, and we, LightStep has, we have customers that are running a mainframe, alongside legacy Java VMs, alongside microservices, and they're all working in concert to the service application requests from end users. And these things need to talk to each other, and I think what's actually really fun for me, Google gets a lot of credit for building things the right way, I don't know if that's accurate for not, but it's really funny 'cause the problem is actually a lot more interesting outside of Google, because you have to integrate with a much larger surface area and the thing that's so exciting to me about a lot of the technologies that are really taking off here, is that they're designed for that kind of heterogeneity, certainly I've talked about service mesh a million times already here, open tracing also exists specifically because of heterogeneity, we didn't need open tracing at Google because everything was perfectly factored, so it was unnecessary. Outside of Google, it's necessary to have a common API to describe transactions as they propagate, because otherwise, you can't make sense of anything that's happening in your application. This sort of heterogeneity has encouraged projects that standardize at the right layer, and I think those are the ones that are proliferating. >> What is service mesh about now? I mean, how would you describe it, I mean, how would you define, in the world of Kubernetes, in the world we're talking about, for someone just getting, tech person, just getting started. What's the hubbub about with service mesh? What is it? >> Well, I mean, I think at the most basic level, it's something that sits in between any two processes that are communicating in your system, and it sits in between them at a layer where you can observe the application itself. Like, you're able to access application levels, security information application level, primitives like, you know, the particular path you're hitting for any HTP requests, something like that. It's something that sits in between at that layer. Because microservices, you know, I've seen Lyft up close 'cause they're also a customer for LightStep, and to see Envoy deployed at their company is really instructive. It's amazing, I mean it's really amazing. They went from having no integration with our product to having 100% integration with our product by flipping a configuration bit to on, you know. Actually it wasn't even on, they could do it by percentage, I mean, they can roll these things out with perfect, perfect precision. And, I mean, it's an incredibly powerful thing to be able to have that kind of leverage over an entire architecture and that didn't require all their developers to redeploy. This system required the service mesh to redeploy, so you make these sorts of changes without touching application CSCD stuff, you can do all these infrastructural level changes independently from application pushes-- >> All right, >> And that's very powerful. >> So, so hold on, I know Stu wants to get a question in, but let's stop there for a second. Compare and contrast what the old way would have been. >> Stu: Yeah. What would it have taken to do this similar concept that full team had met, assuming they had another architecture. >> I've seen, I mean, you know- >> John: Months, weeks, redeploys... >> So, you know, the model that I've seen at Google where would we make changes to software that was linked into every application would go out with the next release, we would make that change in some central place, I'd say 50% of the services would be deployed within a week, 90% within two weeks, but to get to 99% would take over a year, and so the issue is if you need a change that's going to cut across your entire system, it is not feasible to wait for people to redeploy because there are going to be services that are not being maintained by human beings anymore, and no one's about to volunteer for that chore- >> John: It's a nightmare basically. >> Of reintegrating, taking in months of code changes, making sure it still works and deploys. >> Yeah, they're going to quit right there. I mean, no one wants that. >> It's infeasible. >> Yeah, it's not feasible. >> Ben, I wanted you to be able to share a little bit about founding LightStep, you know what's kind of the need in the market, and what you're seeing from your early customers. >> Sure, LightStep is, it has a pretty simple mission. We aim to deliver insights about very complex production software, which is commonplace at this point. Anyone who's building a meaningful business is building meaningful production software, and that means it's complicated. So that's what we want to do. The way that we're doing that with our first product, LightStep XPM, is by delivering root cause analysis for the symptoms that are of most interest to these businesses, regardless of their application or architecture, as I said earlier, we have customers that run mainframes as well as microservices at the same time, multi-cloud, it doesn't matter. We follow transactions across these distributed services and use those to explain behaviors that they're puzzling over and help them with performance analysis and root cause analysis. >> And what's the relationship between the open source projects and... >> That's a great question. It's not a normal open core model. Open tracing is really an API project that's designed to ease integration with any number of vendors, and open tracing is supported by LightStep of course, but also by Jaeger, and CNCF, it's compatible with Zipkin, it's supported by New Relic and Datadog, I'll give a shoutout to some competitors. We're all in this together in the sense that I think we see that we all have a much bigger market as things like open tracing proliferate, and make it easier to actually observe your own system. I would love to compete in the playing field of solutions and not worry so much about integration, so open tracing is an integration project, it's not our core technology. Our core IP is something that's very powerful, that's designed to absorb a lot of information about these distributed systems and deliver value about that. >> And when I look at your website, and see kind of some of your early customers, I mean, jump out, you know, Lyft, Twilio, Digital Ocean, I mean, these are not kind of your typical companies, is it, you know, fully kind of cloud-native, you know, horn of the web, type companies? >> I'm really glad you asked that. No. >> Stu: Yeah. >> I mean, most of our customers at this point are, have actually never seen a full microservice deployment, certainly not at one of customers. It's always a combination of a monolith in the middle and microservices on the outside, but a lot of our customers are more traditional enterprises that we haven't put on our website for logo rights reasons, but they get a lot value out of the solution, I would say even more value in some cases because they're dealing with a greater diversity of technology generations they need to cut across. >> Yeah, I want to go back. You mentioned the time for people these days and you talk about developers and people building, the fight for talent is huge out there. What are you seeing in your customers? Is that something that you help? How's kind of that interaction? >> Yeah absolutely, I mean, I think, Digital Ocean says they're saving, I think 1000 engineer hours a month or something like that on LightStep. It's a huge timesaver for people who are trying to get to the bottom of issues. So it's a labor issue, but also root cause analysis, I mean, every second counts. Seconds cost hundreds of thousands of dollars for some of our customers for any big outage, and so we help people get those, Twilio's addressing the instance 92% faster after using LightStep, so it's a big change to their root cause analysis. >> Yeah, there was a great quote I saw that said, "When something goes wrong, it used to be you knew, now it turned into a murder mystery." >> Yeah. (laughter) >> Tell the story of why did you start the company. Was there an itch you were scratching? You saying, "Hey, you know, I've seen this movie before, I want to get out there, help customers, I mean, I heard, your mission is really straightforward, clean, good positioning. Why start the company? What was the rationale? What was the motivation? >> That's a very easy one for me. I mean, the reason I left Google was not necessarily to start a company per se, it was that I wanted to have as much of an impact on the industry as I could, I wanted to see things, not just make money and siphon cash away from companies, but actually to change the way that software is built. And the first act for us, this product, is a way for us to kind of get into the tendril, get our system deep into the fabric of an application, and from that point, I'd like to see LightStep really change the way people build software. I think people right now, it's almost like everyone's programming an assembly. Like we're all trying to operate this level that's totally inappropriate, and I'd love to see LightStep be a part of this story for making the industry move up the value chain and really focus on building applications, and that's what I want to see us do. >> You know, we've been saying, first, we have a similar mission along our media business, but one of the things we're seeing, we go to all the shows, sometimes it's like, why is theCUBE covering, you know, Node.js, or why are you covering Hadoop in 2010, why are you, because we see it early, we get in early, as I said, we can see the innovation, we like it, but I got to tell you, we've been seeing recently, I've been seeing it specifically, we see a huge renaissance in software development companies. >> Yeah, for sure. >> And my piece is, I want to test this with you because I think this is going to change the culture, certainly in Silicon Valley and around the world. Certainly with open source is exponentially growing, you know, Zemlin puts that stat up pretty clear. All software development models was crafty and built a product you QA and you'd ship it, it either worked or it didn't work, put some art to it, around ownership, and then AdJail derisked that risk, but you can get it to the market quicker, and you listen to the data, you learn from the data, but it kind of took the craft out of it. You know what I'm saying, almost we're coding and we're iterating, we're on a treadmill, which is good. But now, with what we're seeing here, is that you're getting back to extracting away, to your point, all these services you don't need to worry about anymore. I could actually focus all of my attention on the artisan aspect of the solution. Not UX, love UX design, not that kind of art, but something about software art. What's your reaction to that? Do you see that coming? Because if this continues, we're going to have a whole class of software developers just essentially painting software art, if you will. >> Yeah. >> I mean, that potentially is a scenario. Your thoughts. >> Yes, I agree with that scenario being feasible. I think it's probably more than a couple of weeks away, but I'm really excited about it. I think you're right on the money, I think a lot of the changes that we're seeing allow people to operate more independently and that's what motivates the transitions to microservice in the first place, it wasn't just to rewrite everyone's software for fun, it was because we want everyone to be able to be independent of each other and operate in that mode. The thing that I think is exciting about that vision which I would echo is a lot of the primitives that we see in the marketplace right now allow developers to focus on the semantics of application and the requirements of application which is where all of the interesting stuff is, and what we all get excited about. And I think we do see a lot of the, this number of people here right now, that investment as a community in allowing developers to focus on the logic and nothing more is really tremendous and exciting to me. >> How has community changed? I know you believe in community. Community's more important than ever now, in this new model, 'cause there's so much leverage going on with the software. How important is community and how is it changing and how should it evolve to handle all this awesome growth? >> Yeah I do have some thoughts about that. It's definitely important, I mean no one's going to deny that. I think one of the biggest challenges that I think about anyway in this sphere, has to do with, I referred to this earlier, it's important to figure out what problem you're solving with the community aspect of things, like with open tracing we thought really hard about this, like are we going to focus on, like, the bits and bytes and the wire protocols, or on the part that really needs to be standardized. I think community makes sense when standards are appropriate and standard interfaces are appropriate. I'm actually a little bit skeptical of community driven solutions where it's, you're delivering the entire package as a community because it ends up intersecting in ways that are complex I think with business motivations. I think the most successful projects are areas where the community really must collaborate, which usually has something to do with standardization. Those are the areas where I'm most excited. And then you actually literally, I was talking with Ken Goldberg yesterday, and they intentionally carved out areas for vendors to play, because they don't want to kind of meddle in that are. It's actually better not to meddle in that area. It's actually better- >> It's like microservices, you put the vendors over there and you put core commuters over there. Ben Sigelman, thanks for coming on theCUBE, I appreciate it. Congratulations on LightStep and the success and your talks here. Early community exploding, cloud native is not only a movement, it's clear to everyone, cloud and data and software and open source is making it happen, easier, accelerating velocity. It's theCUBE, doing our part, bringing you the data, here in Texas, I'm John Furrier, with Stu Miniman. We're back with more live coverage after this short break. >> Thank you. (techno music)