 Hi, I'm Bridget Kremhout, here from Pivotal to talk to you about the future, and I figured also that we would talk about as many buzzwords as possible, so I put as many buzzwords as possible on this slide. All right, but buzzwords aside, the traditional second slide, I live in Minneapolis, Minnesota, a state notable for having snow every month of the year except July, which is why we hold DevOps Days Minneapolis in July. You should come. It's going to be great. Including people from Pivotal, and I work in the tech advocacy team at Pivotal and on Cloud Foundry, and I podcast with Arrested DevOps, and I organize DevOps Days. So that's all the things you need to know about me, except that I also probably have to cop to having some pretty severe on-call PTSD. So I wasn't called for production from 1999 until August 2015. When I listened to Andrew Clay Shaffer when he was like, come with me if you want to live, and it turns out you get just as little sleep when you're taking ridiculous flights as when you're being paged. So I'm not sure that that was the, you know, it didn't actually fix the sleep issues, but the people who are operating Cloud Foundry, and I see Jim Park, I see at least one of the CloudOps team from Pivotal Web Services here, do get more sleep than your average ops person. So we can dive into that, and also like the changing role of ops in a platform world. I gave a couple of talks earlier this year that I kind of whimsically entitled, computers are easy, people are hard, and I use a title, a provocative title like that on purpose, because obviously it's a lie, but there's a little bit of truth in it because the complex systems that we're creating, you know, every presentation that we've gone to, and by the way, there is no code on these slides, and if you were looking for a live demo, this is not the right room, I suggest any other room, but the, there are many fantastic, you know, very technical sessions here. This is not one of them, but the systems that we're creating are highly complex and yet work way better than a lot of the manual stuff we used to do. At the same time, the human interactions that as people are starting to, you know, implement Cloud Foundry, I mean, I was just sitting in a session from JPMorgan Chase where they were talking about how I kind of work like a Skunk Works team, got a lot of stuff off the ground, then, you know, there were people questioning, well, what's happening over there? How is that going to affect me? Those human elements of how people are concerned, slash confused, you know, slash perhaps even, you know, resentful about what you're changing in the organization by bringing in a platform like Cloud Foundry are actually pretty important, so let's talk about them. Because I think that there's a problem in our industry and I will cop to being guilty of this, that a lot of times techie, when left to their own devices, techies are going to pick whatever sounds like the most exciting thing and cobble it together and get it working and get it into production and get their next job and at that point, the people who are left holding the bag go like, and we didn't use Cloud Foundry, why? So, getting people to help understand that picking whatever they can assemble from the top three hits on Hacker News that day is not necessarily going to get their organization to where they need to be and it's not necessarily going to help them either. If they've created, you know, a Rube Goldberg machine, they aren't necessarily going to be able to function someplace where they're not allowed to create more Rube Goldberg machines. So, I think trying to drive to how we get to that value, I think it's, I stole this slide from Andrew Clay Schaefer, he's used this one a bunch of times and I love this idea of the, all of the initiatives that we have inside our organizations because many people who work at large enterprises, there's some place in the organization where people are building out continuous delivery pipelines and there's another part of the organization where, you know, maybe they're going to Cloud and then maybe somebody else is doing DevOps because you should just have a department for collaboration because why not? I don't know who they collaborate with, but they're DevOpsing really hard over there. And, like, if you have a lot of, if this sounds familiar, if inside your large organization, you have a lot of these different initiatives happening, I think something important to remember is they're all basically trying to do the same thing. They're trying to, you know, bring value faster, they're trying to be more stable, they're trying to do an awful lot of stuff that sounds suspiciously like a platform. And we hear all these buzzwords, we can throw one up there, like serverless. I think it's probably important to remember, and this is actually kind of funny when I was making some slides a while ago with this title of this ops in the time of serverless containerized web scale, and I got a suggestion from Keynote, and if you can't read it there, Keynote is suggesting for serverless, suggesting servers. And I'm like, yeah, you're not wrong because there are servers. Like, we can't ignore the fact that they exist, they require power and emit heat, and when we are coming up with abstractions that are super useful, super important, we shouldn't deny the fact that we still have physical reality that we're dealing with. And there's a lot of this, I got this from Simon Wardley, and it's kind of funny because, and I'll put these slides online later if you can't see that particular, you know, detail here, but it's basically just terminology of what we're calling a Paz, what we're calling a cloud, you know, what we're calling WTF. And I think that this stuff changes a lot over time. Like if you look at what's happened in the past, and, you know, where we're probably going in the future, stuff changes a lot. And so the places where we get bogged down in those arguments inside our organizations end up not being maybe as constructive. Because we are in a time, I shouldn't make it a light of the fact that there is change, we are in a time of significant change like it's, it's probably likely that a lot of people you work with in tech today never watched Babylon five, I know it's tragic. But like time passes what? And looking at lessons from the past, I think are important, like the, you know, the waves of virtualization and there's organizations that are just now getting them some VMs. And they're pretty excited about that. And it's like, well, I mean, should they jump to Unicernals tomorrow? Maybe not again, like the technology isn't the point, it's the way they get value from it that is the point. I think if we if we look at like, you know, the historical context of everything that brought us to where we are. Technology, like, no matter what, you know, the Beeper King might have said on 30 Rock technology is not cyclical. But we do have trends that come and go. And this, you know, like Bill Joy saying the network is the computer, we suddenly now are way less attached to like, very specific physical machines that we keep in our data centers, or that, you know, we possibly even have with us. My fun fact, my laptop actually died in the Delta lounge at SFO on the way here. So but because hey, cloud and USB keys, I'm fine. There's when we're building out these platforms, I think there's a lot of things that we need to consider around the architecture. And this goes to I mean, what we were just hearing from Google about, hey, tying into authentication that you already have, like stuff like UA and Cappy is it's really important because we, we all have built things in isolation, and had them be just like, you know, magical and perfect until we tried to plug them into everything the business was already using. Because the reality is, I mean, for many of, you know, pivotal enterprise customers out there and regularly talking to people who still have main frames, probably aren't turning it off tomorrow. There's still business value there. And so the idea of building things that are modular and can interoperate is I think a good way to get people who may be resistant to like changes or the platform that you're introducing to understand that like, hey, they're going to be able to plug their thing in too. Right. I think we get there's a, you know, we talked before about tech trends and there's a lot of pendulum swings with tech trends right now. And I mean, right now people are very excited about microservices. And that's cool. I mean, you should probably have microservices. You will, the principle value that microservices may give you is changing what your debugging process looks like. If you're, if you're looking at, I actually was in a conference and in an open space talking to somebody last year who said, our VP says we're going to have microservices in fourth quarter help. And I was like, what problem are you trying to solve? Because if the problem that you're trying to solve is you need to be able to deploy more consistently and correctly, I mean, maybe your VP should be looking at platforms or maybe microservices are fantastic, but you're also going to need to rearchitect a lot of things in order to use them. So like having those conversations inside your organization, remember, we still have humans in the picture, those humans have motivations. Maybe they just want to own something end to end that they can deploy without arguing with anyone else. Like maybe that's what they're trying to do in which case again, like talking to them about what they can do at the platform is a little bit more useful. Again, microservices, excellent. They just might not solve the problem that they're actually trying to solve. And cloud, I mean, we were, I'm here in a Google track, so I think I have to say like, obviously Google has a cloud. It's delightful. Clouds are a great abstraction that prevent you principally from having to worry about provisioning the actual hardware. However, just because something is in the cloud does not mean that it is limitless or perfect. And having these discussions in terms of like putting what kind of abstractions you're going to put in front of what your end users are using, I'm guessing because I put the word ops in the title that some people with ops interests are showing up for this. And so like strategically, when people say, just give me my VMs, it's like, just push back with what is it that you're trying to accomplish? Oh, you just want to be able to scale up without talking to me? We can do that. Because this having to talk to people thing is real, like Conway's law, I mean, not really a law, right? More of a, you know, an axiom, a maximum guideline, whatever. But Conway's law is basically telling you that your org chart may say that you escalate requests through the VP of whatever, but you're probably just going to talk to Sarah because you know Sarah will help you and Sarah works in that department. Like that's how communication actually works, you know, between people and the larger our organizations get, the more important it is that we're building tooling, you know, including say platforms that allow proper delegation and role based access control and all the things that make it possible to not trip over communication hurdles, you know, between people. Because I do, I want to believe that everybody is going to only deploy thing, you know, code that actually works and, you know, nobody is going to be paging me in the middle of the night. Like that would be delightful. No one pages me in the middle of the night now, but people page Jim in the middle of the night and systems page more importantly. And the reason that we try to set, you know, guardrails of whatever sort, whether it's let's not let somebody accidentally spend all the money or let's not let somebody accidentally blow up the world. We try to set these guardrails because we're worried about resource constraints or we're worried about, you know, accidental, probably not malicious, you would just take away their access if it was malicious, but we're worried about accidental, you know, toppling over the world. And I feel like this is again, like when you're when you're setting up your your constraints that do empower people because they prevent people from needing to work every single detail out themselves. I think that like the the cynical realities of ops life is the better the well signed happy path that you can give people works, the more they're going to use it. You know, this this is a the, you know, classic like make the right thing, the easy thing. Because you're otherwise you're just going to end up yak shaving and it'll be DNS problems and sadness. And it's like, is that what you really want? Probably not. So I have to have to quote interclash Schaefer again here. I like to use this quote of his because he said this on the club founder after dark podcast a while back. And this is a Gartner hype cycle. And it could, you know, this could be a hype cycle for absolutely anything that we want to talk about. You know, container orchestration, why not? But I think that the important thing to consider here is that most of tech is tribalism and tribalism and fashion. Mostly people, you know, we go to talk to customers and they always want to hear about a story from their vertical. It's like, you know, the other verticals are using computers too. But they want to hear the story from their vertical because they want to know if people who they perceive as being like them, who have their problems who are in their tribe are able to solve their problems with cloud foundry. That's that's what they want to know. They don't want to hear about people who they perceive as being not their tribe, not like them. And so I think it's it's really that's one of the really useful and important things I think about coming to cloud foundry summit just because you can meet more people from your tribe and maybe also expand just a little bit the definition of what your tribe is. And this is a I don't know if any of you recall the the left pad incident, but this is I think one of those examples of it's very easy to throw blame around when you're operating things in production and someone else probably those NPM people or whatever. Somebody else, those front-end developers made a terrible choice and now you have outages and sadness. But like the reality is if you're tasked with operating something in production and you might be a balanced team that also is developing the application as you go, there might be handoffs inside your organization. Like I mean I can't I can't dictate what your chart is going to look like or your responsibility matrix or whatever. Your your racy chart may say that this is someone else's problem but someone is going to have to care about how stuff is operating in production and chances are good that if you're coming to a talk with this title it's probably you. So like this is owning your own availability and figuring out what your allowances are and where the platform is going to allow you to give people a lot of latitude and where nothing will allow you to give them latitude super important. This is this is where the observability that you can get by using any one of the many choices from PCF metrics on you know on out what any of these choices in the platform to have better visibility into what's going on with your infrastructure and into what's going on with the applications is super useful. So this is again like tactic tactically from the point of view of somebody who maybe once they operated a bunch of you know VMware and now they still operate some VMware but there's also like public cloud stuff that things are bursting to and they're not exactly sure what their job is and maybe it's going to be very different soon. I would challenge you to think that like scaling and telemetry and observability of the overall platform is probably your job at that point. So that's the stuff to focus on you know asking or answering those questions that you didn't even know how to ask. I'll put a plug in there for a honeycomb.io has a beta PCF tile is worth looking at for this sort of thing. And this again it comes back to the way you're going to handle the handoffs and the communication between teams like at pivotal for you know the escalations for the on call process there. Many teams are in the on call rotation for different services. And like that's a model that many people find valuable so that they're not sending all alerts through people who maybe are just going to act as a really angry named pipe to send it to the developer who they want to blame and be angry at. Like instead of that you know I'm not saying make every single developer who basically just knows how to write some Java be on call for you know your open stack. That's not what I'm saying. But I'm saying four things people are going to be the best one to answer have them be the first one to be asked. And this is also I think really important to and this is that that human factor of communication between teams to hang a sign on those things that you know you probably want to change but it's a known limitation maybe a few people have even bumped up against it and open to ticket about it and you still can't really change it yet but also it's politically bad for you to talk about this problem that you can't change it's like okay that's just going to waste a lot of people's time and we've all had something in our infrastructure like that that waste a lot of people's time just put out whatever kind of announcement you do and say like this is our remediation plan but for now these are things you need to know. This was actually a glacier in Iceland. I went hiking with my spouse and and it said attention natural hazard do not pass this point and that's exactly where the guide was taking us and I was like well at least they had a disclaimer we didn't die the glacier was melting into our boots but we didn't die and this this kind of also like that idea of what to alert people to and what to monitor on there's a lot of the old style of monitoring that focused on you know the the host check and the disc check because those were things that were easy to check and therefore easy to tell you how they were doing but it's like what does that actually tell you about capacity or capabilities like what does that tell you about what your organization is suddenly not going to be able to do and the way that monitoring is going these days is again like with a modern platform you can actually say hey yes you can you can deploy yes we can handle this amount of load depending on whether you have auto scaling or you're doing manual scaling of the platform like there's going to be differences with how you handle you know any kind of capacity issue but this is the sort of thing where you can imagine and maybe some of you remember like I do that there used to be a whole thing with you know procurement processes and purchase orders before you could scale anything up it's like okay we're past that but are we to the point where people don't have to do quite so many handoffs between teams like if you're trying to get something and there's getting things from the infrastructure team and then getting firewall roles from the security team and all of that like that is going to make for a really difficult monitoring troubleshooting and debugging process if you're trying to figure out exactly where the problem is so this is a I think I also want to point out that there's a lot of focus in developer centric communications about day one it's going to be developer ready it's going to be easy to use we're going to get this out there and that is all great but day one is really short and day two is probably forever and you're going to have stuff in production a lot longer than that initial exciting rollout that you had a party about so having the the focus inside your organization to allow you to configure and you know maintain your cloud foundry installation such that you aren't going to put undue burden on the humans who are still part of this equation super important I also want to put a reality check about like attack it and get bigger by the way that's what happens when you feed them but reality check about it's very easy for me to stand on a stage and say you should and it's very easy for you to go to a meeting and give somebody recommendations and it's not easy at all to make sure everyone who needs to follows through and to make sure that all the stakeholders actually can be brought to some sort of agreement this is that human stuff is really sticky is sticky widgets and they're it's hard and I don't know about you but I got a computer science degree because I didn't want to talk to people and apparently I made terrible life choices at some point and so here I am but like it turns out we all have to talk to and interact with other people and have some degree of empathy and understanding for why they want the clearly wrong things that they want and how we can convince them that they want the clearly right things that we want like this is actually you know pro tip life hacks that we all need in order to get the things that we need and we want you know inside our organizations just gonna take a look how I'm doing on time I'm doing delightfully on time this is great okay so alright so you're here you're like okay those are really cute pictures to your cats but we're here at a tech conference why are we not talking about specific tools I did warn you there was no code of live demos here but I also think tools are a little bit beyond beside the point like they are really important you're you can hold hands and think from by and not really be devopsing at all if you don't have tools that actually work so they do matter they're just not going to solve the problem by themselves I mean even Cloud Foundry as delightful as it is isn't going to solve all of the problems inside your organization where people are resisting change or where people would prefer to build something that is there you know their baby and they do not want you to tell them their baby is ugly and you're like your baby is beautiful I just don't want to maintain it and it's like yeah exactly so I think this is where like the the classic and it doesn't just have to be developers and operations I mean this is the Andrew Clairchafer's classic wall of confusion but I like to think of it a little bit I remix this one a little bit I think of it more as like Team YOLO and Team NOPE and this has to do with how the incentives are set up inside the organization right so if there is a team that is celebrated when they ship things that are exciting and then they wash their hands of it and they go and they do something else exciting that's really super for them and the people who get paged on that exciting stuff when it hits corner cases hate them and would like to say no to their new exciting ideas and if there's I see a couple of people nodding and if this happens inside your organization think about how the incentives look inside your organization like if you're again this is this is not something you can solve with Cloud Foundry but this is something you can solve by thinking about what motivates people if people are you know having the release party while someone else is dealing with the data center burning down like that's not going to lead to happy inner team communication and it's also not going to lead to everyone being excited about the next release I mean some people might be but probably not everyone so like some specific actionable things and again this is this is very very simplistic I'm just breaking it down to like people who are primarily tasked with operating things and people who are primarily tasked with feature you know new feature development that doesn't mean that no one bleeds over between the two obviously most people do but I would say it's really important not to just say drop some devs into your on-call rotation and be like good luck have fun and then they get patient and they're really sad and they hate you so that doesn't actually make it easier better but if you have good automation everywhere that you've you know made some Bosch choices you check all of that into version control right maybe everything has to go through version control even to get released hopefully and you don't have like I think a lot of people do have those few things that are really only known to the people who do it the most frequently and that's that does not democratize the observability it also doesn't lead to better sharing and this doesn't mean like you have to sit there and write write documentation whatever that means no one wants to write documentation but you probably could write a reason on the commit message like minimum viable documentation and then for people who are developing those features that are essential and necessary and really important and are making the organization money or helping it reaches a non-financial goals I would say it's really important to think about the operability of your software because your software is going to do exactly what you wrote it to do probably some other things that you didn't expect it to do and you're going to have an awful lot of inputs that don't look like your ideal test cases and so like I think that seems so basic but there are how many bugs do we we all run into where it's like oh I didn't think this would happen well I mean again that's what you're automated and then manual testing is for but you know your exploratory testing is really valuable for finding the things that nobody surely no one will yes they will but having good tooling around your observability and your debugability again like this year when you're when you're implementing your platform think about where you're going to send your logger gator like you're probably going to send it to one or more places what kind of problems can people solve with the data there and then I also just have reality in here because I don't know about you but I've definitely worked with really optimistic developers and I'm a cynical realist because I'm an ops person at heart but I've worked with optimistic developers who everything was the happy case and it's like well I mean the happy path the ideal case where nothing goes wrong is mostly what they focus on and it's like well you know if you have an endpoint that returns 200 okay literally that's what it does like it just returns 200 okay all the time no matter what else is going on you're right that instances never going to get thrown out of the AWS load balancer like you did solve that problem you may not have solved any other problems but real like real life I have actually run into that and I was like oh that's you know that endpoint is not it's not operating in reality so and something else too and we I know we've heard in some of the keynotes and what not a little bit about this but like the human factors of it's easy to say that your distributed systems problems are basically just like cash and validation and naming things and off by one errors you know there's a lot of great jokes about that but I would actually say that the main one that I think is a real problem in computers is the fact that humans we get really attached to our ideas I mean I know I get really attached to my ideas and we get really upset when someone else doesn't see things our way and I think it's it's really important to remember that the other people who are clearly wrong and are making choices that are making us very frustrated are still people and they have motivations just like us and so we have to work with them like we we can't use the abstractions that make our lives a lot easier to shut them out of our lives entirely because as it turns out those abstractions are kind of leaky so I mean like for example at Pivotal we are you know a worldwide company and we do a lot of collaboration over you know internet based tools and this was actually envisioned it's kind of funny this is a French some French magazine art from 1890 where they have an artist rendition of like you know video call where the audio is clearly having problems and the people are you know dropping off of the the call I feel like we we have a lot of places where we've imagined or envisioned what the future is going to be like what how people are going to use the tools we're creating how people are going to use how end users are going to use things how our collaborators and coworkers on open source projects are going to use things we have a lot of these visions of the future that you know that's the near future the next week future not the hundred years in the future we have a lot of those visions that turn out to be sort of right I mean in retrospect like this is this is sort of right and it's completely wrong this is not actually what the year 2000 was like for my recollection at least I mean maybe I don't know but yeah I was on call for for Y2K in December 31st 1999 so perhaps my recollection of 2000s a little a little hazy but but this idea that we can't always know what the future is going to be like but we can try to set up structures and processes and tools that will help us with what we know is going we know there's going to be change because I think and this is this is another quote from Schaefer I just I could just do an entire talk that's all Schaefer tweets hmm this is a challenge for the future but what he's what he's saying here is the software industry is stuck on deployment but we desperately need to be looking at architecture and telemetry which is another way of putting that is day one is short day two goes on for a really long time we need to run this stuff in production a lot longer than we need to see it working because this is I think there's a lot of and again I have nothing against developers some of my best friends are developers but and I know I'm running a tiny bit long but in a world that is saying go out there and ship your app it's like that's awesome is that app going to like write data somewhere maybe need to collect user information provide value in some sort of way that matters so this is that's basically what I see is like the whole thing behind dev ops is we're all going to collaborate to make this sort of thing possible and that's it I'm with pivotal where we've got spring one platform in December you can come to that if you want to talk more about this stuff otherwise thank you so much