 All right, the post-lunch crowd. Very excited about this, see if we keep you awake. Thank you for joining us today. My name is Richard Sarotar. I had a VP of product for CenturyLink and CenturyLink Cloud. We'll be talking today a little bit about the enterprise transition to Paz and some of the objections you may face and hopefully answer on that journey. So I do work for CenturyLink. We're an 85-year-old telecommunications company, the second largest colo provider in the world, their largest telco company. We've got a Gartner recognized public cloud. We've bought AppFog a few years back and do public Paz based on Cloud Foundry, launched the first .NET extensions back in 2011 with Iron Foundry, do a lot of stuff in this space. And part of that gives us some unique perspective on companies who are doing everything from managed hosting to doing straight up Paz. And it's not always just as simple as a cloud native sort of transition. So excited to talk a little bit about what it means to do this transition. I've also been playing with Cloud Foundry for a few years. I taught a training course you can find on Pluralsight.com that goes through a developer training. It's a fun technology so appreciate the chance to chat with you about it. So 451, it's a good outfit. Coté left there but they're still cool. Doing good stuff with the cloud. They did a research report that showed that 42% of workloads over the next two years are targeting cloud. It's not a lot, it's a lot. But you might be lent to believe if you follow at least my Twitter feed or maybe your own that everyone's doing containers, your parents can use Terraform and third graders are writing go. Like my gosh, everything is moving way too fast. But that's not really the case. As we know that, the same survey actually showed that they asked IT managers, what stage of your IT journey are you in? And 40% said virtualization. That really, really. So 40% are in that meaty part of virtualizing their infrastructure which shouldn't be that surprising if you actually live and breathe that every day. But to someone who might be thinking the world has now moved on and Paz is so five years ago, that's a really interesting reminder that 20% of those said they're in the automation phase. Only 6% are doing orchestration, like really advanced stuff. So we're still in this point of trying to figure out how do we optimize in this environment. A lot of room to take advantage of what Cloud Foundry and Paz has to offer or cloud native applications, whatever acronym we're using. But that's a really valuable area. We haven't passed that, we're still entering that phase. But the key and what I'm gonna talk about today is the approach is different. Arguably Cloud Foundry and Platform as a Service is the most disruptive of the cloud modalities, right? It's not software as a service where things kind of, I can understand that, right? I'm consuming Office 365 or Salesforce, it makes sense. Infrastructure as a service, I might lift and shift VMs and do a kind of a lazy migration that works fine. Platform as a Service is a fundamentally different way of thinking about designing, deploying, and running apps. So how do you possibly inject that into an enterprise that may have spent decades building up process and tech to not do that? I mean, what's the goal? And we'll talk about this, hopefully this will be the theme through the rest of it, but the point is we're trying to go faster. We're trying to be relevant. We're trying to make sure that as companies we're growing and we're doing interesting things, it's not the technology, right? We all have introduced technology into our organizations, but just doing it for the sake of it makes no difference. So it's the point that I'm trying to be a productive company. So what's the problem? First quick area, I'm sure if I polled you all, let me amuse myself for just a second. Who's a developer? Few, who manages developers? Oh, a few. Opside, mustaches who just attend conferences to get information. Some senior executives, well done. All right, so if I polled the different groups and said what are your problems from an IT space, right? Where do I spend my time in IT? We all know some of these. There's areas of server sprawl, especially now in the cloud, where anybody can do anything they want with a credit card. I mean, I can buy ERP with a credit card. That is horrifying and awesome that I can do those sorts of things. So that means if you're in operation, that is a disaster of how do I keep track of my things? They're all over the place. I have a bunch of servers with 3% utilization and they're all over the place. I don't know if they're in use or not. What's going on? I've got configuration drift where I couldn't recreate this app environment to save my life because I have patched and updated and done all these things and now it's this careful precious snowflake I can't destroy. So that's fine, that happens a lot of times. You also clearly have cost structures changing. You have the pace of tech. I mean, joke about this, but I'm paid to keep track of this and I barely can. I don't know how most of you are able to keep up with the pace of tech and innovation and that can be daunting as you figure out where to spend your time. You've got how many people actually test their DR scenarios? Most survey shows it is a very small embarrassing number, a proud hand back there, I appreciate that, but most people are terrified of a failover scenario. Is that something that's built into your service structure? Skill sets, are they keeping up to date? And am I maximizing investments? If I talk to most companies, and as all of us think about it, you've got data centers full of decades of investment that you're not gonna throw away tomorrow to use a cloud native application platform or public cloud, that's insane, right? You're not going to do that. You want to think of ways to take advantage of that versus necessarily scrapping it all. But I would argue if your CEO is being kept up at night, it is not because of any of those things, because those are manifestations of something and those are causing problems, but you're worried about things like strategy decay. It was a term used by Dave Gray in his great book, The Connected Company. And this idea of successful strategies are copied, that you have this period of hyper-competition right now where it's really easy to disrupt someone else with very little capital investment. So how am I keeping my strategy up to date? How am I making sure that I am pivoting when I'm detecting a new market, when I'm seeing the growth is slowing? That's what's keeping people up at night. 33% of CEOs said growth was their number one priority and their focus. How am I making sure my strategy from three years ago isn't now irrelevant? And am I moving fast enough, right? And enterprise typically becomes successful over time by creating a lot of efficiency processes. That does not lend itself to flexibility and agility. It lends itself to consolidation and standardization and then a freak out when you do something that's non-standard. So how do we pivot a little bit internally and change internally to handle the fact that I need to be able to build applications that change? I need to be able to innovate faster. So let's talk about that. So why Cloud Foundry? I would argue there shouldn't be a CEO who could care less about Cloud Foundry. That means they're super involved and maybe that's cool, but they probably have a lot of technologies that they're worried about. They're worried about things like, am I getting things to market faster and learning faster? Am I entering something interesting there? Is this helping me do that? If yes, let's keep talking. If no, then I can't spend time on it. Am I experimenting? Boy, with this rate of change of technology, it's never been more fun to be able to say, let me try something and see if this works maybe at a low cost and throw this in the market, maybe at bombs, who cares, I'll take it offline. No more two-year, three-year, five-year projects that you don't know if we're gonna succeed. Quicker experimentation. I need a low barrier to entry, though. I can't start from zero and scratch and try to think about how in the world do I pick up this technology and start using it. I need value on day one. Is this approachable? Is this something that my developers can use? Is it something my operations staff won't mutiny over? Can I take advantage of that? In the app-centric approach, you've seen some more of this, I know this from this conference, is it completely shifts your mindset from going, I care about servers to, servers are irrelevant. OS is irrelevant to some extent. I care about the app, because you know what, your customers couldn't care less about which flavor of Windows or Linux you're running. They cared that they use that mobile app to do their health stuff on the go or things like that. So taking an app-centric approach is a customer-centric approach. A server approach is not. So I thought I'd do a little challenge response having an argument with myself, which happens in my head a lot. I am seeking attention for it, but what matters is, can I ask questions? What are the questions we hear? So I polled our field staff, I talked to some of our customers and said, why Paz, why not? Do you even care? If I even walk in the door and say, are you interested in Paz? I'm not doing a good job because they shouldn't care. It's how are you solving some of your business problems? But what are the things we hear? So I hear there's major cultural problems, right? That's the elephant in the room with this. This changes a lot of things. Your whole process for how you do release management, hardware provisioning, technology selection, guess what? They might not be relevant anymore. You might literally have to change those things and that is extremely disruptive. So I mean, there's no sugarcoating of that. That's absolutely the case. There's change involved. If you're not going to change and you're gonna buy Pivotal Cloud Foundry or AppFog or ActiveState or any of these technologies and not change them, frankly, you might as well start over. There's really, and I'm probably screwing my sales staff or Pivotal with that, but unless you have a real desire to change that, this is gonna be left as some weird siloed environment full of random PHP apps that your interns wrote. Like it's not gonna be used as a strategic asset if there's not a change around how do we focus on our apps and our customer experience to deploy that. Arguably, you shouldn't have architects at your company who don't code. Maybe that's mildly controversial, but you have to build reference architectures that I can deploy and architect and innovate on, get out of, I designed an awesome spec to here's a reference application that we can use to build something. You've got a data center full of stuff. What am I supposed to do with all those? That's one of the first things we also hear with this is you're showing me the new hotness. I've got a data center of old and busted. I'm not making that transition overnight, so how am I supposed to take advantage of any of this? And so some of that, and the real big approach here is that how do I embrace and extend? How do I take advantage of these apps and wrap them up a bit? How do I put an API gateway on there so that I don't keep writing APIs in Siebel? I make sure that I wrap that up so I can call through that through a more scalable API tier. How do I make sure that my mobile applications, again, might be working in a Cloud Foundry environment and talk to some of these systems behind the scenes? I don't have to gut my system. I can simply wrap it up with some of this, and Dave McCrory, who used to work for VMware and talked on the DevOps Cafe podcast a couple weeks ago, talked about how he at Warner Brothers did some of this, and his real big point was that the data has to move. If you don't move the data to the pads, you're not gonna see the same adoption because that's where the apps need to talk to something. So your data needs to be accessible to your platform as a service environment or else you're not extending it far enough. So thinking about migrating that data, making it accessible at least to your pads is a huge piece of how you are successful with this sort of strategy. The other piece is how do you integrate it with the rest of your stuff, including infrastructure as a service, software as a service? You have to make pads part of your ecosystem. If Cloud Foundry is just sitting there with only your most modern apps and it doesn't talk to everything else, you're not gonna get the same advantage. You have to think about that from day one. Where the heck do I put this thing? I mean, I've got lots of different ways I can ship this, right? We hear about them this week. There's apparently 97 vendors who sell Cloud Foundry in the Foundry area. I didn't know about all of those, but it's awesome, right? Everyone's packaging this up and you can have it hosted. I can do private. I can do public. I can do all these sort of ways to consume platform as a service or Cloud Foundry. Specifically, how do I choose one of those? And what are my implications? If I go all in on one of them, have I completely stuck myself with going another way? And so we hear that a lot. So what's the answer there? Well, there's no right answer. I guess that's the consulting answer. It's all of them. But the idea is that there is a progression here. If you are just introducing pads to your environment, I don't know if going a full on-premise pads is the right strategy, right? That's a big commitment where you maybe haven't embraced the organizational change, the technology pattern change. And so that's where public makes a lot of sense. Using something like Pivotal Web Services, using something like AppFog, using these sort of services, Blue Mix Others, where I want to try out these patterns. I want to build something secure that makes sense. And when I want to switch it over to private, where I can literally change my endpoint and push the exact same app from one place to the other, that's crazy great stuff. I don't have to worry about that same level of lock-in. So in this case, the key is thinking about that. Now, private makes sense if you've got regulatory stuff where it makes no sense for you to stick your PCI data or your patient data in a public cloud. And you might say, I don't trust that at all. I have to run a private pass or at least a virtual private pass, a hosted one. Okay, makes sense. Likewise, this needs to be close to your data again. If you're trying to have a public pass tunneling through and accessing data over in your data center 3,000 miles away, let me tell you you will have a negative experience for your users, right? So unless I'm gonna commit again to where my data is gonna go, I have to think about that. My data has to be wherever my pass is. Otherwise, what's the point? You're gonna have lousier latency and performance. You're not gonna get the same benefit. Hey, you're changing how I do config management. I worked at an enterprise company, a very nice group of folks, but they have a big configuration management database that was always out of date, but we pretended it wasn't. And it kept records of apps and servers and owners and whatever, and it was, it's a fool's errand to keep that stuff up to date, especially in this era of, I can have instances that I'm adding and tearing down in seconds. What am I supposed to track with that? Am I tracking the instance now? Am I trying to track the server? That stuff's irrelevant, but how do you deal with that? That's a big change from having a way to enter and manage your configurations. It feels like anarchy in this sort of PAS model. So I guess my answer to that is you're focusing on the app. You're saying the app is the thing that matters. So I have a configuration via manifest. That's what's awesome about this, is when I'm deploying Cloud Foundry, I'm getting runtime dependencies put on the box as part of Buildpacks. I'm deploying things with a manifest that says hook up to this service, call it this thing, size it this way. Check that thing in the source control. Now that's great. Now, granted, I can be a rebel as a developer and still scale it via CF scale and break kind of that model of just using a manifest. So you still need some process in place. But the fact that I can source control my configs, I can push that sort of thing through. My configuration is really the registry of apps that I've got. I can do CF and list my apps, CF apps, see my apps, see my instances. I don't have all this rigor and unnecessary process and ceremony around configuration management, especially when it's wrong all the time. So thinking about how do I focus this on the app? How do I have the system tell me it's state versus trying to manually keep things up to date? How in the world do I integrate this stuff? I'm used to using my VMware management tools. I've got my own log processing tools. This is, again, some weird uncle that lives in my basement. I don't know how to bring it into the family. I want it to be part of the family. Though I integrate this thing. It's a horrible analogy, but it's visceral. You're thinking about it right now. Yeah, you might be an uncle. You might be that weird uncle. I'm not judging you. But look to the marketplace for some of this, the CF marketplace. This is pretty neat stuff where I can extend it, right? Over in the foundry area, you've got companies like New Relic. You have others where I can extend and use some of those toolings, but I don't need infrastructure management tooling like a console when I'm dealing with a pass. I don't log in and boot up a server. I'm not looking at its configuration settings. I'm dealing at the app layer. So some of that goes away, but they're also thinking about marketplace. How do I append those services, but also user-provided services? Take your database and in Cloud Foundry expose that as a marketplace service to your developers. Treat that as a service catalog for your thing. So all of a sudden now, your private pass customers, your users, your public, I'm accessing my internal systems as an attached service like I should be with 12-factor apps. So being able to think of marketplace, think about services and not having my devs hard-coding connection strings to random systems, but treating it all as a services ecosystem is really powerful. Too much freedom. It's dogs running in parks. It's developers are simply taking over the world. This is mayhem. I can't tolerate this. Too much is going on here. Developers are not the new king makers. Be quiet. Steven O'Grady and Red Mung people. We hear that, right? That developers are drunk with power. This is just simply giving them more liquor. Please don't tweet that. That's a horrible way to say that. So the answer to that is that there are policies and constraints though. There are, I can use my continuous integration, my continuous deployment tools as part of a PAS pipeline. I can absolutely put some process there. I have certain behavior that the platform doesn't force. There's state management, or there's instance management. I can't have too many instances. I actually have limits to make sure my developer doesn't accidentally spin up 40,000 instances and go away for the weekend and completely screw my bill. I can actually make sure that I have some governance and policies around that. All my configs can go into source control. It's not complete mayhem where it's coming from my desktop computer or laptop or whatever, into the cloud. I can source control my configs. I can maintain that. And I have the service catalog we just talked about. So I can have this CF marketplace. I can have these service catalog items. It's not mayhem. Now, conversely, what we hear from developers is you know, you're putting me in a cage. I'm a peacock. Let me fly. You know, that's absolutely something we do here from people that says, like this is too restrictive. You're making me do certain patterns I don't wanna have to do. How come I can't get right into the box? I wanna deploy my own React cluster in here. Whatever, you're not letting me do that in my PaaS environment. We do hear that. That's a real objection. So it's a little more of a dog in a fence, right, not in a cage, but you're in a bit of a sandbox if you're familiar with the term the paradox of choice. You know, this idea of the psychological thing they did where you have 30 jellies in the supermarket and everyone looks at them and no one buys anything because they're overwhelmed, you put out four and everyone buys them because I don't have all these infinite choices to deal with. You know, when I have so many ways to implement a solution, I end up being paralyzed. So sometimes having some reasonable constraints is actually really freeing because I'm not stuck debating every possible solution. I have one way to deploy things in this sort of thing. Now let me innovate in that environment. So some of this does fit that way, that you can do a good job. Talk to almost any developer and the number one thing they're gonna tell you they have trouble with is getting access to resources. When you can give someone a sandbox to run multi-language apps and scale on demand, that solves a lot of problems. And while that may not be perfect and I may have to hook in services for my own databases or my Elk stack or whatever I wanna do, maybe I can't do everything, but I can layer some things in. And the main problem I'm trying to solve is get your apps to market faster so your company makes more money and you're growing and you're able to be more agile. It seems like a decent trade-off to say there are some guardrails around your development. So you're making me change how my apps look. Damn it, I love my client-server stuff or I love just having my simple two-tier stuff. Now you're telling me this random 12-factor stuff, I don't even know what that is. Why are you making me change what I do? We do hear that sometimes from development teams who are comfortable with their tool set. See, you want the army of instances, right? I mean, the 12-factor stuff is exciting but it is absolutely about this now. If you're building any custom apps from this point forward and not doing at least the principles of 12-factor apps even if you're not doing every one, you're doing yourself a disservice. And what are those? If you've all checked out the site 12factor.net and was referred to in some of the keynotes, this is declared dependencies. This is network-attached services. This is making sure that you have services that can shut off instantly, gratefully, stand back up gracefully. It's making sure that you've got things like good concurrency. These are just good architecture design principles. I don't care if you're in the cloud or not. These are great in your data center, right? It's gonna give you a more microservices-friendly, DevOps-friendly, Buzzword-Bingo-friendly flavor of your applications. And so it's a good pattern regardless. No more snowflake servers, right? No more unique environments that someone is terrified to log into and redeploy to. This all gives you a nice, standard, quick way to deploy to an environment which is pretty powerful. But what does this require? So what this requires is that if you're any of those folks who raised your hand saying I'm a manager of devs or I'm a mustache attending here and taking brochures, you have to give your team some help. They need training. Clearly, my plural site training is their best option, but secondarily, nothing. Nothing from you all that's blank stares. So you have that, right? But get them a sandbox, especially with public paths now. This is an incremental slash meaningless cost. Make sure your team has an effort or an ability to try these things out. You can't just say top down, here you're gonna start using a paths. It's not gonna work. What you need is developers to feel that pain and suggest some things. Use these environments. Make them a stakeholder in it and give them the tools to actually try out these patterns. Use these technologies. That's the investment you need to take if you're someone who has a budget in your organization. So I don't know what the heck to put in the paths. We hear this a lot. You can sit in this session and go, not this session, because this one's very clear, of course, but I might be in other sessions where I'm looking going that's a weird scenario I can never copy. My company doesn't do Netflix-y style stuff. We don't have mobile apps because I'm doing whatever at my company. How do I start thinking about the right apps that make sense for my paths? And we get this, right? There's lots of choices. Even us, as a company, offer things like hosting or bare metal or paths or virtual machines. How am I supposed to stick what where? And what seems like a lot of the future is picking the right host for each service, each microservice, whatever, in your architecture. There's gonna be things that fit in mobile that might go in a paths. There's gonna be things that might be IO-intensive that belong in a physical machine. There's things that need certain type levels of scale in a VM. So sometimes it's not gonna be, does this whole app move? It's which parts of it move? And as you look at the answer to that, it's things like green field apps. It's really hard to take existing apps and completely refactor them for the cloud. Sometimes you might say it's not worth it. It's running fine here and I don't wanna have to do the work necessary to switch it to a paths model. That's fine. There's companies here that help you with that, Alturos and others, who could help you do some refactoring. That's great if you wanna pull that off. API projects are great. As we're building more and more APIs when I can have developers using whatever language they want. You wanna write APIs in Ruby and Node.js and PHP and Go. I can put them all in the same darn place. That's amazing that I don't have to deal with any problems there. So putting API gateways, aggregate applications, right? Do I wanna invest more in that PeopleSoft application or in that custom app that someone wrote for me? Or do I wanna build an aggregator app that pulls data up and triggers some workflow and things like that? So those make great sense for paths. If you're not running your dot-com sites in something like a paths where you need elasticity, any of your brand sites, again, companies I've worked for would do these big bursts when they launch a product and have all these servers set up for that day one traffic and then take their time decommissioning them all when you didn't need them after day one. In paths, amazingly, being able to scale to 100 instances, do your launch, scale them right back down, that's great stuff. So any of your public-facing dot-com sites make a ton of sense for a paths like this. Using things around WordPress and blogs and open-source projects that you can run in these environments also make a ton of sense. As you do start looking at your on-premises app, you check for suitability, right? Can I tweak these a little bit for them to run in here and make sense? Is it just some small changes to be more 12-factor friendly and not have to write files to the local file system which doesn't work in Cloud Foundry? Can I take advantage of those sorts of things versus necessarily gutting it and starting over? If not, target more of your green field development here. So covered a few things here. I mean, really, hopefully the point is, is that platform as a service is absolutely a change in mindset. If you're not thinking about the organizational change, you're gonna struggle. But if you do, if you can take advantage of it, there's a lot of cool things you're able to do here by having a much more adaptable application ecosystem. So take advantage of some of that, try some of the sandboxes, don't necessarily feel like you have to be all in and invest in something major. Maybe you try some things out in the public cloud, see if they're the right fit. But answer some of those questions head on. This stuff can be tricky, but it's also super exciting and dynamic if you get it right. So I'll be at the CenturyLink booth out there in the Foundry area. If you have any questions, feel free to come up. Hopefully you're somewhere exciting in your journey with all of this. And if you have any questions, feel free to pop up and ask. Good, thank you.