Introduction to DevOps for Leaders and Managers

[Music] I'm Robert Bobbitt I'm the vice president of sales and marketing with the F P complete and I want to thank you all for coming out here today and I know it's the day after the fourth holiday so not sure that was a good strategy or not having it today after that kind of split the room split on that but we have the we have a good lineup today I'm going to have John come up here in a moment he co-sponsored this event with mine centric and John will explain you know have the relationship between our two companies and of course our guest speaker Aaron contourer will be up after that and hopefully by that time the food will be out in front of you you can just sit back and relax and listen to the conversation so and they'll be Q&A after yeah the agenda is pretty simple we're we're just doing a short introduction for mine centric Aaron will be doing the conversation and I encourage you of course to stay afterwards and you know talk with there and ask questions about what we spoke about today so John you want to kick it off here all right thank you everyone for coming I'm just gonna take a few minutes to introduce our company quick show of hands how many people are actually in a DevOps role or in DevOps management sort of well great I wanted to share with you a real quick story that's kind of fitting to the topic went on a ski trip with my kids and there was four families there two of the families I didn't know and we're in the basement shooting pool with one of the guys and we started talking I'm like so what do you do for a living he goes oh I'm in DevOps I'm like interesting I go how'd you get into that role he goes well somebody said if I wanted to advance my career in software I should get into DevOps and he said well how's it going he goes well tell you in a few weeks because we're migrating everything to AWS and he goes I have been sleeping it all but it's been very stressful and I said well have you had any experience doing that type of things like no but we're along the way and I said well what if you had resources or a company that had actual experience and doing that and lived and breathed that every day feels would that be useful - he goes well yeah that'd be great well that's what my company does you know so I didn't even know people like you exist so a month later I'm at this charity thing for our school and I said hey how did your migration go he goes well get a beer let's go talk about it he said we cut over on Friday everything's going good Monday afternoon everything just stops running he's like I think I just killed our company I think I killed my career so they all buckled down and then a few hours they got things back and Ronnie but it took them about a week everybody working 24/7 to get things back running again and eventually he did and he goes the whole time I was thinking about you and because I wish I would have had some help through this process so we're here to kind of talk that's what we're kind of here to talk about what we what we talk about on this this slide here is we want to enable the devs ops and dev out managers to take ownership of their projects and what we're here to do is give you guys resources to fill voids where you have in your companies and be a resource to you so that a lot of this stuff may be new because when you're in the DevOps role you're typically coming from one side and not everybody's going to know everything about all these things so we're trying to be that resource to you and again you own that relationship you manage it what mine centric does is we're doing operational tasks we manage things we've since 99 we've been managing infrastructure and data centers and supporting applications all of our customers own their application and run that and we fill those voids for them then we're working with FP complete they're very complementary to what we do because they automate that process they help you push the code out and there's a lot of synergies and how we all flow together so that that's where we want to bring this together for you as as an organization and bring those resources to mind real quickly so we kind of talk about we're gonna be talking about just real quickly what we do in the services thing area we also we're also a cloud provider we own and operate all of our infrastructure out of the super nap facility and switch we're also partners with AWS in Azure so we integrate we merge we do hybrid clouds and then and we've been doing that since 99 we've been doing office for the last five years just out of customer demand we kind of try to stay away from that and that's really how we differentiate ourselves because a lot of people think of IT services as kind of a desktop company and and we're just the opposite we avoided that for a long time and now with the convergence of the clouds kind of made sense for us to adopt that I know there's a lot of words here but just want to highlight a few things we've been in business since 99 we were a software development firm back when we started and we got into managed services out of our customers wanting us to manage things and over time we just kind of evolved into that business but I mentioned that because we've got that software background and we've developed our own what we call our own tool box that does a lot of monitoring and automation from the management side and we built those tools understanding how to help support applications from a management standpoint then we've got 10 years plus of experience running virtualization and cloud we've done hundreds of migrations physical to virtual in and out of clouds I can mention we're an owner-operator and this is kind of what we're here to talk about is where's your where's your core business and I like to use the term core versus chore I teach ORS are things that you can look at outsourcing and getting help on we want our customers to focus on their core business because that's what makes you money the more effort you can put into that developing apps features and functions that generate revenue for you and if you can outsource operation things then that can make you a lot more efficient and I highlighted this down here in red because what we do when we a lot of times companies think well I gotta do everything we scope our services so we can help you as much or as little as needed so it could be small little tasks that needs like help with architecture or security compliance and then we scope everything to your needs so we we tried to just fit where it makes sense with your existing staff with your budget and your needs and help you focus as much of that on your core business as possible that's just it in a nutshell I think it's over oh this this is just a really quick slide of talking about different verticals we do some things of how we've helped companies one day we were sitting around talking about all of our customers that have been acquired and we started adding it up in a total over a billion dollars in acquisitions that our customers have experienced and this kind of focuses on a few highlights so the red is the company that did the acquiring the Green was our customer who we helped go through that acquisition and it's kind of a fun little fact that we're kind of proud of but that's all I have and I'll turn it over to Erin just take a quick second here so and you can contact John here I will be making a copy of this presentation available to everybody so no fear they're just quick introduction for Erin Erin started FP complete about five years ago F P stands for functional programming which if you're not familiar with that phrase it's just a what we call the next generation of programming Erin basically started the company because quite frankly is frustrated watching everybody do things in a really inefficient way and that's really what this whole DevOps conversation is about how do we do things a lot more efficiently and what kind of changes do we need to make to move in that direction so as you'll see Erin will talk a lot about his some of his experience he worked with some big companies you all know Microsoft and Bill Gates erin has work for them as a senior technology advisor and has a lot of interesting observations about DevOps and what what that can bring to the table so Erin thanks about which is yours okay thanks Martin thanks to the folks at mine centric or co-hosting and also tip of the hat to whoops is my mic on oh it's only to the camera okay well then I'll speak a little bit louder thanks for the heads up thanks to my centric for jointly hosting today also tip that to my colleague Steve Bogdan who's here and I point him out because my goal here you know is to give a relatively short presentation and to hopefully have some of you think this could be the beginning of a conversation because DevOps represents really the future of where operations of software and applications is going and so maybe a few of us will end up working together obviously our company FP complete offers services around DevOps and other types of advanced engineering things in a collaborative way so hopefully today's talk is is interesting enough that that there's some questions after and that some people want to have another conversation another day and in the meantime hopefully it's at least as interesting as the beer and food so with DevOps we do love these diagrams we do love to talk about how things overlap and connect and this is another way of breaking into three parts what it is that I think we're all trying to do we're all trying to deliver with IT all kinds of new features to our users that let them get their work done quicker and sometimes soon and we're never done because whatever we do for our users they want more so in IT we're looking for a lot of productivity we have a lot of customers there's always a backlog and we actually use often the word backlog to describe our to-do list that's how a custom we are to being backed up with demands that need to be met but we're also looking for quality we're also trying to deliver solutions that actually work that don't crash on Monday afternoon and make you think your careers in jeopardy because it's not good enough to have something that runs 90% of the time and then either crashes or loses user data or that can't be shipped because it never even passed its own tests so how do you merge productivity and quality in IT that's a hard problem and it's gets even harder when the demands go up and people say well I want performance I want throughput I want a system that's gonna scale up as my business grows so don't use some tool that's going to build me a bad piece of software that's gonna work today but it's not gonna work tomorrow so the constraints on us as IT and technology people in general are very very strong and I would suggest that that it needs help and that's why we're gonna talk about DevOps today just a moment about me just so you can decide if I'm qualified to talk about this law obviously like gray hair been doing this for a long time I was one of the designers of the distributed systems and networking stuff that's inside of Windows and inside of Microsoft Exchange I was the architect of the server side of MSN Microsoft's family of online services when it first launched onto the Internet so I designed the sort of how their data centers would be structured from a software point of view I served for a while as Bill Gates a senior technology adviser when he was CEO of Microsoft back when computers were a little bit smaller and was a little bit harder to get them to do things I've gone on to run what was at the time the world's leading software development tool visual C++ in Visual Studio where I was one of the general managers of Microsoft's overall developer tools division and then I built and ran Microsoft's in-house sort of secret weapons team called the productivity tools team that was all about how do we get our work done more productively through better technology and the theme you'll see and my talk today is this isn't a talk about we should all stay at work longer this is a talk about if we use better methods and better technology our work is actually going to be successful and that's what I've done for my career for a long time I went on to be CTO of various startups most recently a local firm here that does secure election services called everyone counts and in 2012 a certain FD completa as Robert described to try to advance the state of the art in how we're all doing our software related and IT projects so how are we doing well if we stop and notice I'm gonna suggest we're doing fairly poor as an industry not just any specific person there's something wrong with how we're doing software and IT everybody feels like a Homer Simpson here it's frustrating doing IT right and it's even more frustrating to our users who can't understand why we can't get them the features they want or why it won't work reliably and securely and meet their needs and they're not really interested anymore in hearing our tales of heroics when we say I was here till midnight making the server work the right answer anymore isn't oh thank you you know for working so hard it's well what's wrong with you why can't you make RIT so that it isn't like that anymore right if the guy who built your house said I was here till midnight fixing the leaky pipes you wouldn't say good job thanks for working so hard you'd say come up with a better way to make pipes so we've got to get out of this mode of constant fire drills and coping and figure out a way to get our information technology back to actually doing things for our organizations the reason we've been coping for far too long is that our our technology is not caught up to how the world really works and in particular software is not designed for how modern servers and networks and production environments really work if you look at how software has made whether you got it from somebody else or you're making it yourself in-house we often make software on very small computers and then at the very end when it all seems to be working we say oh by the way there's this completely different environment where we actually run our company so we'll just copy the software over there and it's gonna work right and well it doesn't it doesn't work and so we have all kinds of failures I like to use the word reproducibility from the life sciences and healthcare industry right if you have something not reproducible it means you can't prove that it's going to work because every time you do it it's different and done by hand but we have ear reproducible servers because somebody really smart probably somebody in this room or somebody who works for somebody in this room is waving their magic wand to somehow get the apps to work the complicated networks of computers and other devices that are our production systems they don't work and depending on who typed the command they might have typed it differently something as different one day I was just over at the global air show in Paris there's an amazing aircraft called the a400m it's a four engine military craft and it has computers in every engine and one of them recently fell out of the sky and killed everybody because the guy who deployed the software update on to the engines did it by hand and he forgot a command that one day and so the config files that tell the engine how much gas it needs were missing and so the engines all idled in the middle of the flight and couldn't be convinced that they didn't have enough gas so the plane turned its own engines off and fell from the sky that sort of problem happens because there's no reproducible system for putting software from our dev environment on to our production systems unfortunately those production systems were inside of engines and not just at a place where we could all go get a coffee while somebody fix this it but we can't all get a coffee while somebody fixes our company if everything does go down on a Monday afternoon you can't get it back up it's not interesting anymore to say well we worked hard and we tried our technology doesn't work and we've been coping for too long but I'm gonna suggest that since our industry isn't dead at this point somebody must have solved this problem how is it that the internet keeps moving forward and software as a service keeps moving forward and software products keep coming out there's every reason to believe that somebody must not have there built their their business falling from the sky the way that airplane did somebody must have figured out the problems with IT and how can we learn from that well I'm gonna Sherlock Holmes this up and show you some data and just let you read this slide to yourself for a second did you get to the bottom there's something going on right I don't have to be too big a genius to say that right about here at software-as-a-service startup there's a dividing line and there's a generation of companies that have figured something out about how to deploy software where they can put new software into production whenever they want and they're very successful companies and then there's sort of all the rest of us putting software into production at very long intervals so evidently these people have technology that these people haven't yet got their hands on or put into production what is that technology that technology is DevOps and I'm here today to really say if we can adopt those better tools we're going to be ok in fact we're gonna do very well indeed and the reason is when you put new tools into production your whole industry your whole enterprise changes think of a factory that makes something out of wood maybe chairs and this is the tool that they have this is what a lot of our work is like today we have very smart very skilled people we give them the sharpest saw in the toolbox and we say you use your skills and you're gonna make a great piece of furniture that's true that's true but not a lot of furniture is gonna come out and that person better be pretty darn smart also the chairs are probably all going to look different from one another a modern tool doesn't look like that it looks at least like a power tool that has some settings and some gears in it and if you set this saw to the right angle and you pull down in that handle you're gonna get a reliable cut of wood the same time every time that's a tool from the 1970s but a really modern tool looks like this a computerized cutting machine where you program in what you want and what you'll see on a tool like this is it's fast it can do things as many times as you want and it never makes a mistake and that it builds in the process of cutting the other thing you'll see in a tool like this is the actual part that does the cutting is almost all of this tool there it is on this tool it's a couple of pixels the part that does the cutting is the easy part we as a civilization solve the problem of how to cut a piece of wood some time ago the hard problem is directing that cutting to where you want it to and the same as you'll see it a couple minutes is true with software we know how to write applications programming isn't that hard anymore it's getting them to work at the right place the right time the right way that's hard and that's what DevOps is about so you can't just try harder all you'll do is cut more pieces of wood we need to try better as you saw in the very first slide today from mine Centrex we believe that DevOps is about combining the creation of new capabilities developing apps building whatever IT systems you want to build with some kind of integration thing I've called deployment in here so that the software ends up in an operating environment ready to operate every day so DevOps is about turning IT into a factory a productive automated factory that can move new capabilities from a developer's desk or from wherever you got the new software all the way over to your production environment how do we do that the same as we do with a cutting table by taking that little that little nugget of goodness which for us is the application and surrounding it with much more automation and much more technology so we're not going to read this slide but this is how much more technology I'm talking about in this diagram which is a typical FP complete DevOps deployment where does the app live it's inside this box and the source code is inside this box everything else in this whole picture is DevOps this is all about surrounding an application with infrastructure that allows it to be built and deployed and operated successfully we're not going to walk through this diagram of the all got copies of it but obviously there's a lot of very specific tools that we would use in a typical deployment this is a this is a Linux and open-source version of the deployment where are all these tools coming from is this going to be super hard now no it's not in fact with with thanks to growth point this is a diagram of some of the companies that are producing DevOps tools right now there is an abundance of great tools now for doing DevOps company after company agrees that this is a crucial problem area that we need to work on our belief @fp complete is that it's our job to be experts at this technology and then to partner with other companies that have their own in-house IT capability but they don't want to have to figure this all out from scratch that's why we exist as a company as a boutique engineering firm our role to some degree is technology transfer to come in and say let's get you set up on a better way of doing things that will allow your whole team to go forward more productively so it's our job to know about these things but my point in showing you this slide is really to say there is an abundance of great tools and DevOps there's a reason why those companies at the bottom of my previous slide can get apps deployed every few seconds and that software is available to all of us to automate how we deploy new applications and solutions on to our production data centers and servers what are we trying to automate when I say we're automating a few different things first we can completely automate with private clouds or public clouds the creation of infrastructure the day is gone when you should have to figure out how many servers you're going to need and what type of devices you're going to need and how much storage and networking capacity cloud with virtual machines and so on gives us the ability to automate that but automating isn't the same thing as having a command line available to you automating is using modern DevOps tools to declare what your application needs and have a script run whenever you need more servers so that you can or whatever infrastructure need routers you name it VP sees virtual private clouds so we want to automate the creation of IT infrastructure that's called infrastructure as code a script or declarative statement about what you need should be able to run hook up with your cloud provider and automatically bring up the resources your application needs that's an important part of DevOps we also want to automate the building of software some of you familiar with the term continuous integration that means having a system that's online than running all the time that will bring in new source code whenever you or someone in your company modifies it with approval build a new version of the software automatically tested and ought to make it automatically make it available for the employment on two new machines containerization is a technology you're going to hear a lot about a lot about of the next few years if you're not already using containerization there's a good chance you will be containerization is a technology for grouping together applications and the other files that they depend on and creating an identical configuration with all those files that looks the same on the developers desktop on the test machine and on the production machine so continuous integration in its more advanced sense is about having a server that automatically builds new versions of your apps puts them into a container that's ready to deploy whether on to your laptop or on to a much bigger production system as an overview talk I'll leave that up there but we can talk more about any of these topics going forward we also want to automate the actual running system once you have an application that's deployed and running we want to automate the management of it and I'd particularly draw your attention to things like capacity on demand @fp complete we've been running systems online for the past four years that run completely unattended on the cloud and when too many users get on to the web application it just fires up another copy and I don't mean another just copy of the software I mean it tells the cloud to create an entirely new server which is built out of physical servers that the cloud provider had on standby go get a new server go put an operating system on it go put this container on it that has our application on it and add it to the list that the router is willing to send traffic to so while applications are in production there should never be a time when somebody's pager goes off saying we don't have enough capacity and our server is overloaded there should be a little script that fires off that says go make more servers why is the world changed why do we now have tools like this it all boils down to computers are cheap and we now have virtual machines and clouds once those things were invented all this automation became possible it was no longer the case that you put somebody in a car and say you have to drive over to the data center or we're never gonna have another server know your cloud provider can do that for you and what we do is automate that process once we have automation life gets a lot better once you have automation you can increase the tempo of new releases you might not want release every second or every 15 seconds but once you're releasing new software reliably and predictably every week life looks completely different from how it used to look in sort of more traditional software development where you say well we're planning a release for eight months from now and we'll get as much into that train as we can and then it's going to leave the station and then another train will leave the station ten months after that life isn't very good in that mode because everybody tries to put more into that release and so inevitably that releases gargantuan and unreliable when you know there's a train leaving the station reliably every week you don't even need to look at the train schedule anymore you say we're gonna get these features working and they're gonna be deployed automatically if the test passes and the next release date happens so we can increase the tempo of releasing to something where our customers are no longer calling us up and saying hey where are my new features the answer is they'll be on the server within a few days of the developer having them working that means we can say yes to new features we can change our job as people in an IT and software from from saying no because we don't know what the impact will be of adding your feature to yes because we have a stable system with all the latest features in production all the time so it's very easy to say well the impact of your new feature will be very small because each week we just release a few little features it also means this is a technical thing we'll get to do if we have time that you can lock down running systems completely once you have a cloud-based automated deployment system you can eliminate the step of modifying and correcting your servers once they're in production instead you can have what are called immutable servers meaning that the server is set up by an automated script that script runs your server has on it whatever it has and if you ever want to change anything about the software on that server you just kill it and make another server the immutability means your servers are never an unknown or unprecedented state where you sort of say oh gosh what command did that guy use oh boy I'm not sure if my data is secure now I'm not sure if my servers will talk to each other of course they'll talk because every server is in a state that was generated by a script that's under configuration management and is auditable that's something you get when you have automated deployment you get it for free so you get the ability to audit and control those engineering changes and any administrative actions new to no longer wonder why why did this happen it means also once you've automated this that you're ready to use new cloud features because your system will automatically work on the cloud and that means that for those of you with the business mind which is some of you I know you can move from using capital expenditures capital expenses to build soft to build servers that are based on detailed forecasts to using operating expenses and saying I'll just fire up new servers from my day-to-day operational budget whenever I need them that makes life a lot simpler when you need to be flexible and able to respond to your users changing demands so I know we're we started a little late so I'll try to be a little fast on the meat here but I know some of you this is some of your favorite part these are some of the things that we physically do when we when we setup DevOps in an organization and partnership with somebody's IT or engineering department we automate pieces of the engineering department we automate pieces of the operations and sort of if you will our favorite spot is the middle where we build the bridge between these two with what we call deployment automation I'm not going to talk through all the steps on this slide because obviously there's a lot of them but we'll make sure you all have copies of this slide and I'm happy to address anything you see here in more detail on a given time we talked about immutable servers replacing servers with better ones I've made a special slide just to emphasize the importance of this technology if currently like most companies you treat servers as living things that have to be handheld and have to be patched and moff I don't improve while they run try to get this mind shift going and see how it feels ask yourself what if I could simply replace any server with a slightly better server anytime I wanted to what if that works even easy wouldn't I do that so immutable servers are technology we're going to see a lot of once we have automated deployment another thing we're gonna see a lot of another term some of you probably know or have come across is service-oriented architecture this is where we take an application and divide it into multiple separate little applications each of which does a piece of the job and they talk to each other over application programming interfaces api's what's special about service-oriented architecture is you have completely different servers running different pieces of your application that can be maintained modified scaled up separately and you don't even have to coordinate closely between the teams that manage those different servers you could just modify one piece of your application while even the other piece literally untouched service-oriented architecture becomes practical when it becomes easy to deploy lots of servers until that time nobody wants to break your application into ten servers instead of one because it's hard enough to deploy one server so again automation unlocks new software architectures for us that now become feasible so right away when we turn on DevOps there are some immediate wins we start having faster time-to-market for our features the the scariness of deployments goes down that sense of so many companies we've talked to who say every time we deploy a new piece of software we sort of grit our teeth and we warn our families right we might not be home tonight and and we actually had a company I'll tell you micro anecdote we were talking about the company here in town that's a software-as-a-service company and they said we want your help with DevOps and deployments and we said we will great that's what we do what help would you like in particular to start with because we like to do a phased rollout and I'll talk more about phase rollouts if there's time and they said well okay we want a way to have a conference call when there's an emergency and there's a failed deployment so everybody can talk about what broke and I said you know we're not in the business of fixing things after they broke on an emergency basis we're in the business of preventing that from happening and they said we are so far deep down this hole we're more than once a week we have one of these emergencies where we have to get everyone from engineering and everyone from IT on a conference call that we'd actually like to solve that first I said we might not be the right company for you we'd really rather help you move forward um life gets a lot better when you proper DevOps in place you can correct issues before they hit the server because you can have a new deployment whenever you want and because your dev environment through automated setup looks the same as your production environment you're going to go in to find bugs before they go into production and if heaven forbid something goes into production that doesn't look right it's very easy to automatically roll out another server that works better maybe roll back to the previous version for example by getting dev and ops to think together about how the servers are going to work we begin to break down the silos that make it's so scary to be an IT today where you say there's only one guy who knows how to set up this server right if he or she that person leaves we literally there's no other wizard in our company that knows how to make our servers work we get out of that mode and into a mode of calm collaboration where everyone understands what they're trying to build and operate and in the longer term that means we get some strategic wins our customers ultimately get more features more often we no longer feel like we're at risk of getting fired every time we try to do anything that increases our Liberty to put new features into play we automatically scale up when when demand goes up and we automatically get access to new technologies as they're built into our cloud provider and ultimately it's less work to build software the same way I was talking here in town with a company that makes healthcare software who has implemented full DevOps themselves and does actually have a weekly release cadence and they've said everyone goes home for dinner with their families every day that's the single best thing they said about implementing DevOps it's not how much better our software is is not that our customers are no longer yelling at us it's that everyone wants to work here because they all get to go home every night knowing that nothing blew up but it's still hard it's you can prepare for resistance when you want to roll out a series of new technologies even those that are as basic as the ones in DevOps you can expect that people will resist this change a lot because for years we've had this culture that our job is to be firefighters right for years we've we've just said well we're emergency fixers that's what we get paid for you some of you probably know the joke that you know if you're an IT manager when everything's working people say why do we pay you and when nothing's working people say why do we pay you right so how do you do right as an IT person well historically our answer has been by fighting fires what we're trying to do as we were just talking about before the talk is John we're talking about is we're trying to move you from a world where you're in danger doing the thing that gets you credit right if it doesn't work you and your company are at serious risk of catastrophic failure we're gonna move you to a world in which you can take credit for things that are safe and reliable say the reason you're paying me is all the new features that came online this past six months and all the new features that have come in line this next six months not because of fighting fires but there are people who work with you who think their job is emergency so there are cultural changes to be made and there are people who will say why I learned at two or three years ago I want to get paid forever to just use that tool so be prepared for some resistance when you actually want to fix things not everybody wants what's best for the company you need to drive that forward with some some persistence and of course you don't want it on the other hand try to do everything at once you don't want to drive change so quickly the organization can't absorb it and one of the topics that one of you asked about before I started today was how do you roll out DevOps and the answer is you don't roll it out at all at once no part of me is suggesting that we should go to anybody's IT organization and replace everything on the first day the great thing about DevOps you've seen how many different pieces there are and how many different tool makers there are and how many different stages there are the way to roll out DevOps is to pick one problem that's really troubling your organization right now work with somebody who's already fixed that type of problem and say give us a copy of that fix just bring us that piece of technology let's do one thing better as an organization and with that under our belt let's do another one and another and another one there's nothing about DevOps that's monolithic Automation can be done in as many stages as you like so trying to do everything at once is but people get too excited so don't worry it's not necessary to do everything at once it's not even recommended to do everything at once there's a need to bring in knowledge that's why we're here today we're sharing knowledge it's gonna be a constant issue for all of our careers that we're always gonna have to learn new practices but still you'll have people who drag their feet and then you'll have people who say well I could have written that right so what if there's a hundred company is in a hundred open-source projects I'm smart I'll write our DevOps system please don't fall into that trap it's really tempting to let you know to let technical staff or oneself try to build these solutions again there's just no benefit right we don't write our own word processors either you'll have the usual issues of people saying I just don't have time to do anything Robert was telling me the joke about the guy who says stop talking to me about that fire extinguisher that you have you're trying to give me I'm busy looking for a fire extinguisher we get a lot of that right so people are very very busy it's probably the number one obstacle to adopting DevOps is simply saying there are so many problems right now I don't have time to think that's another reason to break it into small pieces that are easily adopted you'll find that you need to rethink how things are budgeted because DevOps is about making investments in software and process they'll pay for themselves immediately but somebody's gonna have to hear about how the budget works for all that and of course you'll have to pick which tools you use because there are a lot of them that's another reason why why people like us are around to say it'll let us help you we spend all day on these things so a few takeaways then I'm gonna wrap up and because we can get more detailed about anything but I know everybody wants a things to say reasonably concise automated deployments will change your life if you do not have a system for automatically deploying new software and new applications and new updates onto your servers you need to get one we're happy to help of course continuous integration will change your life if you're making new software having a system that constantly builds and builds and builds new copies of your app and constantly runs the tests and we could have a whole separate lunch talk just about testing and how important it is to make sure that your software is well-made before you put it into production again automation makes that easier once you have a reproducible system your life gets better so DevOps is ready for you to use and it will make your life a lot better and we'll do some QA in a minute and we'll see what people want to hear more about what I would recommend since a lot of you are in leadership positions is put your focus on the right topics don't get drawn in to questions of it should I use tool a or tool a - or tool a3 that's not really the main question about DevOps these tools work very very well indeed the question is can we change our organizational culture and our way of making decisions to learn about the better tools and to make a commitment to adopting better tools and the better processes that go with them so that we can have a calm and orderly cadence or tempo of new releases that are reliable predictable and secure and as you're managing your team's push them to focus on things that are reliable things that are predictable and and take the take the trophies off of the firefighting category and put them into the fire prevention category of course I'm happy to talk more with any of you about any of these topics it's what FD complete does for a living and for now let's open it up and see if there are a few questions with the group take a minute to let you gather your questions okay where do microservices play into service-oriented architecture two ways one is that you can break your application into very small pieces and you can say there's a piece of my application that other people in my company should be able to access if I could easily deploy that onto its own little server and publish an API now no one else in my company has to reinvent this capability they don't even have to see my source code and this is where life changes between DevOps and traditional software engineering in the old days you talk about code sharing I wrote something how can I give this code to a colleague who can then put it into their app in the new days where we talk about dev and ops working together you never have to show that source code to your colleagues you can just tell them hey I've solved this problem folks here's the what here's the address of the server that I and you know as my engineering people in my ops people are keeping it running all the time don't worry about how it's written don't worry about the code we'll maintain it we'll upgrade it over time just connect to this address and the service is there for you so that's you taking a piece of your application and publishing it as a micro service for your colleagues that's one way the other way micro services factor in is once you have an architecture for your applications that assumes that they're online and can reliably access online resources and cloud resources you can start shopping for other people's micro services you can start saying why do I have to solve all these problems and you can you can shop for smaller and smaller problems that an outside company may have solved perhaps you just need user authentication perhaps you just need data backup perhaps you just need some math diamond and you can pick little services and shop for them without having to write that code again yourself as long as you know you have a reliable way to put your app on the network one of the next steps is to then start accessing network resources another question anything different topic yes sir yeah versioning and how do we manage when there are a lot of versions so there are at least two ways that I would address that I guess I have two answers for everything I would seem let me talk first about source control and auditing and then about how do we bring up new versions of software so for version management the most important thing is to understand what piece of software is actually on a server because you want to be able to predict what happened and if a bug occurs or a complaint you want to know what software is on that server the we can spend up I won't get into the full detail in versioning this is a complicated topic but my short answer to that would be you want to have an automated system that creates lots of log files so we did a system for example for a big pharmaceutical company where they said the FDA or our regulator wants to know anytime anything that comes out of this computer looks suspicious is there something wrong with this computer and so what we did is we set up a system of progressive log files where they can go to a server and say which server answered this HTTP request what software was on that server they can go through log files and backup the question and say well which district which automated distribution action caused that software to get on this server and when that distribution script ran where did it get its executable code and when that code was built where did it get its source files when those source files were built where did those check-ins come from and when those check-ins were done what line and what SPAC was cited by the developer who checked in that piece of code so that there's a complete path backwards from I saw this on my user interface all the way back to there was a line in a requirement spec that a developer was trying to implement and that's why you saw that code on that server so we can find any mistake that might have happened and trace it a micro version level another way I want to address versions for a second is how do you actually deploy new versions of software I said it's automated that sounds lovely but I went rather quickly and didn't go into a lot of detail there are a couple of main ways that people deploy new versions of applications with modern DevOps I'll call them immutable device an immutable server an immutable device means you bring up an entirely new virtual private cloud your script says I know how to build the routers I know how to build the admin accounts I know how to build the connections between the machines the database connections and things like that I'll just bring up we did a device software based device on the cloud for one company that when you run sort of when you pipe sort of go and say go ahead and set me up a copy of this device it brings up 12 computers and so we just bring up an entirely new system in an entirely new virtual private cloud so that versioning happens for the whole device at once that's a super rock-solid way to do things it's also pretty hardcore yeah there's a hard core client that wanted that level of robustness but more common is to do staging where you replace the serve the application servers one by one from the previous version to the new version two terms you may see in literature about this our canary deployments and Bluegreen deployments a canary deployment basically means I have a set of replicated set of application servers I'm going to I'm going to add to that cluster one server running my new version and then I'll let traffic go to all of these servers and see if any of them looks different from the new server than the old server and if everything looks fine then I feel comfortable to my new server works and I can roll out more of them that's a canary deployment comes in the expression the canary in the coalmine the animal that if it gets sick you know something was wrong and then a version of that another version that's called Bluegreen deployments where we say we have two groups of server's aren't which we arbitrarily call the blue group and the green group and we'll keep them all running and today production is on the blue group and when it's time for our deployment we'll put the new software on the green group and then we'll switch the traffic over but the blue group is still there until next week's deployment with the old versions of the software so you have the current and the previous version of your application running in both of these models so that's a way to handle gracefully the transition and then you let the network direct traffic whether to the servers run in the old version the servers are in the new version or both I know there's a lot more to say about version management but I'll leave it at that for now another question another topic okay so I'll focus a little bit more on containers if that's okay since we already spoke about micro services but containers are a technology that we use almost constantly first of all just to show of hands how many people here have any familiarity with containers or container is a Schnoor docker okay so about a third of people so I'll explain a little bit so containers are a technology that's much lighter weight than virtual machines but at the technology for grouping together all the resources needed to run a particular application and its particular runtime environment because a container is not a whole virtual machine you can actually deploy several containers on to one virtual machine and therefore micro service has become more feasible you don't need to set up separate virtual machines for every application that has its own preferences for its runtime environment the container brings with it config files and even operating system related files that it wanted to see effectively creating a little private district within the operating system that's configured as it would want and those files are hidden from everybody else except that application so what we're doing with containers is we're saying we like virtual machines we like the idea of creating an environment on demand that runs whatever we want but wouldn't it be great if there were something even lighter weight where we could just instantly put new software onto any number of virtual machines and like with VMs there are broker middleware pieces of software where you can say I've put up several copies of this container running on different virtual machines or different physical machines please direct the network traffic to any of them that happens to be free so containers and virtual machines both give us a sense of load balancing and a sense of automatic capacity management where we can bring up more copies anytime we want to the big difference is containers are so lightweight and so cheap to fire up even cheaper than virtual jeans that it becomes more realistic to say I'm gonna make a separate container for everything I don't have to just make very large ones I can make several small containers they're cheap and that's why the micro service has become even more cost-effective that's different again from serverless computing and which is sort of an interesting twist where you say I don't want to know what server is running this container I'll just specify somebody run this container please and I'll rely on my hosting provider to find a suitable computer without telling me about it does that make sense sure you're very welcome a different question yes what type of ROI can people expect from deploying DevOps I'll tell you the truth is that we don't usually measure it that way because the client usually takes the savings and turns them back into other benefits so they're saving a lot of money but they're usually saying now we can ship instead of not being able to ship or now we can add those features that we were never able to add or now we're getting no security outages so it would be great for me as you know promoting something to have a dollar figure but what's the dollar figure for not compromising your HIPAA data you know is it is it a million dollars I mean what's it worth to not sort of you know ruin your privacy of your of your clients data what's the dollar value and getting your features out this your instead of next year it really depends on the business what the dollar value is but people tend to roll those savings back into more IT capacity rather than giving the money back to the corporate Treasury so we don't see it as dollar so much as we see it as IT works ever so much better than it used to does that make sense you measured in the output of work thank you and that's not always dollar priced there was another question over here I think yes I'm sorry you're chewing there will be another question in a moment okay so what are we seeing happening with serverless in the future and also with the choice of languages for programming on servers is that fair summary for server less visited okay so what we're finding is first of all we've entered a world where companies don't want to commit to a single language anymore the days where people say we're all gonna program in one language are really gone because we now have programs talking to each other over network interfaces you can take any team and say build your piece using the technology most suitable and of course that started years ago where we said well the web browser can only run JavaScript but we don't really want to write our server code in JavaScript so we had this sort of 2 language actually it started years before that when I was at Microsoft we were doing visual studio and we would tell people well write your high-performance pieces in visual C++ and write your easy pieces in Visual Basic so mixed language programming has been going on for a long time and it's continuing to be more of a thing and more of a thing but to the point where now people in an IT department don't care what language someone else was using and I'll just give you a simple example if you wrote an app right now and called an API to let's say get a stock quote off of a stock quote service do you need to ask what language that stock quote service was implemented in no right you have no interest in knowing that just give me a Web API spec and tell me how to ask for the information I need so in terms of the trends we're seeing people are using a lot more node J s people are using a lot more native code we're seeing a lot and our favorite language Haskell compiles to high-performance parallel native code we're seeing a lot more parallelization we're seeing people running up against issues with a languages like Python and Ruby where they're saying it's not giving me the performance that I need anymore and they're starting to look at languages that are more parallel friendly in the Microsoft world a c-sharp continues to be a big success on the Java Virtual Machine frankly it's a bit of a mess right now I think we could argue that the people in charge of Java kind of let it sit for a while and now there's a lot of discord about which which languages people should be using on the Java Virtual Machine I'll be honest and say we try to work on non Java Virtual Machine solutions if we can the technology is just so much more advanced these days in terms of how that all affects micro services I think the main thing is to say when you want to use or all serverless you also asked about if you wanted to serve this computing that's probably a little more advanced than most people here are doing but looking looking toward the future the ultimate sort of automated deployment is I want software to deploy by magic and I never want to know how it happened that server list it's not really server list this don't talk to me about the server the server list deployment the I'd say the short answer is the less baggage your application needs to run the later weight to the container is that your application is in the more suitable it is for rapid server list deployment which is one of the reasons people aren't so much using JVM but another reason is just raw performance to cost you went from eight thousand dollars a month to eight cents a month by putting your algorithm on server list so you were renting over okay okay oh oh I see and is it is it because you were having to rent a whole server for something that didn't really need a whole server right so not having to rent all that except moment-by-moment yeah a lot of if you look at and I'll pick on somebody's not in the room which isn't nice but if you look at AWS since it's just a leading volume cloud provider you look at how the pricing works um you can pay too much sometimes because you're renting huge chunks of resources and it's very interesting to think about am I getting my cloud services from somebody who's going to be flexible and make it priced and available in a way that matches my usage patterns Amazon you know they were there first that's nice their pricing is a little bit a little bit chunky compared to what people want sometimes one more question maybe yes sure so how can we get started with DevOps what's a good starting place without biting off everything I would say we typically look at either how to get an application on to the cloud using automated deployment and containers that's a great way to start right if you have an application that's not cloud based a great project is just get that application moved over to the cloud and most companies have lots of different applications so you don't have to pick sort of the scariest one to do first it could be one that's relatively new or one that's relatively self-contained and you kind of get your hands you know into DevOps through that path another path that we see a lot of companies asking us to help them with is to start DevOps from the dead side where they'll say well we have a team that's actually writing new code and if we could automate their work then it would be a little bit more predictable and then it wouldn't be such a shock when this crazy thing shows up and they're saying please put this on a server that's a nice way to also bridge the gap between ops and dev because you can start having the conversation from the IT or operations group saying to the developers well what do you want right we can expose to you an image of whatever runtime environment your application would like so now you kind of throw that back on the engineering team the dev team and say you don't get to just produce anything you want and tell us we you know somehow make that run on your server on the contrary you sort of say to the IT group hey let's be more structure in our offerings let's tell the dev group if you can put out an automated build we'll tell you what runtime environment that build needs to target and if it doesn't make it all the way to that runtime environment then I guess it wasn't ready to deploy so let's work together and make that happen so those are two different great ways to get started getting onto the cloud or getting the flow automated from dev to production for one application we have time for one more question Robert okay we'll stop there then and if anybody wants to talk more after um first of all I'm available and secondly I'll move this glass out of the projectors way so you can see my email address is Aaron enough be complete comm and of course welcome to contact me anytime back to you Robert here so just to conclude here I know we meals got out a little late desserts coming as well feel free to hang around there's a beer menu in front of you I'm not sure if you had an opportunity to try a Ballast Point beer but they're there for you as well but if anybody needs to contact us we're here now you can come pick up our business cards and we're happy to help mine centric I want to thank those folks for co-sponsoring this event with us and hopefully we'll do some more so in the future if you have other people that you think would be interested we certainly like to host them as well so I'd like to thank everybody for coming out thank you

Channel: FP Complete Corporation

Views: 1,537

Keywords: DevOps, Functional Programming, Continuous Integration, Haskell, software development, computer programming, Cloud Computing

Id: dUkcsqvtJQo

Length: 59min 29sec (3569 seconds)

Published: Fri Oct 06 2017