 Thank you very much. Good afternoon. Thanks for coming along. It's a very, very big room. It's a lot bigger room than I'm used to speaking in. Start off a little bit about me. I've been involved in the open source community for about 20 years now. Since I was a teenager and discovered this Linux thing, it was a bit cooler than that Windows thing. I work at Puppet Labs. I run the operations and professional services group there. I'm an author. I've written five technical books. Mostly about Linux. This had been an open source set of things. I'm a big geek. My wife would say very much a big geek. I'm known to buy every single gadget that appears on the market. I usually buy two of them and break them fairly quickly. I should warn you, I do talk funny. I'm from Australia and pretty much every other part of the English-speaking world doesn't believe we speak English. So if you find anything you can't understand or find that I'm talking very quickly, wave your hands frantically in the air and go please slow down. Okay. Not a good sign. I'm also a win jig bastard. I've spent a lot of years in operations working in some big shops and I'm well known for complaining about things. I don't like things that are broken. I'm a firm believer in perfection. I don't think you can achieve perfection but you can get a bloody well of a long way towards it. So what's DevOps all about? This is a topic that comes up a fair bit. And I don't think there's a clear answer to it yet. So DevOps is about cooperation for me, cooperation between development teams and operations teams. And particularly important as to why Belgium is so important for DevOps is because the gentleman who coined the phrase DevOps, Patrick de Bois, is obviously from Belgium. Chris, and I'm going to stuff his surname up, Bayart, also heavily involved in the original DevOps movement. So pretty much the original DevOps sort of thinking emerged out of a bunch of people in Belgium sitting around, I think, drinking beer, which may have something to do with it while they felt the sort of love for one another. And generally the whole, I guess the whole movement emerged out of sort of a bunch of northern European cis-admins. So what comes up when you start to look at DevOps? There's a little bit of a keyword cloud, and I'm afraid that the top bits cut off there. There's some of the phrases that come up when you look at various blog posts around DevOps. And I look at these sort of things and I go, well, what does this become? Is this some kind of buzzword bingo where after a few phrases you all will get sit around together and go, we can talk about DevOps and cooperation and ITIL and we can talk about cross-functional teams and somebody can sort of sit in their meeting and go, bingo, we've managed to parrot out all of the appropriate corporate phrases and phraseology. Is it a pop culture movement? Are we a bunch of fly-by-night guys who are just trying to con you into buying something? I've seen a couple of products so far that claim they're DevOps compliant. I'm not sure who they were certified by, but if they buy me beer I'm happy to, or bourbon even better. I don't think we're a pop culture movement. I also don't think that we're going away in a hurry, but I do have some caveats before I talk a bit further. So it's very early days. So DevOps is probably about two years old in terms of its sort of thinking and it's probably only about six months old in terms of people actually sort of, I guess, more theoretically considering all of the possibilities that DevOps implies. Largely speaking, the first conversations about DevOps happened about two years ago. I think last year they had a DevOps dinner at FOSDEM and I believe there was about 10 or 15 people there. Last night they had the same thing again and there were 60 people. So it's early days. No one has all the answers. I don't think anyone's suggesting that it's a fixed movement. We certainly don't have a manifesto or a style guide that says, you know, this is how you recognize it's DevOps, and it's got little stripes. That's not the case. Nothing's fixed in stone. I'm certainly not advocating a position that there's some sort of doctrinal approach that we need to take. And at the moment, for me, this is all about outreach. It's trying to get a message out about what DevOps is and about the community around DevOps. And you may notice a little footer on my thing, all opinions of my own, maybe subject to change without alcohol. It has been about discussion, about people going, well, DevOps is a bit of this. It's a bit of that. Let's see how this all fits together. For me, I like lists and DevOps for me is about four things. Simplicity, relationships, process and continuous improvement. And I'm going to talk a little bit about each of those areas and why they're sort of important to me and why I think they're an important part of DevOps and why they're useful to both operations and development communities. Firstly, simplicity. So we all work in, you know, if you work with IT, then IT is complex. You know, the simple things, some of the simple things, you know, that in an IT shop, you know, how you build your application stack, what particular operating system you choose can cause a massive amount of debate. I'm not even going to talk about things like if I sat down and said to you, well, then all the Maks people would be stoning me. And it's not an uncommon phenomenon in the IT world to have hugely complex applications linked together based on choices that you have to inherit from somewhere, legacy applications. And in order to manage those environments, simplicity is the key. So you need to choose things that are simple and easy to manage. Those things need to be repeatable and reusable. It's particularly in environments where you're managing thousands of hosts, you cannot do something that is a one-off thing anymore. You can no longer get away with saying, all of my systems are unique snowflakes and they're all different and they need a different set of rules. You simply do not have the bandwidth or the time to manage a thousand systems that you are considering to be unique snowflakes. And simplicity implies easy to communicate. Whatever message you need to communicate about your systems, whether it be their state, whether it be their configuration, whether it be, you know, how to recover them or back them up or secure them, it's basically something that's simple and easy to communicate. The key for me around this is that if you're sitting in the, at the end of the day, you're sitting in a room full of people trying to fix a bug or doing an outage, you want to have the best possible conversation with somebody where the end result is that you solve the problem as fast as possible and you solve the problem in such a way that it never reappears again. And if your environment isn't simple and repeatable, then you're going to have a lot of struggle with that. The next thing for me is relationships. So we all work in an industry that's well known for the fact that we're sort of supposedly misanthropic. We're supposedly this bastard operator from Helltypes. We've just had been types and we're the ones you pick up the phone and call them and you go, they're going to blame me for breaking something or the dev team is going to actually, you know, he's going to cry out and say, here's the guys that, you know, they can't install our latest version of the application and they'll hate us and, you know, we cause them all their problems. But every single thing that we do in the IT world is built around a relationship with other people. Too many of the conversations I've had over the years in IT have consisted of, you know, what I like to call the blame storm. So the blame storm is where, instead of ascertaining what the actual problem is, the first thing you do is work out who can I blame for the problem and how can I make sure it's not my fault? And there's a famous American phrase, cubby your ass, and that's an expression that gets quite used in enterprise IT shops. You're attempting to, rather than solve the problem, you're attempting to be the person that is not at fault. The only way to change that mentality, to change that conflict between teams is to build relationships. And there's a lot of reading you can do about how to build relationships and a lot of its touchy-feely stuff. I now work in America where everyone talks about their feelings all the time. I'm Australian, we don't. We just get drunk and hit things. But generally speaking, it's about engagement and it's about engaging early and often. So if you imagine the life cycle of a project, life cycle project consists of, you know, if you work in a business and the business says we would like to build a product or a service it's going to talk to a new bunch of customers. And the marketing team, you know, come up with a marketing message and the business comes up with all the things they want to do. They throw over a sort of, you know, maybe a few scratchings on a cocktail napkin that the marketing guys came up with between strippers and then handed over to a bunch of developers. And the developers go, we can't build this, it's impossible. That's their first reaction almost every time. They next go, okay, we can build this but it's going to look a bit like this. And then build the application, you know, there's a whole bunch of people sitting around and they go, this is really cool, we should use React here. That NoSQL stuff's really cool. And then someone says, oh wow, we better make sure that it runs on this and we better make sure it runs on the latest version of Ruby. And my God, we can use this really cool library I found and let's install all of these gems and vendor them in here. And all of a sudden, and I'm picking on Ruby people because I'm a Ruby person, but it's true of almost every environment. The next step that happens is that the team puts together this amazing demo and they demo it for the marketing people, the marketing people say we hate it. They hire a couple of UI people and fix that and then the application people say we're done. Hand it over, let's toss it over the fence. And the people are handed over to operations people. And the operations people take one look at it and go, oh my God, how are we going to make this work? It doesn't run on our standard operating system, it requires all these libraries we don't have. How do we back it up? Oh my God, it's syncing data between three data centers across four continents and how do we secure it? The application architecture is completely different from our existing application architecture. And they model through, they spend six weeks trying to work out all of the bits and pieces, they jury rig things, they write scripts, they build systems that, you know, especially we need systems to stick application, they run it up, first day goes under some load and it falls over. There's then, you know, we've all sat in that meeting where the system's fallen over, you know, there's 10,000 concurrent connections and the developers say it should support 10,000 concurrent connections. You guys haven't provisioned enough systems, you guys haven't worked out how to handle this problem. And everybody sits around and basically it's an exercise in trying to ascertain whose fault it was rather than fixing the problem and trying to ascertain, you know, how do we get here and how do we get out of the hole? The key to getting out of that hole is instead of right back at the very start where the business has a particular need, the business says we want to create something. The people they should have gone with are both developers and operations. And if those people are in the same room having that conversation, then all of these little things which are called, in IT world, non-functional requirements. So non-functional requirements are little things like security and backing things up. And they're equally as, ironically called non-functional, but equally as important to the process of building an application. So if we start from the beginning where both sides actually have a conversation, actually get involved and talk to one another, then we actually have an opportunity to develop applications and products where everybody gets what they want out of it. So how do we do that? To start to do that, both sides need to have détente. And my French accent is terrible. It sounds much better when you actually have a French accent. But détente is about both sides need to understand that they're all in the same problem. We're all in the same problem space. We all have the same issues we have to deal with. We all have the same, you know, the same bosses, the customers. We all work for the same people. We all get paid the same way. We need to actually get stuck into a conversation with one another where we actually don't let our prejudices sort of color the conversation. And you have to have that conversation. You can't send someone an email. I find the classic example of, you know, someone is wrong on the internet. And the reason someone is usually wrong on the internet is because someone has written an email and someone else has read the email and gone, ah, I interpret it like this, or I speak English as a second language and I've read this email in a particular way. Or I miss the smiley face, you suck at the end of that. And next thing you know, somebody is having a conversation that consists of we're actually aggressively pursuing a point rather than actually having a dialogue. And I can't underestimate you the number of times that I've solved simple problems of getting off my ass, walking halfway across the room, or getting onto a video conference and actually talking to the person involved. And building those relationships is a key part of any of the steps that we need to talk about and DevOps. So the next important thing for me is process. So I've spent about watching the IT industry change dramatically over the last sort of 20 years. When I first started, the one system we worked on was a massive big mainframe. Partitioned into production and development. There was a DRP mainframe. And there was pretty much, you know, we had a system and it did stuff. There was no client server. There were dumb terminals. I started to cut my teeth on 3470 green screens. That's changed dramatically. We went from a world where all of a sudden client server appeared. You were no longer managing one big system. You were managing thousands of small systems. You were giving them the time to realize and throw in the cloud if you're happy with the term the cloud. And all of a sudden individual sysadmins have gone from saying a 1 to 50 relationship with machines to a 1 to 5,000 relationship with machines. That's simply not scalable. I don't know how many hours people spend doing sysadmins stuff back in the day, but certainly these days you literally, I don't know a sysadmine who isn't overworked. I don't know a sysadmine in a big shop isn't constantly looking at new technologies, constantly having to look at new challenges, new products, and having to deal with projects in, you know, far more projects than that they used to handling. The only way to handle that is automate. I cannot under emphasize the importance of automation. The only way you're going to scale up to those environments is to actually manage to all of the things that you do should be done at the click of a button. The other thing is built-in redundancy and the expectation of failure. For me, the classic example of this is that the business comes long and they say we would want 99.999 availability and it needs to be redundant across all of our data centers and if anything goes wrong it needs to be up within an hour. That's whatever our SLA happens to be. And then they say, you know, we want this magnificent Rolls-Royce solution but here's a budget that buys you a Morris Minor. And that's something that we all have to deal with. So my assumption is that instead of starting from the position of let's build the best possible, let's build the most wonderful architectural world, let's make the assumption that let's build from a concept of this is going to fail at some point. So have the expectation of build around, build your process and your tools around the assumption that things are going to fail and you need to build redundancy around them. The key part of doing that is to test things. So don't do your testing at the last moment of your operation. Assume that at any point in time you should got to pull the plug and say this is broken, this is gone. What's happened? How do I resolve this problem? So the next, the key part of that is understanding that if this is in a failure state, how did it get there and how do I reverse it? So you have the processes and the automation to say, if it fails, this will automatically make it better again. The other thing, too, is that remember that process and the various processes and steps across both themes, both development and operations, is all part of the same life cycle. So all part of the experience of running an IT environment, it's not the, so if the development team is doing testing in their development environment, if they're deploying applications, then the overall, it's part of an overall life cycle that ends with that application going to production. So any process you build should be something that should be transparent and open to everybody. The key around that is tooling. And this is where the open source community has really come to the fore in the DevOps sort of scene. And the reason that it's so prevalent in the open source community is that there are tools like Puppet and CF Engine and Chef in the configuration management space, Control Tier, Rundeck, M Collective, monitoring tools, security, testing, a number of people I think believe Lindsey Holmwood who came up with Cucumber Nagios, talked to you last year about that. These are all perceived as ops tools. And the reason that I put the option to question mark is that the value you get from having these tools is not limited to operations teams. Development teams have a key stake in building these tools. And the important part, for example, that we cite as an example of why use Puppet is that an application developer can build a Puppet manifest or a Chef cookbook or a CF Engine recipe, and they can actually deliver that recipe from life cycle to its end. So they've cut their code, they've built their associated Puppet module or their Chef cookbook, and it ships all the way through the life cycle. So it gets the application development team, hand that over to a testing team, hand that over to a production operations team, who actually implement that live. And it means that you actually have that co operation, have those things like, you know, we are building the infrastructure, we're building this is how the DNS looks, this is how the backups work, this is how you secure things all the way through that life cycle. Deployment and orchestration, you know, application teams, particularly, for example, big Java shops, there's a very clear way they like to deploy and orchestrate applications. There's an important opportunity for developers and operations people to work together with those tools and actually understand what the particular requirements the development team has and what the requirements the operation team have and why those are important. The other thing is things like monitoring and testing is they're not they're not solely limited to to one group or another. So the sort of data that you make available with your monitoring environment is a key piece of data that most of your application developers need to understand troubleshoot problems. So if you actually go and ask them questions about what they want to monitor, what they want to see, then result is something that you can both work with and both use. So excuse me. The other piece of this is the lots of things developers do that are useful to operations people. So smart sysadmins for a long time have been version controlling things, you know, everything ranging from DNS configurations to to whatever happens to be that changes state you want to keep track of. The last couple of years you've seen lots more operations people understand tools like git and bizarre. And the reason they've done that is because there's some useful things developers do about branching about the way that you can actually actually have multiple people collaborate on tools and will collaborate on configuration and collaboration on code that's useful to both operations people. Following from that, there's also two things like agile and XP. And concepts like continuous deployment that have emerged out of the development community that are useful things for operations people to know as well. That's not to say that those those concepts are perfect. Not to say those concepts are things that you should immediately adopt in your operations team. John Allspar from who was at Flickr and is now at Etsy talks about a number of times about how it's how Flickr used to deploy into production 10 times a day. Now, a lot of people look at that and go, those WebOps guys are fucking nuts. There's no way a stable environment is going to it's going to be healthy if you deploy 10 times a day into that environment. That may not suit your your your particular environment, but the ability to say go from having a six week deployment cycle and there's a number of banks and financial institutions and insurance companies that literally go weeks and weeks between deployments because they the processes of deploying an application is so complex, so risky and has such a potential to to cause disaster that that they they're incredibly cautious and risk averse. There's a lot of concepts that come out of that agile and continuous deployment things that can be adopted to cut down that time period. Application architecture and orchestration operations people are classically bad at documentation. I think that the you know that the the the only time the network diagram tends to be up to date is usually after the post mortem for for an outage. There's a lot to be said for for the way applications people build architecture the way that they document architecture that operations people can learn a lot from. Another thing is testing methodology. So operations people this is something that that's new to a lot of operations people a concept of for most operations people the concept of testing things is monitoring. So is the is the SMTP port open? Is the DNS service running? You know can can I you know what's the load on this particular machine? Applications people think about testing in a whole different way. They think about testing in terms of is the application functional? Does the does the result that I input you know run through this method and output does that result mean something? And a lot of what someone like Lindsay Homm what has to say for example about Cucumber Nagios is about understanding that that testing things like is the SMTP service running is not that important. And the reason it's not important is because it doesn't tell you anything about the function of the application doesn't tell you anything about what the business failure of that application does. The SMTP court can be open but if it's not sending email and that email is not shaped the right way whatever like latest marketing blast that Oracle is sending out to everybody if it's not shaped that way then the service is valueless. So you need to take your testing up to another layer which is test the business functionality. So from from an operations perspective you can learn the lesson or lessons that application developers have which is that you test the function and you return the result that you expect the customer to see. And in the process of testing that function in order to you know send a message by the SMTP. Wow the SMTP port has to be open. So you actually get all of the base level reporting and I'm not saying you certainly turn off the monitoring but all of the base level reporting you get that as well but you also get to understand that what the customer is expecting to see what the application is supposed to deliver actually gets delivered. The last piece I'll talk about is continuous improvement. So in the IT industry as before we all have customers. The business is our customer you know the doesn't matter what sort of organization work in you have somebody who consumes the result of what you produce. Those people don't stop asking for things. You know the when I first started out as a CIS admin you know I think we fixed a couple of problems and I was really chuffed I was really pleased. Now I fixed this problem it's awesome you know the customers have been complaining for months that this thing didn't do what they thought it was doing you know it was generating a report and they wanted the report by you know 7 30 in the morning instead of 8 o'clock and I was really chuffed they did a bit of fiddling around and I you know the report generated you know tweaks and SQL and the report generated much faster and I sat back and I went I can have a cup of coffee and a cigarette you know I've done a really good job and I about nine o'clock I got an email going yeah we've got the report it looks like this but now we want it at 7 because we've actually ascertained that you know it would be really useful if this particular operations team in this time zone had it and I'm like fuck you guys where's my thanks where's my you know you did a really good job you know where's my part in the back it never comes because customers never happy with the end result they want the next best thing and fair enough to you because they pay your salary and you work for them and I get a lot of I get a lot stick for this because I'm a firm believer in saying that that we all deliver a service and the people that pay for that service in title to get a decent service out of us obviously if they pay like crap then you know that's a whole different thing but but those customers don't stand still they have requirements that keep changing keep that you cannot sit back and and go wow we've done something really cool here that's the last time we have to worry about this because they will come back next week and say well you've delivered me this I'd like a little piece more products don't stand still either so businesses change you know the organizations like banks I spent a lot of time working banks 20 years ago the concept of online banking completely non-existent now nowadays ask most customers to say you know right with the exception notable exception of the United States writing a check is a foreign concept to most banking customers as a result things become far more complex that don't stand still and you need to keep on top of delivering things that that I knew that are changed and that that that have unexpected sets of requirements technology doesn't definitely doesn't stand still either you have things like virtualization have come up come for a rude shock to a lot of shops you know or cis admins have gone from saying you know we can manage a 50 systems like this to managing that five thousand system model and your team doesn't stand still either people get bored and there's nothing worse than it than a bunch of people who are who are bored and disinterested by their jobs if you provide people with the right sort of challenges the rights sort of sort of things to learn then then you can you move forward quite rapidly and you able to if you're able to prove improve on things move forward and look at things in that sort of continuous improvement light then it then it's a it's an opportunity for both people to learn and and people to develop the strike off and strike hard and be aggressive is that you can't sit still in an environment like this you can't sit still wait for things to happen to you so the continuous improvement piece needs to be you know think about what would go wrong here think about the failure trying to resolve think about the issues you need to deal with and deal with those first the more problems you solve up front the more time you spend putting into making things better is the letter is that and my boss Luke can ease as a phrase the faster you get to the pub and I'm a firm believer that if you if you if you address things aggressively and quickly and and actually think about the problems first you're able to get to the pub much faster the big thing about about DevOps for me is that it's a cultural change it's not a it's not a series of technologies and tools and processes alone and cultural change is hard people don't like thinking about things differently they don't like looking at things in a new way the not invented here syndrome is very strong in a lot of organizations people hate change even little changes people don't like little changes in their life we like routine we like things to be normal we like things to be consistent and as a result when you make change people don't like you so I've worked in a lot of environments where we're introducing changes like DevOps where we know that the coordination between teams that the the first thing that comes out is the why do I have to talk to him that's the guy that wrote that code that really sucked and I have got woke up at four o'clock in the morning with a pager and as a result you know people will respond to you in a fairly aggressive way when you make changes like that that fear of change is largely irrational it's largely a you know I don't know where this is leading I'm largely I'm going to be concerned about I'm concerned about my future where this is leading what happens to me the best way to deal with that fear of change is to listen to people actually have a conversation with them about what's what they're worried about what's going on provide concrete examples of how things help how things change I think the the classic example for a lot of people is is is presenting to them this is that this solution will actually result in improved availability will result in a better better SLA actually demonstrate how the change of work of them I think is you can't just stand up and say make pronouncements so as a you have to actually be in the guts of things actually to be solving problems actually part of the problem part of the solution rather than problem the worst thing in the world for for any IT shop you know the classic example is is the is the development team who don't get woken up before a clock in the morning who are who are able to come in at 10 o'clock or whatever happens to be and and they get that they see the ticket they go you know something's broken oh well where's development team have been awake for last five the operation team of the wake for last five hours trying to resolve that issue if you want to make things like culture change that's the space give developers pages make them on call make them responsible for service levels and availability that they wouldn't otherwise be so I also wanted to talk a little bit about some of the responses to the DevOps movement and I'm very fond of the classic danger will Robinson with Robbie the robot talking about talking about what are you know some whatever unknown dangers around it's also my favorite Thomas Paine quote when we're planning for posterity we ought to remember that virtue is not hereditary so when I first started out in the IT industry the guys who taught me about IT ops were all in their fifties that all come from that mainframe world they were very serious guys who were like availability is the key big iron is the only way to do it and the virtues they taught have not passed on there's a lot of people who come from coming to the operations and development world with a very a very different perception of how availability how operations works you need to actually actually provide that that concrete that concrete set of planning in order for people to continue to understand can you understand what's important so some of the classic responses to DevOps that have been is good systems she said means have been doing this since they came down from the trees and for me this is really this is really something that that that I look at and feel a bit horror there was a very small percentage of the system in community and the development community who look at this stuff and go we've always done this and those people sort of go shrug as a result of that I'm not going to make any changes outside of my world so that other part that they completely ignore that 85% of the community that has no idea that there are better way of doing things no idea to that automation will make you free that that that there are ways of different ways of looking at things the next response is that that you know my organization is different that can't work here and that as I said earlier that whole unique snowflake world that's gone there's no there's no way that you can look at an environment and say we're going to manage everything differently we're going to be different from everyone else that that that thinking is is is something that that will become you know it comes from that whole bastard operate from hell view of the world and that that's no longer something that's feasible in a modern environment the next one is it's all about one particular group or the other so I concentrate on operations that's the area that I work in and the response here is that that operations people are going to have to become like developers the developer where espousing that development methodology is is the key for the way forward and for me that's that's that's simply simply not true the thing for us is that when both sides need to learn from one another so for us to me it's understand that both sides need to actually collaborate both sides that can learn from one another and yes someone actually posted you're a bunch of elitist European wankers which I was a bit horrified by because I'd love an EU passport and I didn't have one so the other danger is that that where DevOps ends up and for me that the as I said earlier there's there's been a couple of products that have said they're DevOps certified that the new the new hotness is DevOps and therefore you know my product does DevOps I've also seen Forrester and Gartner both have DevOps events I know speaking to Patrick and Chris neither of them were invited to that and it's always fascinating when analysts some of you may understand the analysts markets very soft-serving the analysts get a question from customers saying I've heard about this DevOps things what's it all about and they all go around to ask other questions of there are the customers and they feed the result back and it becomes a self-fulfilling loop the key thing for me is that around around DevOps and understanding how how to avoid that for DevOps is to make it more than marketing speak so actually put this thing stuff in practice in organizations to actually solve problems using DevOps concepts to solve problems by actually making operations and and develop work better together other thing is it's very easy to pay lip service to this it's very easy to say we're going to have a role called a DevOps person and we're going to have a DevOps team it's not a role it's not it's not a thing you can build a team around it's about a different way of looking at it and it operations it's also a concept that's very easy to cause disenchantment amongst people mostly because people are uncertain about those changes they're uncertain about how how the world will will will change for them in in that sort of doubts environment it's very easy for people to lose faith in the organization that they work for because they don't feel that they're going to get anything out of this and that whole disenfranchisement of people is something that that that I think every organization struggles with and it's something that that that I think DevOps has a real opportunity to change that that frustrated mentality a lot of CIS admins have and the frustrated mentalities a lot of dev developers have dealing with those CIS admins and that that change is around is around that whole learning understanding from each other and understanding what's what's what's going on I've I've found the last few years that I spend a lot of time cutting code where I didn't used to I used to spend a lot of time writing writing batch scripts I now find myself cutting Ruby code learning things learning new things and I get a lot of a lot more pleasure out of my role than I did previously and the last one anti-disestablimitarianism I just wanted to put in because I like anti-disestablimitarianism so I think I've I've spoken very quickly and I think rather poorly unfortunately but I did want to ask if anyone had any questions before we go on okay when you when you look at the role of development and operations in your environments what are some of the tangible things that change about their roles like I like I know for agile principles for example I mean things like between agile and testing tend to blur the lines what about in DevOps does it change the relate how does it change some of the activities does it blur some of the lines between development and operations so I think classically the whole I think configuration management is the prime example there so that the we used to spend a lot of time doing things like creating users installing packages managing services monitoring things those are not cool things those are boring tasks the thing about that the DevOps allows is to say let's take all that stuff let's make it automated let's make it something that we don't have to worry about because the really cool thing I'd like to do is learning how to scale this particular application or I'd like to learn how the new no SQL stuff that the developers have introduced works I think the tangible outcome for a lot of organizations is that you get away with saying that all the boring shit the stuff that has occupied your time fixing things installing things changing basic configuration things that is fairly sort of boring and monotonous you can actually work on the projects that are actually interesting the other thing is that being for a lot of organizations having that conversation with development teams means that you're actually in the guts of the development process that's far for me is a far more interesting activity than sitting around being an operator and watching watching the you know the the meters and running if you run a whole bunch of people through through and for example we have I have a couple of organizations we've worked for that have embedded operations people into the developers scrum right they can't necessarily cut the same code but they're part of the actual development the application by the time the application gets to production those guys are like this is really cool and they become evangelists for the for the applications developed not only do they they understand the application better they understand the metrics and the basic concept the developers put into the the thing but they actually care about it and I think that's a really important I've seen too many applications to get thrown over the fence and you go I don't really understand what this does you know I don't understand why it breaks all the time I don't understand why it performs like shit but if you're actually involved from day one you can go well then we made a compromise here we actually decided to do it why are it like this instead of this because of this particular reason and you go we can make a better like this this this but here's the the caveats we had I think a lot of that sort of knowledge is not you know that sort of that sort of knowledge is not something that gets passed on otherwise when will your big and explicit book about puppet will be finished finally so I'm continuously jet lagged and that that that question has been asked 17 times and the since I landed on Belgian soil March or April maybe no unfortunately yeah I think I I spent about 20 our days at the moment and it's almost done almost two chapters left and I had the help of a very good colleague who is pushing along so hello obviously one of the keys behind DevOps is a better collaboration between the development and the IT operations guys coming from the IT operations field yourself what would you expect from a development team in order for you to relate better to it what could the developers do to ease your way towards this collaboration so I talked about embedding operations people into scrum and or into your can ban or whatever developers do do it the other way around as well so drag development people into into incidents and outages bring them if you have an operation stand up drag the developers in make them understand the sort of problems you have a lot of developers are operating the principle that we've we've built something it's really cool it's really hot and then we piss off down the pub and the operations people have to manage it if they actually understand that the there are implications and consequences to their choices that if they choose a particular application architecture it is going to it's going to have an impact on the operations team at the end of the day the number of developers I have a conversation with who go oh oh you didn't tell us that that you you don't do things like this or it's hard to package this or we this set of Java libraries like this if you actually have teams involved on both sides from day one of a project there's a far greater appreciation for for how that works developers also stuff like developers are like you have a particular operations problem we spend to be fairly metric centric people operations people we we're interested in metrics we're interested in measuring things developers are also interested in that sort of thing and they also have a set of things they'd like to know when something goes wrong something's performance performing badly they have that that desire for that information if you have a conversation with the developer that says let me tell you about the metrics I have you can tell me about how your application is instrumented and then I can tell you how I what I'd like to have added to that instrumentation you can tell me what data you'd like from my end those sort of conversations are really powerful and I found that a lot of a lot of developers are sort of stunned by the by the I guess the the depth to which operations people use metrics and and and they're sort of have underappreciated our our perception of that so this I guess there's some there's some conversations around that that sort of really healthy and and promote that sort of cooperation so this sounds really interesting and it sounds like what we did actually what I've done actually in some of the companies I've worked and it's it works really well but does it first does this really scale it also does this scale to bigger team and the bigger teams of operations and development people because that's one of the main problems when the team become big enough it's really hard for them to mangle and the other thing is mostly if you've done this but I have this very weird observation that development people think for example that CPU memory and hard drives are infinite and most of their resources are infinite and this is one of the main issues with working with deploying their software so if you've managed to teach anyone that that's not exactly right I think the challenge of and I certainly you can see a lot of pushback around DevOps and the fact that it works best in small teams for example you know people say it's much easier to do this if you haven't got you're not an enterprise and you haven't got 500 people I think that's it's true you it's easy to have relationships in small teams I think the the larger teams you do things like you move whole groups of people through through through different teams and different organizations you shuffle people around you keep you keep people actually actually learning new things you don't you don't silo things I think that the key mistake people make is you build silos you build a a group of people who are all the Java developers and you build another group of people that are all of the the web ops people and then you build another to that that is a not only an unhealthy way of building teams but it's a way that that doesn't promote that sort of cooperation and coordination he's cancelled his question hi I have a quick question over here when would be the exact perfect time to be to start doing DevOps when you're doing a startup when you're doing a beginning of a startup and you found it yourself you don't have that much capital I can't see why for example a whole bunch of things are useful but the whole configuration management and all that might just be a drag in the beginning because you really need to move quick quickly forward in order to get capital and first clients and angel and whatever so how would you approach that one so I think I think greenfields greenfields is far easier so if you have a greenfields environment it's far easier to introduce new concepts people don't have that it's not invented here or we've always done it this way mentality in a greenfields sort of environment I think though there are real advantages to looking at something like DevOps DevOps in legacy environments so legacy environments you know we've all got them we've all got you know lots of organizations have have you know their collection of rel4 machines that have been living there forever and they can't change or upgrade them they're a bunch of of windows and T machines that they've ring fenced off from the rest of the environment those things cost lots of money to maintain because they're they're all sort of that they've become sort of boutique or no one wants to change anything there's real opportunities in that sort of environment to actually to actually sort of if you automate stuff in those environments to save a lot of money and to become a lot more efficient but it's a lot harder to do because making those changes tend to be systems like that tend to be sort of very fossilized they tend to be sort of things that that have the organization has become risk adverse about we can't change that no one the no one who works here understand how that works anymore but as a result the opportunities there are quite large but the risks are quite high but green fields is certainly easy if you're a startup from day one if you if it's the classic example is is agile if you start from day one using agile it's far easier to go from a legacy development process to an agile then going from a legacy to an agile process if you start from scratch there I think that was enough do you have a guarantee I'm in operation myself and in here we are in this not uncommon situation where all the applications are almost all we all the applications that we are deploying we are not developed in-house so is DevOps still relevant and how do you trigger this cultural change about automating things because we can only automate some baseline basic things like SSH configuration VM provisioning and very basic stuff all the rest is too diverse and too complex to automate to do automatic deployment so I'm I deal a lot with customers that about source stuff to India and China and it's really interesting outsourcing in a lot of cases gets it's a very bad name you know that people are it's the lowest bidder who's outsourced you've outsourced your stuff too and they have no interest in quality or changing things I think it's that's the wrong attitude to take the opportunity is there for you to infect those organizations if they understand and there's a couple of people here I know there's at least one person here from India who works in a big Indian IT company who actually can tell you that those guys are interested in learning new things they want to work on cool technology and if you have an opportunity to infect them with a whole different idea about how to do things I think those things will be picked up and there's big cultural barriers in any outsourcing arrangement but I think those are also opportunities and it's also about demonstrating value so if you can demonstrate that it's we cheaper for the organization to do it a particular way then they're going to jump on that because they want to deliver the service and make it be a profit I mean if you can deliver you get something out of that you get better availability you get a better quality service you get a better SLA and they get to do it cheaper or faster or whatever it is it's a win-win situation for both organizations Hi I luckily started two weeks ago and I'm responsible for implementing application monitoring in a quite very big corporate Belgian environment which already says a lot for people to know about that and I'm facing the fact that the operation people have a solar system to be able to participate in that but on the other hand they're saying don't flood us with all your application level events and all the business process metrics that you would like to see on the dashboard for the business do you have any comment on that or do you just want to show some empathy So I'm not sure I understood the question toilet totally but I think again it's about it's about demonstrating what what so if you demonstrate that that that was a question was the question if I find paraphrase you've got they're not interested in looking at the business metrics they're not interested in looking at the application metrics was that well the developers and the business are but the iOS people they want to limit the number of events that will go through their monitoring systems so what I'm trying to promote is to help them changing their mind in such a way that they accept that monitoring should go a bit higher level I think it is about that demonstrating the value of it so demonstrating that that that it's that monitoring the CPU the memory and the disk is not what's important about the application what's important about the application is what business results it delivers still want to know about the other stuff but if all of those those metrics are perfect of all of those dashboards are perfect but the response time over here and the application doesn't do what it's supposed to do then it's not working so then you need to demonstrate that if they have an under picture of that then necessarily be the same metrics that all the dashboards and the business people look at but a view of that and how it links to those other metrics that they care about infrastructure metrics that's a way that you can say this is the picture your customers get this is the picture that they're seeing and they pay your salaries they pay all of us and we have to work together and solve in that particular problem or give that particular view I think it's probably I think there's time for one more question any more questions here thanks very much