Pivotal Developer Ready Infrastructure - CTO Advisor 052

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, welcome to, I don't know what episode this is, it's like our 58, 56, who knows, but we've been recording an awful lot, bringing you the experts from the Dell EMC World show floor, talking through some really tough topics that the enterprise is dealing with. Today is no exception. Mark, how's the show been for you so far? I'm pretty tired, actually. I'm ready for it to be over, but we've had some great conversations and seen some cool stuff on the floor, so I'm really excited.

All right, so special treat, we got James Waters. James, what is your title within the Dell Technologies pivotal world? I mean, we see you all over the place. You're always talking development, you're talking business sometimes. What's the title and what do you do? SCP product is my title, but you know, I care a lot about, you know, a couple things. One is making our customers successful, so I spend about 70% of my time load testing airplanes, as I jokingly refer to it, but spending a lot of time out with clients, seeing what's happening in the market.

Also really measuring what's working about our model, if that makes sense. Kind of believe in the science of new products, if that makes sense. So I do a lot of that and work on our company strategy, product strategy, where we're going, and I spend a lot of time with the other parts of the Federation, too. So part of the thing about us building a great private cloud is you can't just have pivotal. You've got to make sure that, you know, the NHC environment from EMC is really bolted in, ready to go, and we announced some stuff this week.

Let's talk about developer-ready infrastructure, where Pat Gelsinger got up on stage. So I've been working with the VMware team on that. Yeah, so that's what I do, and generally I've been kind of chasing down this idea that enterprises are going to look more and more cloud native over time. That was kind of my thesis maybe four or five years ago, that we could introduce a whole new operating model for enterprises that resembled cloud native companies, and that it would change their operating costs, their whole development ROI would change, they could differentiate themselves.

So I'm excited to have Brian here today to be one of the people on that journey with us. Yeah, so that's a long time, so I'm really interested to see what Brian has to say. Brian, you want to introduce yourself? Sure, I'm Brian Gregory. I'm from Express Scripts. I am the director of the cloud strategy and engineering team. So what I started out, it was basically go figure out how we're going to, we're running a hundred billion dollar organization, how do we start doing these new cool things much faster and not disrupt what currently is going on to run our organization.

So that started out with deciding what we're going to do from a cloud perspective, what made sense for us. The type of data that we have, it made sense to start with an internal cloud, a hybrid cloud. And then we decided what was the platform, you know, how would we run the platform. Actually, I think it was reversed. We started out with a platform and then we would figure out how to run that. So Andrew, who are you and what is your role?

My name is Andrew Clay Schaefer and I suppose I'm the senior director of Ravel Rousing at Pivotal. And my job is to try to help James be successful and at the same time not cause too many problems for James. So I spend a lot of time in customer meetings. I also do a lot of conference talks. My team that I've built is focused on developer advocacy. So we're split between Spring and Cloud Foundry and we're really focused on helping kind of message this cloud native narrative, both from the dev and the off side.

And my background has really been kind of bringing that DevOps story and taking, literally stealing the good ideas from building the big web. I was a co-founder of Puppet Labs. I did a bunch of stuff on OpenStack and now I'm focused on Cloud Foundry. So stealing all the patterns that we've seen successful building the big web and trying to package them and help bring them into the enterprise. So this is a nice setup. We're at Dell EMC World. Dell is a massive company.

One of the things that I've challenged Michael on over whether it's Twitter or over on theCube has been where's their future of Dell technologies. And he points consistently to Pivotal. He's saying, you know what, Pivotal is that next level of integration business value of where the Dell technologies of family needs to go. So James, walk us through, what is the vision? Where are we coming from and what do we need to get to when it comes to enterprise IT? I think the articulation of where you're coming from is really important, right?

Like it's sort of like, hey, there's a new shiny tech. But spending a little time of like, what are the current set of assumptions a lot of organizations operate under is important too. So when I, you know, I was down at FedEx, you know, I gave a talk about the future but first I went through my past. And my past came from Sun Microsystems where we actually invented Java. You know, that was a nice little thing that Sun gave of the world.

Yeah, that was a little thing that we did. But at the time, the model was that you would buy a million dollar server or more. You'd buy it over six months. You'd spend time assessing it. You'd spend time rolling it out. And then if you needed to scale that application, you'd buy a bigger one. Famously, LinkedIn, even in 2005, was still running all of LinkedIn on a vertically scaled 72-way sun box. People forget this. Like there was a whole era of slow deploy waterfall technology that came for the last 20 years that were just now really at some of these conservative enterprises starting to change.

0 was built on Sun. It was. And, you know, Brian, you speak to the truth. But when you're in a, your truth, I mean, but in some of these organizations, waterfall was at a fault. And so, speaking of developer-ready infrastructure, developers didn't actually even touch the infrastructure before because in that old world, like you were saying, they would email a war file. Correct. Yeah, they would, traditionally they would build it on their desktops and then they would ship a war file to another team that would then try to get that implemented into the environment.

And obviously there's a disconnect there. So how's that journey? It seems long and hard to get from where you were years ago to something brand new where developers don't have to care about infrastructure. Yeah, I mean, for us it's it's been every day, you know, you're making progress, right? So if you look at it and you look back at the the road that you've paved, you know, it feels pretty good. But yeah, every day is a struggle to figure out how to go faster because you want to go faster and do things better.

You know, we've been, we're about 18 months in now with Pivotal Cloud Foundry and it's really starting to take off. So we've got over, you know, 1,100 AIs running today. Apps are starting to move, but we still have a lot of that frozen middle and the other stack that we're trying to migrate over. You can't take everybody at once. We've got several thousand developers. So that's a little bit of a pain point, but, you know, we're working through that. As a matter of fact, that's literally what James and I were talking about before we started this session, was how do we sell for that?

So I think my question is, why did you choose Pivotal Cloud Foundry over roll your own Cloud Foundry? Oh, that's an easy one. For me specifically, I wanted to figure out where the value line is for me. Like, where can I deliver value to the organization? And that was to not build something ourself, you know. And there's another side of that, right? So I spent 16 years at a cloud service provider. We had 55 data centers building products that we were telling customers that they needed.

Adoption is a painful thing, right? So if I built something internal, trying to get 3,000 developers to now adopt what I've built and saying, hey, Brian, this cool guy and this cool team built something neat and you need to consume it, doesn't really scale and work. Pivotal came in, obviously they delivered it on the spot, and we consumed it. It worked, and so why would I try to build that, right? So for me, we're trying to deliver another subset of values to our consumers.

I want to unravel the statement that developers don't have to care about infrastructure, and then add to this notion of the value line. Because in some ways, what we're talking about is everything's becoming more and more software-defined. There's definitely developers that are going to worry about the infrastructure. They're just going to build these platforms. They're going to build these reusable components. They're going to interface with the infrastructure in predictable ways, with scalability, security taken care of as a first-class consideration.

And that work can be done by you inside of your organization, and that's really what most of the big web had to do at their time. Or you can leverage a partnership with someone like Pivotal to let our developers focus on those infrastructure problems so you can focus on what's differentiating for your business. So as people are listening to this podcast, I know there's some infrastructure VP rolling his eyes saying, you don't understand. I have big iron on my floor. I still have that 72-way sun server.

I still have that in my data center. This is why I give this talk, so they know that I also understand that. So getting there is really tough for people to envision what they see today. A lot of that stuff, frankly, isn't going to go away right away. The goal is to have it go away, but it's not going to go away right away. Brian, can you give us a snapshot of what your physical infrastructure looks like? Sure, and it's interesting because it's purpose-driven, right?

So what are we trying to do with this set of infrastructure? If it's to adjudicate claims, something maybe that doesn't have a user impact directly, like you don't care how we're adjudicating your claims on the back end for what we do as a business. You do, maybe that's a mainframe, right? That's okay. The legwork to get that off of a mainframe, to say we're going to go move that and be like cloud-native with it, doesn't really make any sense. When you start looking at user feedback, the user experience, things we can do there, you need something that's quickly scalable and available to your consumers.

For me, I'm trying to provide for specifically our chief innovation officer. We have a big data department and then we have thousands of developers. To give them that experience to where they can quickly iterate and find value in something is the best thing I can do. There's also another stack where I'm going, I need this stable architecture infrastructure that's solid as a rock and it does nothing but process billions of claims at any given time. Those are very different things for me when I start focusing on what we're trying to build.

Andrew, as you're out talking to customers, what is some of the resistance you run into when you deliver this message? Initially, who doesn't want more agility, the ability to not be disruptive, or the ability to disrupt in their industry? But then when you talk through the vision of where you need to get to enable that type of capability, where's the level of resistance or where's the resistance points? I think that the primary resistance that you see is the cultural resistance. The technology problems are relatively simple compared to the social engineering that's required to change behaviors.

In particular, you have generations of individuals that have attached their identity to their task. So you're going into an organization and you're telling them that the task you do today might change. There might be some new way to work. I am a DNS administrator. That's what I do. This is who I am. I labeled myself this way. This is my tribe. This is my people. And if you make this go away, then I don't even know who I am anymore.

And so they'll fight to preserve the past because it's preserving their identity. So you see that resistance in a lot of places. So James, how do you change that? How do you see people changing that resistance? How do you get past that? Yeah, I think there's two lever points there that I see. One is that you give the users an experience that they love and that they can't go back from. So when you start to use the platform and you use CF Push, you use Spring Boot, you use some of these very productivity and experience-oriented interfaces that we have, I think it really would be hard to go back.

Like, I don't know, Brian. Well, that's part of it. Yeah, I would 100% agree with that because it's very different, right? When you start to deliver things much faster and you have the value there, you couldn't go backwards, I don't think, after that point. At least not without somebody coming after you, like with a pitchfork. No, and I would say we're not perfect. It's a journey for us. So a point where we're working in our R&D organization to deliver more and more is actually fully functional data services on the platform as well.

And it's essentially like once people have that experience, they want everything in that experience. Right. And so some of the friction then for us is almost like, okay, this is great, but I want the world this way. Yeah, so they look at it, they come from, we talked about this pre-podcast, developers are not oblivious to what's going out in the world. They use AWS, they use other paths, they built applications on Salesforce or whatever, and they come into an environment, they might settle for traditional workflows, but once they get a sniff, like, wait, this is what I used to do somewhere else, they want the whole thing.

Yeah, to add to that, what James was talking about, so we installed and we got PCF going, like that was great, that was one level, but there's still demand, right? So they want a fully automated, like self-service pipeline, you know, availability. So let's just take something like, how do I get access to PCF? You know, how would I get in there? We had to build a portal for them. It was a self-service portal, take us out of the mix and enable them to go faster.

Like if you wanted access to his organization, you request access, anybody in that side of that organization can now grant you access. It's not back on like some platform team to go, yes, you can be inside that space or not. So once you gave them one thing, one little taste, they just had that. So here's what's funny about that, right? Because that's one thing, then it's a taste. Now all of a sudden, well, hey, we want to do this sniffing on the fly, like, but we want to call you every time, you know, and that's our goal, right?

Not just because people will say we're lazy. You want to automate everything because you don't want to be called every time they need to do a packet capture to do some debugging or something. So we do automate everything for efficiencies and to get us out of the mix and to make them better. And then the second thing, if I could just answer the question, the second lever you have is, and this is where this made some beautiful presentations for us, about the actual business impact of operating apps in this cloud model.

And they've said publicly that they're running over 10,000 app containers with four people and that they've taken their, you know, resiliency up, they're down to the mean time to repair was 50% better. So there's a series of business results that we've generated from, you know, when you use a platform model, your operating costs go way down, your developer experience goes up. And that's actually something we can take to CIOs and CEOs. So we kind of come at it in both ways. We give the end users a better experience.

And I think the reason we've been commercially successful is like, actually, the business really makes sense here. So to add one point to that, that I'm living out is that, so yeah, we focus on other things now as a result. So I have, when I look at my team, I'm hiring developers, they're actually building code and building things that actually can be services that people can consume. They're not necessarily managing the platform, just being traditional ops guys that, you know, have to go do that kind of role.

So it's changed the game a little bit from my perspective of what we can focus on, on the team alone. Yeah, and then I think, you know, we haven't gotten everywhere. And but I think as more and more of this becomes the standard, you saw we did an announcement this week with Cognizant, where Cognizant has 40,000 developers. They're a big, you know, contributor at Express Script. And, you know, their CEO and management team spent some time with us and said, wow, this this kind of cloud native operating model is big.

I want to enable all of our developers to do this. And this is how we want to engage. So to add to that, and in some ways, go back to the resistance, what the overarching pattern is here is making, doing the right thing, the easy thing. It's not enough to just enable developers and you create this Wild West thing where they could do whatever they want. You're making it so that what they want to do is actually the right thing. Because it's so easy to do the right thing.

And you're getting all the benefits from the scalability and the security that's built into the platform. So, Brian, Express Script is a highly regulated industry. You're in health care. You have PII. You have data that you need to protect. One of the fears of infrastructure technologists and practitioners and VPs is giving away that level of capability and letting go of the keys of the kingdom, you know, compliance, audit. How do we track all of this stuff? How do we do the stuff that once we get past the technology and maybe even the people hurdle, how do we tackle some of these practical audit challenges?

How do you guys approach that? So that's a funny topic. For me, I tell this little story about how like PCF was basically the thing that broke the dam. And then we started riding this crazy wave and trying to, you know, you're forced yourself to look at the mirror all the way down because now all of a sudden you got to figure out everything else, right? Because that's exactly it. How do I release code to prod? Like that's a whole other conversation.

What am I going to do with this data? So everything, you know, our approach was we will still do this, play by the same rules. We're going to solve them differently, right? And so maybe it's instead of these check boxes and manual people doing manual jobs, we have actually some automation where it's logging these things. You know, we protect ourselves in different ways. So it's, we haven't. So again, let's talk about how do we get code? Like we started out with that.

Well, how do you get code into the enterprise? Clearly we're not, you know, IRM wasn't going to let us just go connect to the open source community and just download whatever we wanted. So we came up with a pattern. We'll take a Jenkins user. We'll go through artifactory. We'll lock it down. We'll whitelist where you can get code from. So that was a conversation you couldn't have before, but you have to have it to figure out how to accelerate and be successful.

So everything we had to do, and that's, again, going with the release process. We had a 10-day cab control process. So those things have to kind of get blown up in order for you to actually realize the value and be successful. So Andrew, I'd like you to expand upon that beyond just this. What are some of the other areas that people need to pay attention to when they go down this developer-ready infrastructure model? First, I'd like to add on to this idea that Brian just put out there, because we're having very similar conversations and very similar problems are being solved in the federal space and in financial space.

And they all have compliance. They all have security, all of these things. And what you come to realize at some point when you're letting software enforce these policies is that you can actually not just do them differently. You can actually do them better. You can enforce security policy better with software than you can with the theater that most of the compliance processes end up being. And then to answer your question, I think that there's, again, just going back to this notion of the social engineering that's required to change behaviors.

So you have developers, they now have a platform. Well, maybe you should teach them about 12 factors. Maybe you should teach them about the application architecture patterns. How are you going to put the things on the platform that are going to make the best use of the platform? There's a bunch of opportunities to train the developers, to train the operators, and all that is changing the way that they work day-to-day in a way that sometimes that's going to be the resistance you have to overcome is the social part.

So I think one of my final questions is, there's a lot of controls infrastructure and IT has placed on things for a very long time, for good reasons, bad reasons, and just because sometimes. How do you distinguish between the what I have to do and what we do? I'd like to make a case. So we announced this week, this developer-ready infrastructure initiative with NSX from VMware. I can make the case we can do much more control now that we actually understand what applications need.

I've seen network teams building ad hoc arbitrary networks and not even knowing what apps need, which end up being way more wide open than necessary, but having arbitrary complexity. They don't actually always accomplish limiting what the app can talk to to only what it needs to talk to, connectivity. With PCF and NSX together, the vision is over time that you bind to the data services you need to for your application, you bind to the routes and the APIs you need to, and you bind to other applications, and NSX lets you talk to that and know more.

And to me, that's a much more advanced security environment than we've ever had in a data center, which often has a hard outer shell and a very chewy middle, as some people have remarked. Yeah, we're actually, we are doing that today. So we use the application security groups, and then we also have NSX at the edge. And then on top of that, we still have firewalls. So we've got three layers of, you know, that we're using. So there's added layers of security in our space.

So one of the things I've talked to, I hate to steal our thunder, I don't want to go out on it, but they talked about one of my favorite topics, which is NSX and integration of NSX with real applications. One of the original visions for network virtualization in general was the ability for developers to interact directly with the network. Then we discovered, you know what? Developers don't want to interact directly with the network. That's really not a great idea. They don't know how to.

They don't know how to, they shouldn't. So at the end of the day, they consume the network. And how is Pivotal Cloud Foundry making that consumption easier through the integration of NSX? Yeah, I'd like just to riff on it a sec, since it's a passion for me. What we've done is we've embedded the connectivity and network rules into nouns and verbs that developers understand. So developers need to understand, oh, I need to connect to this API, or I need to buy into this database, or I need to talk to the service discovery.

Those are all developer-friendly nouns and verbs. And the integration with NSX says, well, if you know that you need to talk object A to object B in the developer world, we'll plumb that with the network. And Martin Casado has said that now that you have these microservices environments where that's all explicit, that metadata can be harvested to drive the network. And so as opposed to making the network arbitrarily programmable with some sort of complex policy language, you're actually just, you're attaching it to the nouns and verbs developers are already using through automation, which I think is a huge shift.

Before the integration work that's being done with NSX and PCF, you basically required the network people to understand the app topology or the app people to understand networking to get any of this kind of programmable network to work out. What we're doing here, going back to this pattern of making the right thing the easy thing, is you're pre-deciding what those policies should be, pre-deciding what those topologies should be, and then you're just letting software enforce that by the predefined policies that were agreed to between the network side and the app side.

So wrapping this up, this gets super exciting, but we're already stretching to the limits of the normal podcast. You know, you think about that capability where we've abstracted the way the network and these two objects to something developers can understand. And now you introduce something like cross cloud to that. And now they can take applications and move them across infrastructures, just independent that you don't have to worry about. IP addressing, DNS names, if the objects are consistent and the foundation is NSX, you have an interesting solution.

So with that, let's wrap up. Let's go through where people can find each one of you guys, social media, if you do social media, and what you want to plug. James, we'll start with you. So I've written a few tweets at Waters James. All right. Brian, do you do social media at all? I do. I am at Mr. Brian Gregory. Brian Gregory was taken, so I had to go with Mr. Brian Gregory. I think you should change to Sir Brian Gregory.

Yeah, yeah, yeah. Thank you guys. I'll do that. The fastest way to get my attention is at Little Idea on Twitter. I have open DMs if you want to talk about anything. And as always, you can find me as at Sensi Storage on the Twitters. And lastly, you can follow me at CTO Advisor on the Twitter. As usual, if you're over your mom's house and her phone is unlocked, open up her iTunes app, subscribe her to the podcast.

She might learn something. Whether or not she wants to know anything about development or IT in general, we just love to see those numbers go up. We'll talk to you guys next episode of the CTO Advisor.