 From the CUBE studios in Palo Alto and 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, we'll really help understand where we have gone from cloud, how we're taking advantage of innovation. A real driver for what happens in the space is, 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 in the rest of the organization. So I 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. Have a welcome to the program. First time guest, William Jonsson. He is the CEO of DeltaBlue. Deep in this discussion of Cloud Native, DeltaBlue is a European company helping with continuous deployment across cloud providers in the space. William, thanks so much for joining us. Nice to see you. Glad to go to the show. Thank you, Stu. All right. So one of the reasons I'm glad to have you on is some of the early episodes here. You know, we're discussing, you know, really what Cloud Native is and what it should be. My first interview on the program, Piscar, who you know, had given the analogy and said, you know, 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, you know, lots of companies out there that are like, oh, Cloud Native, well, we support Kubernetes and we have this tool and you should buy our Cloud Native, you know, ABC or D. So, you know, I want to start a little first with, you know, what you see out there and, you know, what you think the ultimate goal and outcome of Cloud Native should be. I think Cloud Native, to start with the 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. The Kubernetes is solving a technical problem and introducing another technical problem. So what I think Cloud Native should do is focus on what you actually do it. So a developer should develop somewhere from the infrastructure and operating should focus on their key points and not try to mix up. So not Kubernetes. Kubernetes is again, sort of 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'd love to do. And not talk to the cross-border, talk to a lot of developer and solve operational kind of things. That's what we try to solve. That's our view on Cloud Native. Yeah, I'll poke that a little bit. Because one thing you say, you know, 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, you know, 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, you know, the drumbeat that I hear is, you know, 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, you know, building this beautiful stack that we could optimize and build these pieces together. Today, the analogy I hear more is, you know, there's layers out there. There's lots of different tooling, especially if you look at the developer world. There is just, you know, there's too many options out there. So, you know, maybe bring us a little bit as to, you know, what Delta Blue does, how you look at, you know, allowing developers to build what they, new things that they need, but not be, I guess the word, you know, 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 going on. And when we started out with Delta Blue, the only thing we had in mind is how could we make the lifecycle of applications and all the things you had to do in the government the right applications way more easy. Back in the days, we already saw that containerization solved some of the issues, whether it solves technical issues. So, like when you start coding, you don't need to code 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 a 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 containerization solution. We take that for granted. There are so many great solutions out there where they try 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 try to solve with our platform is to make that part of your lifecycle. So, let's call it the horizontal version of your application lifecycle, not getting an application built or running off different stuff. We take that for granted. So, we take the horizontal approach, how to get your traditional application from your development environment to your testing acceptance. That's the 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 build one web interface, a logical portal, and you can simply drag and drop any type of application, not just a modern microservice-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 inter-shop environment. And that's going to add to business value. So, going back to your definition of cloud native, getting that kind of abstraction between getting your, and coding your application and getting it somewhere up and running and all the steps that needs to be done from your development environment into the production environment. That's going to add to business value. That's going to feed up your time to market. That's going to make sure that you have a better code 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 Delta Blue, we took the different approach, took the technical stuff for granted and focused 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, would 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 Winnerman Thompson, a big e-commerce 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 for the developers, coded a new big e-commerce application. In the past, everyone had to install their own inter-shop environment on their own laptop, Java, Oracle, that kind of stuff that took them a day and a half. Since we abstracted that into like a simple file, 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 inter-shop 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 there's a security patch. We all know the trouble of getting a patch installed in production, but also then installed 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 one simple click off 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 because 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 their complete development DTAP environment. So, with a single click off the button, they have a complete DTAP environment, known over they need to go to their infrastructure to get the service, to their operating guys, to have them installed inter-shop, Nexus, the report card reports, 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 like spinning up a container or spinning up a VM. Now a complete business case applications of complete environment should be up and running with a single click off 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 off the 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 shop in their production environment. And based on business rules, we can spread the load against the different versions of a business application or e-commerce 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 to meet the New Relic data, I mean, and e-commerce applications about performance. A long response time of a page, page load time will drop your, will drop your funnel, your revenue. So what we're going to do with New Relic is we get performance data into 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 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. So if you're talking about business, 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 kind of setups. We want to have fast development cycles that kind of flexibility when you do the functional deployment, the functional release, not the technical stuff. What we now see in a 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 environment. We try to focus on the functional level. Right, 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 platforms because that is one of the reasons we go to cloud isn't just because it's got limitless compute and pricing comes down but there's all the 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. 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 kind of functionality like AWS has. But I can imagine that people want to develop on AWS and get our AWS Lambda function or S3 buckets or that kind of specific functionality and going back to the inter-shop example they run their application as a CAS solution on Azure. So we want to have 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 OVH, DigitalOcean they're 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 equivalence 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 built 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 to have them like VMware or that kind of stuff. We want to and we are aware that we need to include that specific stuff specific functionality. And what we do with this with what we call gateway components so we have AWS gateway components Azure gateways 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 have complete IPs of nets, DNS results as if it was running on their local and thereby what since we have that abstraction layer we can even move the workload from AWS to Azure and since we have the abstraction layer on network layer we can even make sure that you don't need to reconfigure at your application. I think that's the flexibility that people are looking for if they have a specific workload on Azure and it's getting too expensive or they want to include AWS stuff they want to shift the workload to different kind of cloud profiles based on the characteristics of the specific workload or even if you want to have the cheapest option you can even use your own on-prem data center. So William 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 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 I cannot say all because there's always specific components 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 on and if your application is running on an AWS you get the gateway components with the components like an S3 bucket or a laptop or an RDS based on the data center you're running in so we took that abstraction layer even on that level but I gotta be honest I think 80 percent 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 an Azure or a Google cloud or an IBM cloud or whatever the main difference is that we can make a guarantee about the SLA I mean an IBM has a better uptime guarantee and a better performance and a better network compared to let's say a digital ocean kind of setup is that so 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 it as many as possible as much as possible into our portal interface there will no way that we're gonna redesign and we work about the complete AWS interface so we're not gonna include 100% of their functionality that's not possible we're a small company AWS has somewhat more developers in place but the main components and people are asking for like RDS or those kind of specific setups that's where we have the gateway components for available and they can include them into their old application but we're also going to advise them why then we're looking for those specific AWS components is it within their application architecture or is it something they just heard of isn't there a better solution but another solution I think since we have that abstraction layer one of the biggest benefits is and what we see our customers also do is we incorporate their 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 those kind of specific and stuff and all one development team which had more like a traditional point of view because their internal system had 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 on an encrypted way and we have one big platform available so with our gateway components we can make sure that that data and that application type is really staying internally and only is allowed to grow internal data access and that kind of stuff but still use external functionality or points 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 are actually using No absolutely William you know the the the goal of infrastructure support you know my applications and my data and you know we want companies to be able to focus on what is important for their business not get bogged down in you know certain technical arguments and discussions 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