>> Narrator: Live from Santa Clara in the heart of Silicon Valley. It's the Cube. Covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. >> Welcome back, I'm Stu Miniman joined by my cohost, John Troyer. There's nothing we love more when we're at the User Conference is to actually be able to dig in and talk with the users. I want to welcome to the program Opal Perry who is a divisional CIO at Allstate. Did the keynote this morning. A really good community here. I know they were excited to hear your story and thank you so much for joining us. >> Thanks, it's great to be here with you. >> So Opal, we hear this term the digital transformation. Some people think it's just a buzz word but you talked in your keynote about the transformation that's going on in your world. Why don't you give us a quick overview of your role and what this transformation has been. >> Sure, so I've been with Allstate almost six years and I'm one of the vice presidents on the technology leadership team so we both work together as a whole team on initiatives that affect the entire enterprise. And then my particular day-to-day focus is Divisional CIO of Claims. We're a large insurer. The number publicly held insurer in the U.S. We support claims for auto, property, Allstate business insurance. It's a outstanding time to be in the business because there's just so much going on in technology. There's so many immersion areas and particularly when we are able to knit them together to serve our customers from insurance protection, restoration standpoint. It's really powerful. We do say and hear transformation so much that it feels sometimes like an overused term but I haven't found a better word for it yet because I think things really are transformative. We've been used to, for many years in the industry, change. Right, continuous improvement. We're always trying to change and get better. But what's happening now with this conversions of forces is truly transformative. We're not just replacing one way of doing things with a slightly improved way. We're changing the way people interact and serve the customer. >> And Opal, what was the driver for the change? Was there a pain point or competitive pressure? What drove this change? >> At Allstate, it's all about the customer opportunity. As I mentioned this morning, we've got 16 million customer households and that's just a tremendous responsibility and also a tremendous opportunity. To us, it was thinking about how do we bring the forces of this great 86-year-old company to bear and use the digital and technology changes emerging and really do that in support of giving our customer a better and better experience. How do we protect them? How do we restore them? >> As you are making this transformation to... We're here at the Cloud Foundry Summit, so interested in the Cloud Foundry story, how some of that decision process, obviously the tech is really cool, A. So was this coming out of the developers first, the technologists first or was it more of a needs analysis from the top-down that like a platform instead of technologies like Cloud Foundry? It could be what we need. >> It really came from a number of quarters but the tipping force was from our infrastructure area. As we looked like a lot of large companies do at what's the future of infrastructure, both in the data center, themes that have been emerging for many years in Cloud. There were a number of us that are leaders at Allstate that came from a banking background so we had seen previous era changes. Prior to Cloud Foundry been instantiated, I'd worked more in home-grown paths and seen that opportunity both from the developer but also from the infrastructure and so when Andy Zitney had joined us, he's with McKesson now, but he had joined and was our CTO for a period of time and had background from Chase and PayPal and various areas. He came in and build our platform team and really looked through their selection process, determined Cloud Foundry was a great option for us and something that we could grow with over time to start meeting the needs. But it was really an interest of saying hey, let's let infrastructure get out of the way, provide the foundation for the developers, and let the developers innovate great software for the business. But let's let the platform take care of things. He brought early awareness to a lot of those factors. >> Yeah, I think the joke is that nobody should be righting their own cryptographic software anymore (Stu chuckles). Nobody should be writing a distributed key-value ParaStore anymore. The Cloud Foundry people will tell you nobody should be writing their own platform anymore. That's hard enough, let somebody else take care of it. >> Yeah, maybe if you're a PhD student (interviewers chuckling) or researching the next great idea but in terms of being within an enterprise, whose primary role is to serve customers in a different way. Again, it just takes care of a lot of the lifting. That took a while when we introduced it for some people to understand. People would say to me why are you adding another layer? Getting them to understand the power of the abstraction and that's what we're really doing. We're lifting up above so we don't have to be worried so much about the exact infrastructure we're sitting on. >> That upscaling process that you're talking about, that training process. Both from the developer side and the operational side, there's a learning curve. Some people embrace it and some maybe not so much. Can you talk a little about how people have gotten trained up on the new skills, how you're helping people do that? >> Yes, in our platform team, it really started with Matt Curry who joined us a few years ago. He's a awesome engineer but also a great leader. He really set the tone culturally for the platform team to be learning environment and for people to share a lot. So a lot's really happened where he's led the hiring and training and seating of the platform team. From a developer perspective, when we looked across the enterprise and realized we've got a couple thousand developers that have worked for us for decades across different areas, we needed to do something more to reach scale more quickly. Initially, we were pairing with Pivotal and that was effective in getting some good results but we thought in order to make that scale and scale more quickly, we wanted to take a different approach. We partnered with Galvanize and brought in-house a 12-week bootcamp-style approach. >> Opal, one of the things that really resonated in your keynote, you talked about painting a picture as to how this technology really impacted your customers. There was a tree, there was a sun, there was your lab's environment and roots. Maybe if you could tease that out a little bit for us and explain how this technology really impacts your users. >> Yes, well, one I think in using that metaphor, it kind of acknowledges the environment is somewhat organic, right? The platform is still growing a lot, the ecosystem we're in, we have the chance to both contribute to the community and to take from it as it develops. To me, that's a really strong notion. The notion that particularly in leadership, we're kind of we're gardeners in a way, right? We're fostering the growth and so I thought that it's a really good example of thinking about as a tree or any plant really grows. It needs a variety of factors so I said our customers are like the sun to us, they're the reason for existing, and that's what we're all orbiting around. But the air represents all the business opportunity. The winds of change have been blowing mightily for years. The soil in which the tree is planted is like all the great Cloud Foundry instances. It's the training, it's the new role definition, it's the holistic program that really defines how we work as a digital product team. We put all that together and we need constant leadership support on a number of grounds to really make sure we take and cement the change. >> What about the developers? Where do they fit in this natural, organic analogy. >> They're the growing, thriving, strong plant itself. I think both. We aim for each individual product team and each individual, whether it's developer, product manager or designer to be continuously growing and using their creativity, discipline, strength, to bring us great business results. And then when you kind of back out and look at our network or product teams, that's a really important thing to me. An enterprise of our scale is very few breakthroughs will occur, I believe, because of a single digital product innovation. It's really in the ability to knit together different products to provide an end-to-end service or experience to the customer. >> How do you look at the public cloud? You know, Cloud Foundry allows? We were talking about BOSH, a multi-cloud environment. Where does your applications and deployments live today and how do you look at the public cloud? >> You know, we're still exploring some of the possibilities. Matt and his team have been very active looking. We started with on-premise installation for Cloud Foundry. And for myself, leading a development team, it's great as the platform is a look to kind of burst out into a multi-cloud environment. It'll be transparent to my team as long as we're operating to run on our Cloud Foundry instance, they can take us wherever we need to go. They've been doing a lot of work with our security team and other areas of the company to determine what's the right way to forge the path forward. I had a meeting with them Friday and they've got some great design things in the works. I think the next six moths to a year, are going to be looking at some real strong expansion of our cloud strategy. >> How does security fit into this whole picture? Obviously, a major concern for every CIO these days. >> Yeah, absolutely. I mean, to us, we've taken a real security-first approach. We're been our CISO team has been working really closely with Matt and the Cloud engineers and they're just defining how do we want to segregate parts of our environment? How do we follow the principle of trust no one and build security in from the get-go? Again, it's a little bit like the platform itself. I'm confident when they get a solution in place, they'll minimize the burden on my developers and we can just have a security-first mindset but have a lot of the hygiene taken care of by the platform implementation. >> Again, something you don't want to differentiate on. You want to be built into the foundation, or the roots, maybe of our metaphor here. >> Opal: Yes. I heard ya. >> Opal, can you talk a little bit about the apps? Obviously, we've already used words like scale here today. Allstate's a big company. You've got lots of apps. Legacy apps, many different kinds of stacks, generations of technology. How are you choosing what ends up being is this greenfield or things that are being moved? How are you all looking at different applications inside the company? Where they live on which cloud and how they get modernized? >> We're lighting the business needs and strategy, really drive how we prioritize. It really is a matter of a lot, at this point, triage and prioritization. We've got a rich set of opportunities. When we're building new apps in-house, we're certainly looking to take a cloud-first approach. Again, a lot of that's within our own walls today but we know that with the Foundry, it offers us the option to burst out at a later date and leaves us some optionality. The Allstate Corporation, the Allstate brand of insurance is what's best known but in Claims, I also support we have a brand called Encompass Insurance so we're looking to provide support for multiple companies and build technology that can serve everyone. There are a lot of cases too, in an ecosystem like ours, where we're working with third party vendors and they're increasingly offering cloud-based solutions. Again, we do a lot of work with them from the security and compliance perspective to make sure that their strategy is consistent with ours. To make sure we take appropriate care of our customer data. And then I personally get really excited by the refactoring opportunities. I'm really fortunate in Claims that our core claims system was implemented just about 10 years ago. I call it legacy now, but it's not, (John chuckles) as far back to the dark ages as some of the other systems that you'll find within the walls of enterprises. It was build as our last big monolithic implementation and we've been doing decoupling there. So whenever we know we're going to do a decoupling, we look for what opportunity to implement new cloud native microservices and again just stand that up in our environment with the platform team. >> I wanted to ask also about culture and technology adoption. We're sitting here in the middle of Silicon Valley. This cloud phenomenon driven a lot from Silicon Valley. Sometimes people think this cloud native stuff, it's for startups, it's for the kids, it's for whatever. You're based in the Midwest and I also, I'm an Illinois boy myself. You get sometimes, kind of a inferiority complex about the coast, both coasts. But this does not seem to be a coastal phenomenon. This does not seem to be something that only a startup can learn. This is Allstate, a mature company and with a Midwestern base, can you kind of talk a little about was there anything about that in terms of people saying we can't do that here or that sort of thing? >> No, no, I mean, in fact, I think it's a global phenomenon. I was living for almost two years in Belfast, Northern Ireland. We have a division there, Allstate Northern Ireland and we saw a lot of Foundry activity among different companies there. Of course, there's a European summit every year, as well, so I think it's just good common sense. A lot of us, again, before Cloud Foundry came through were working with the different predecessor technologies and Spring and Vmware, you know various aspects and kind of knitting together which felt like reinventing the wheel. So it's just good business sense, good common sense when there's a solution that you can leverage. I think it's just like you were commenting earlier, right? If it's there and you can use it and you can allow the focus to be on what really differentiates you as a business to your customers. That's the way to go. >> Opal, the last question I have for you is there either commentary on any of the announcements that were made this week or are there any things that you're hoping really, for either Pivotal, the fFundation in general, your ecosystem that would make your life easier that's kind of on your to-do list from the vendor side? >> There's so much to take in. I think it's probably still going to take me a week to absorb all the implications. It's great to watch the dynamics going on. I think Microsoft joining the Foundation, that's a very good move 'cause we have so many different technologies within our enterprise so to understand how different vendors are working and playing together in some way is really good. I think Abbey and the Foundation, they've been fantastic about always soliciting input from members like us and members of the community about what we want to see. For me, it's always a big eye-to-word scale. Again, we're a huge enterprise. There are even larger enterprises here that have started running and when this really becomes the we all achieve the aspirational goals and it becomes the day-to-day backbone. It's just making sure this is really hardened to run at true enterprise weight. I think that the enterprise scale of the future is going to be even bigger than what it has been historically because with all these new products, we're driving an appetite towards greater and greater customer interaction. I saw that in banking ten years ago and I think we're going to see it in insurance more and more so we just want to know that we're all working together to get that strength and that power that the customer needs. >> Opal Perry, really appreciate you sharing Allstate's digital transformation with us and our audience, for John and myself. We'll be back with more coverage here from the Cloud Foundry Summit. Thanks for watching the Cube. >> Opal: Thank you. (gentle lively music)

[lively music] >> Man: 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 cohost, 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 in early days of everything happening. >> Yeah, and in fact I have been working with Cloud Foundry for longer than the Pivotal Company's 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. [Laughing] >> Yep. And I worked in the architecture group and we did architecture in emerging tech. And about five years ago, my boss, who you know, Tom McGuire, said, "You know, this platform as a service thing, I think is 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. So that was 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." [Stu Laughing] 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 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 grok the differences about that. >> Yeah, 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 skillsets. What are you seeing, what's different now than it was, say, three or five years ago, and 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. [Stu laughs] 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 weren't comfortable with the "asynch" 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 of the platform or changes in the architecture of 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 the people and 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 spent 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 there are people who are trying and then probably people who have not started yet. >> Cornelia: Yeah. >> As Coté calls them "the donkeys without the unicorn horns yet. >> Cornelia: Ah. >> But as you go out to the customer base, obviously part of what Pivotal is doing is really this huge Pivotal Apps 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 Zitney talking about this three or four years ago. Well, that was IT saying, "Hey," and that was more from the operations 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 Zitney'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 groundswell, 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? >> Yeah. So the term "cloud-native" is brilliant from the perspective of having a term for it that has really taken ahold. 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 how. 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. You know, 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 and parallel with this on this process, and the point there is 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 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. >> All right. And what about the role of data, when we talk about that? Distributed architectures, storage is really tough in that kind of environment. >> Cornelia: Yep. >> And therefore, how does data play into it? >> Cornelia: Yeah, so cloud-native apps were really, as an industry starting, and here at CF Summit, people are really kind of grokking 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 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, and 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 a shared database. There's this monolithic Oracle database or SQL server, 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 rigid architectures and configurations and so on. So when we start to apply cloud-native to data, we look at the same goals 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 today yet. We're earlier in the process 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 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 punch line was it was the data team of this organization. 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 had, had been tackling for three or four years. So the types of technologies that we're starting to see emerge and the 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 and 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 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, do you think these technologies will come from the database or, well, let's call it 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 database vendors aren't thinking about that, but again, they are keeping the lights on with their existing product, so they have those quintessential business school constraints that are holding them back. >> A quick question on nomenclature. So a few years back as cloud-native was being coined, you also heard about 12-Factor apps, and that was one particular manifesto, and certainly the ops folks, I would call it at the time, said, "Well, wait a minute, that's great for your front end, but where are you storing your state?" >> Cornelia: Exactly. And so I love this conversation about >> Yep. cloud-native data. 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 microdatabase," then of course everybody in any large enterprise says, "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 large, large ship that's hard to turn and hard to move. 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 forever. 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 cloud-native data is all about. 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. >> Cornelia, I 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 aren't at the show should know about? >> You know, I was walking down the hallway this afternoon, one thing I'll note that has changed, like I said, I was walking down the hallway with a colleague of mine, and he said, "I have 12 people from 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. [lively music]