>> 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.