 Live from Santa Clara in the heart of Silicon Valley, it's theCUBE, covering Cloud Foundry Summit 2017, brought to you by the Cloud Foundry Foundation and Pivotal. Welcome back, I'm Stu Miniman with my co-host, John Troyer. Happy to welcome back to the program actually a former colleague of mine, Cornelia Davis, Senior Director of Technology at Pivotal. Cornelia, it's great to see you. Thank you, thank you for having me. All right, so why don't you fill in our audience a little bit about your role at Pivotal, you've been involved since before the foundation and early days of everything happening. Yeah, yeah, and in fact, I have been working with Cloud Foundry for longer than Pivotal, than the Pivotal companies existed. As you know, Stu, you and I used to work together at EMC in the corporate CTO office. Yeah, I remember a company named EMC. Yep, and I worked in the architecture group and we did architecture and emerging tech. And about five years ago, my boss, who you know, Tom McGuire, said, you know, this platform is a service thing. I think it's going to be pretty disruptive and I want you to start looking at it. And so naturally we were EMC, VMware was incubating Cloud Foundry already, so I started playing with Cloud Foundry. And so that was back way back in the days of Cloud Foundry version 1.0. I'm one of those people who got to raise my hand and say, yes, I've been to every single Cloud Foundry summit. But fast forward, then we had the Pivotal spin-off and since the Pivotal spin-off, I joined the Cloud Foundry team proper. And I've been in a role working in the product organization, working with James Waters, who I know you spoke to earlier today. And helping our customers kind of get their arms wrapped around what this, this isn't just the next application platform, how really it's radically different and how the applications, it enables a completely different style of application. And so really helping customers kind of grok the differences about that. Cornelia, I want you to help us dig into this a little bit because when we look at any of these massive changes, a lot of times we say, you know, the technology is the easy part. It's really the change in mindset, the change in the structure, new skill sets. What are you seeing, what's different now than it was, you know, say three or five years ago? And, you know, what are those customer discussions that you're having? Yeah, and that's a great question and I will say, and thanks for the opportunity to say this, is that the technology isn't always the easy part. So let me give you an example. So just earlier today I was on a call where somebody was talking about some user interviews that they had done with some programmers and what they concluded at the end of that was that programmers really didn't, they weren't comfortable with the async model for this particular API and that they really wanted to just deal with the synchronous stuff. And the answer there is not that we say, oh, okay, we'll let you keep doing synchronous. The answer is that, yes, there's a technology thing here that's hard which is starting to think asynchronously and changing the way that we design our applications. So the technology's not always easy, but we have to go there. Because in the cloud where things are so extraordinarily distributed in a way and the cloud is constantly changing in ways that it never did before, we have to adopt new technology models. So that's the first thing I'll say is that we definitely, the technology parts are sometimes hard. That said, certainly over the course of the last four years as I've worked with those customers in the beginning I spent a lot of time, as you know I'm a technologist. So I spent a lot of time at the whiteboard and sketching out architectures and talking about changes in the architecture, the platformer changes in the architecture, the application. But then I very quickly found myself talking to customers about the other things that are going to need to change around the edges. So if for example you want to start deploying software multiple times a day, you're going to have to change your processes because you can't have the security office have to do a full audit of every change before it goes into production if it's going to happen three or four times a day. And if you do that, then does that imply organizational changes? So I spend a great deal of my time really talking about the whole DevOps and that the people in process side of the equation as well. So last week I was just, I'm part of the programming committee of the DevOps Enterprise Summit and we just held that last week in London. And there we spend a lot of time talking about those elements as well. I spoke with somebody who was at that conference and they said it was a little bit sobering because there are people who have adopted a lot of these practices and then the people who are trying and then they're probably people who have not started yet. As Kote calls them, the donkeys without the unicorn horns yet. But as you go out to the customer base, obviously part of what is Pivotal is doing is really this huge Pivotal Labs push about showing people the culture. I mean, do you feel like it's a push or a pull? Does the technology come first and then the culture, does the CIO yell or do the developers say we want this? So we definitely get a little bit of both. I would say that I have had the great opportunity to work with a great number of these customers. So Allstate, for example, we've seen Allstate here at CF Summit year after year and Opal spoke about Andy Zittney talking about this three or four years ago. Well, that was IT saying, hey, and that was kind of more from the operation side saying, hey, we're going to build you a new platform and then will they come? Now they of course had to couple that together with, okay, we're not just going to build the platform, we have to put things in place to enable people to use it properly. So there's certainly, and that came a little bit more from Andy Zittney's vision. So it was a little bit more from the top, hey, we understand there's a better way, we're going to start making this available to you and we'll teach you along the way. We absolutely see the opposite as well though, where we see the grounds swell which sometimes comes from a bunch of really smart people starting to play with the open source things and saying, hey, there's got to be a better way or the shadow IT. They're frustrated with the three month cycles and those things. So it isn't one answer, it's really both. It comes from both sides. All right, so Cornelia, you're good at understanding some of those next generation things. One of the terms that we've been talking about for the last couple of years is cloud native. Could you help us really kind of tease apart what that means in your customer base and the way you approach and explain that? So the term cloud native is brilliant from the perspective of just having a term for it that has really taken a hold because I would say that three years ago I used to say to people, hey, cloud is not about where you're computing, it's about how you're computing. But in fact, that's not exactly accurate. And so now that cloud native is a term that's taken hold, I have modified my statement and the statement that I like to make now is that cloud in fact is where you compute. It could be a public cloud, it could be a private cloud, but it is more of a location. Cloud native is the hell. So I like to also characterize the cloud and cloud native, really cloud native applications as two fundamental things. One is that cloud native has reached levels of distribution that we have not seen before. We've been dealing with distributed systems and heck, in universities, there have been courses on distributed systems for 40 years. But even when I started my career 30 years ago, I started my career in aerospace doing embedded systems. And I remember working on a system where we had three processors. That was as distributed as we got and we actually mapped out on a whiteboard, okay, we're going to run this on this process in parallel with this on this process. And the point there is we knew exactly, it was distributed, but we knew exactly what we had and we could count on that being there. Now it's reached a completely different, many, many orders of magnitude more in terms of the number of distributed components as we go to microservices and those types of things. So that's one of the things that I characterize cloud and cloud native is highly distributed like we've never seen before. Couple that together with the other thing that I just talked about with the embedded systems that's very different from that is constantly changing, always changing. And whether that change is happening because of some catastrophe or that change is happening because we are doing an upgrade, a planned upgrade, it's constantly in flux. And so we have to do things differently for that. And so that I think really is what cloud native is about is the how and like I said, highly distributed, constantly changing. And what about the role of data when we talk about that? Distributed architectures, storage is really tough in that kind of environment and therefore how does data play into it? Yeah, so cloud native apps were really as an industry starting in here at CF Summit, people are really kind of grocking what that means. Highly distributed, small, loosely coupled components that we've put together. We'll talk about that collective in just a moment. But they're generally stateless and so on. So we understand cloud native apps, but cloud native involves data as well, as you said. Now, most of our customers that have, as you said, some of them are a little bit further along, whether it's DevOps or it's cloud native app architectures, they're a little further along. And those that are quite far along have a lot of microservices. And so you look at them, if you look just at the microservices, you think, ah, beautiful, loosely coupled, independent teams and so on. And then you pull back the curtain and you realize that those microservices are all tied to as shared database. There's this monolithic Oracle database or SQL server or something at the back end that they're all tied to. And so in fact, when a team wants to make a rev on a microservice, they might still have to go through some of that planning and lockstep with lots of other teams because, hey, I want to change something in the data. So the data, remember we just talked about highly distributed? Well, on the data side, it's not so highly distributed. Yes, we've got multi data centers, but we have, again, a predictable number of nodes. We know what we've got deployed. We have very kind of rigid architectures and configurations and so on. So when we start to apply cloud native to data, we look at the same goals that we had with cloud native applications, which is autonomy. So being able to have the different cloud native components evolve independently. Resilience, so that we have bulkheads and air gaps between them, all of those same goals, let's start to apply those to data. And you feel that that's not happening to data yet? It hasn't been happening. That's right, we're far, far, far earlier in the process. And so what we want to start to do is we want to take that monolith that's sitting behind the curtain and we want to start breaking it apart. Now the industry has definitely gotten to the point where they're starting to tackle this. And that was, I kind of had an epiphany about a year ago. I was working with a customer, talking to them about DevOps, talking about all these cloud native patterns and practices, and the punchline was it was the data team of this organization. And so they didn't understand the solutions, but they were understanding that they had pain points that were very reminiscent of the pain points that their colleagues in the application server teams had been tackling for three or four years. So the types of technologies that we're starting to see emerge and the start, types of patterns we're starting to see emerge are things like unified logs, like applying Kafka to that problem of having a unified log and that be the source of record and event-driven systems and those types of things. Every microservice gets its own database, which, yeah, we'll get some of that, but that's a kind of purist not pragmatic way of looking at things. Caching plays a pretty big role in that, so caching in the past has been all about performance, but now when we start to look at patterns, how can we use caches to help us create those bulkheads and those air gaps so that we get additional resilience in our microservices architecture if we can put caches and there are companies like Netflix, like Twitter, who have done that, who have embedded caching deeply through their entire architecture. Well, you think these technologies will come from the database or, well, let's call them the database projects and vendors themselves or is that something those patterns can get built into a platform, say, like Cloud Foundry? I think it's going to probably come more from the platform community, which is not to say that the database vendors aren't thinking about that, but again, they are keeping the lights on with their existing products, so they have those quintessential business school constraints that are holding them back. A quick question on nomenclature. So back in the few years back, as Cloud Now, Cloud Native was being coined, you also heard about 12-factor apps and that was one particular manifesto and certainly the ops folks, I recall at the time, said, well, wait a minute, that's great for your front and before you store in your state. Exactly. And so that I love this conversation about Cloud Native data, but is that, so that is what we're talking about here. That's exactly what we're talking about, is doing that. And so it allows us, it's interesting because as soon as we take a model where we say, okay, every microservice gets its own micro database, then of course, everybody in any large enterprises will wait a minute, what about my data compliance, my data governance, how do I keep a customer that's stored in this database over here from diverging from the customer record that's stored in this other database. I mean, we've spent decades talking about the 360 view of customers because we've already been somewhat more fragmented than we wanted and our knee-jerk reaction over the last several decades was, let's consolidate everything into one database, but with that comes slowness. It's the proverbial, you know, large, large ship that's hard to turn and hard to move. And so, but what's different now is that we're starting to come up with some different patterns of doing that, what we call master data management in the past, we're applying completely different patterns now where those individual microservice databases are really just seen as a materialized view of some source of record and that source of record is just a time series of events and you can always rebuild, you know, it's very interesting because databases have had a log as a part of their architecture for ever, for a very, very long time and in fact, the log arguably is more important than any of the database tables that are stored on disk because you can always recreate the database tables from the log. Now take that concept and distribute it. That's what CloudNative data is all about, is to take what has been a single fabric and now create a highly distributed, constantly changing fabric for data and figuring out what those patterns are. You want to give you the final word, you've been to all the Cloud Foundry summits, either the customers or the event itself, what are some of the things that are kind of new and changing that people that are and that the show should know about? You know, I was walking down the hallway this afternoon, one thing that I'll note that has changed is that, like I said, I was walking down the hallway with a colleague of mine and he said, I have 12 people from one of, a single one of my customers here, 12 people. I spoke with somebody else who said, yep, another customer, not a vendor, but a customer sent 30 people here. So we have Cloud Foundry Summit in the beginning was a whole bunch of people who were the hobbyists, if you will. So I think we've reached that inflection point where we have the users, not just the hobbyists, but the true users that are going to leverage the platform. That's one thing that's changed. Some of the things, the other interesting thing I think that is really brilliant is the touch that the Cloud Foundry Foundation has. So I'll tell you, I submitted several papers here three years ago when it was still the pivotal show, I could talk about whatever I wanted. I don't always get my papers accepted here now. And that is a good thing. That's a really good thing. So we have really democratized the community. So it truly is a community event. I think that's another thing that's happened is kind of the democratization of Cloud Foundry. And I love that. Cornelia Davis, it's a pleasure to catch up with you. Thank you so much for joining us. And John and I will be back with a couple of customers actually here at the Cloud Foundry Summit. So stay tuned and thanks for watching theCUBE.