 As we started talking about innovation and the role that plays in the digital transformation effort, I did want to bring up a long time member of the Cloud Foundry community, Julian Fisher, the CEO of NINES to talk about data services. Come on up, Julian. So now you have to deliver, Julian. Yeah, absolutely. Come on, do a song like that. I was joking that I want to have the Rocky theme when I enter the stage, and they really did it, so. That's awesome. I'm happy to work with you. Great. Well, thank you for joining us here at Cloud Foundry Summit. We're excited to have you here. Never missed one. No, you never missed one anywhere, and you've been a long time member of this community. For those of you that are new to NINES, why don't you walk us through a little bit what NINES does and how Cloud Foundry has impacted your company? Well, actually, the company has been running since 2008, and we started as a web development and managed hosting company. But it was 2012, I was in Palo Alto at ChefConf when I was invited by James Waters to come to VMware Headquarter talking about Cloud Foundry, and in 2013, we started a public offering around Cloud Foundry in Europe called passNINES.com. So that was the beginning of our Cloud Foundry journey, and from offering a public platform we actually transformed into a consultancy, finally ending up as experts in Cloud Foundry operations and, most importantly, data service automation. That is an amazing journey that any NINES has been on, and we talked a little bit about this prior to coming up here in the role data service display, and I feel like we talk about the platform and applications a lot, but we don't really spend enough time talking about data, which is obviously immensely important for your applications. Can you talk a little bit about your view on data services and the role that it plays for you and any NINES? Well, obviously, the first time we actually thought about that topic was when we had a Cloud Foundry platform up and running, and there were no data services. And we have had many customers from our managed hosting, so we've been through all the pitfalls you can imagine, such as using shared cluster architectures and things like that. So we had a pretty clear picture on what needs to be done next. So also we had tons of Chef cookbooks, as this was the primary automation technology we've been using for five years, and after operating Cloud Foundry with Bosch, we decided to deprecate all the Chef cookbooks we had. Everyone? Every single one. And it was actually the head of operations who was in charge of the Chef cookbooks who picked me up with that decision. So he was skeptical at first, but after a while, we just found out that this is the right step. And I would say it's an essential part of the success story around our data service automation products that's based on the capabilities of Bosch. So if you look into a platform where Cloud Foundry solves the problem of, you know, running your stateless applications, you still need to run your stateful applications as well, your data services. So you want to have the same experience. You know, it should be on-demand service so that you can create and restore databases at any time. So we're talking about managing the lifecycle of a stateful piece of software. So, and therefore, you're looking for a description language that allows you to describe this lifecycle. So we've heard a lot about containers and virtual machines and how this changes everything. But from the perspective of investing into automating data services, I don't want to care. I don't want to care about whether there's a container on Kubernetes or a virtual machine on a vSphere or AWS. I want to be able to describe once and run it everywhere. So wherever there's a Cloud Foundry application runtime or Cloud Foundry container runtime, I would be able to run my data service solution as well. So I think that is something that needs to be done. And, yeah, we've been on that journey for years now. But it seems like there's a bigger picture to that and the impact that has on really transforming a business. What does that look like from the companies you've worked with and how has that transformed? And to really think about the data structure is something very different. Well, we particularly had one advantage, which was that we came from the Ruby community originally coming up with the idea of platform as a service, where in the Rails part of the Ruby community, there's a lot of conventional over-configuration. So we've been already pretty progressively transforming ourselves, like agile development was already done, Kanban was already done. And with all that experience in automation, it was clear that we are going to strive for the full automation of the entire lifecycle of data services, not only setting up a data service, but going through all the events, like updates, like failures of infrastructure, and still providing a high level of automation. So that mission statement of having this operational model across a wide set of data services was pretty unique. And I think while now people are catching up to this idea, a lot of the larger corporate customers, they are stuck in their digital transformation at some place. So they have to replay the technological and paradigm shifts of the past 10 years within their company. And sometimes this creates friction where new technologies, new ideas meet existing business processes and attitudes. So for example, purchasing a product or adapting a certain product hits, that creates friction with the big security handbooks they got, the procurement process they have, and so on. So I'd say, yeah, it's a challenge. So with this new product category emerging in the market, customers have to learn how to use it, or how to expect it, and how to buy it, or build it if you want to. So we see two extreme positions at the moment. Let us call them right wing and left wing for a moment, just for the sake of having a visual. The connotations these days, that might not be good. So the kind of businesses that are used to look for a very enterprise kind of solution, such as Oracle databases, and the ones who do the exact opposite, who avoid that going for pure open source solutions on the other hand. So I think there's a world in between which is worth looking at, and most of the digital transformation journeys are starting at the enterprise side, walking towards the more open source kind of things. But that's a digital transformation challenge. All the major organizations are facing, especially in changing the attitudes along with the paradigms and technologies. Yeah, absolutely. It's huge. So as we think about where we're going, we've talked a lot this morning about the platform, the enablement, software development, the role innovation plays on it, and now data services, where do you see the future going? Well, obviously, the future involves containers because there's so much attention to that topic at the moment that you can't get around it. So if you look for a technical solution that an architecture to solve data service automation, you won't have a one piece of software, such as a Cloud Foundry runtime. You're ending up having a framework because the diversity of managing state across all those data services is so different. So the question is, how does the perfect framework look like? What's the automation technology to be used? What are the circumstances, the requirements that you actually need to incorporate into that framework? So as I said earlier, our vision is to have a common language where we describe the lifecycle and don't have to worry about the infrastructure we deploy to. But with the container movement, resolving problems that kind of have been solved already but in a different way, we're going back to the decision, well, do we want to automate things again, maybe in a different technology ecosystem, or do we find an abstraction that would give us a description that can do both? Because the value for us, the value is having a database and not re-implementing it over and over again in terms of re-implementing the automation. So the future is. Yeah, I believe the future is finding common way to describe lifecycle of software without having to care about its implementation. Bosch has done a great job about it. Maybe there's going to be a Kubernetes CPI that will give access to the container world, or maybe there's going to be another domain language for that in the future, who knows? Maybe, it's open source, and it's the future, you never know. Right. Well, Julian, thank you so much for coming and joining us here at Cloud Foundry Summit. It's always a pleasure to have you around. Thank you very much. Thank you. Thank you.