 How have you seen the role of data in the modern economy and how you've seen the evolution of data from the old days of data center to the new era of cloud-centric, Kubernetes-centric world? If we go back into the year 2013, when Cloud Foundry has been in everybody's mind, it was obvious to me, when we started a Cloud Foundry platform as a service offering in Europe, that whatever Cloud Foundry does to applications, which is basically meaning taking source code and turning it into containers, that having that to affect a manifest, that ask application developers to store state in backing services, in data services, that whatever you do in terms of providing automation comfort for application hosting, you also need to do for database hosting. I mean, I've been developing web apps and hosting and running hosting systems my entire professional career, starting at 19 with Pearl and shared hosting. And if you think about shared hosting of the days, you'd have an FTP account to upload your app and you'd have a pre-configured database user and some database server so that you don't have to take care about all of this. You just had to upload your app and connect it to that pre-configured database server. So if you make Cloud Foundry, take that idea of shared hosting, make it into a single command deployment with the ability to scale horizontally, just like that. You also need to find something to address the problem of operating databases in a different operational model. And the idea with Cloud Foundry was that you take applications and you have a tenant concept in the platform so that a large organization can use those tenants to basically say, well, this is a business unit, this is a business unit or this is an application development team and they can run their own apps. So there are thousands of apps, different apps running in a Cloud Foundry. So where do the databases come from? It's the obvious next question and this question has been ignored for years. We've been talking to clients running Cloud Foundry and I said, look, your existing database strategy is going to fail because look what Cloud Foundry did to your apps, something needs to do that for your databases as well. And they were like, really, you could tell it to people and they would still ignore it. So a lot of adoption at the early Cloud Foundry days was, and even we're talking about to 15, 16, 17 and 18 where people introduced DevOps technologies such as Chef to run their databases. Although, at least from our experience we've been running Chef since the very first versions and looked into Puppet as well. And we've learned how many databases you can run given a certain number of operators and DevOps. And we found, based on our own experience that the operational efficiency of Cloud Foundry is magnitudes higher than that of Chef. So even for applications. So if you translate that to databases, it was very clear that the way cookbooks in Chef work, the imperative style of telling a server what to do based on a pre-defined set of instructions cannot be a solution. So we basically took the next logical step which is to be aware that Cloud Foundry's operational efficiency comes from Bosch. And Bosch's operational efficiency comes from being declarative by nature. And the idea was if you make applications containerized, basically making the application server uniform by using build packs, well, you can't do that the same way with stateful apps because you need to deal with state much more intensively but you can use Bosch. So that was the idea of on-demand provisioning any nine status services where this pattern was not obvious at the time that you do not want to have that single oracle database in the heart of the company, but you split it down into smaller databases and you make the databases less important and you take the 80% case where most of the databases will be operated just fine, you automate that and you make this on-demand provisioning based on a declarative automation technology. That was the leap of faith. That was basically the invention of the end of the data services. And we're talking about the year 2014 where we started to do that. Now we are in 2023 and we are now looking at a very young sub-community of the Kubernetes community, the data on Kubernetes community in particular where we are at any lines involved as well where on-demand provisioning of dedicated instances based on pods becomes the standard approach. But that's nine years after we started to do that. And it's nine years of giving talks about why this is a very good solution. And to put it in one phrase is you have one automation code base that will work from small non-production environments to large clustered environments, one automation code base. It's the single most important paradigm in automation since the emergence of ephemeral VM and persistent disk paradigm which is the direct prerequisite for having declarative management in a Bosch or Kubernetes style where you also have persistent volumes and stateful sets. So that's the very foundation of data service or the data management or data management in modern platforms is on-demand provisioning of dedicated service instance. At least when we're talking about software operations at scale, talking about organizations with hundreds or thousands of application developers, there will still be large databases that are nurtured by professional DBAs because they are the centerpiece of a very large service which will just grow inherently to such extents where splitting up is for some reasons not possible or meaningful. But other than that, the 80% case of application developers, that's exactly that pattern we are seeing currently and it's the only thing that's meaningful in my opinion. So I would say Kubernetes didn't change that story at all. Our data service automation story at any nice is intact. We are using more Kubernetes to do the same things or do it to different data services. We're expanding the palette of data services more and more. But it's the same strategy, the same principles apply. So if you're looking into managing data in your platform today, look at the on-demand provisioning of dedicated service instances as dedicated ports of virtual machines that's based on declarative automation. And you'll be on the right path. You will learn how much more work it is than you would ever imagine, but it's the right way to go.