Webcast - The Road to DevOps
Transcript
[Music] alright welcome to the CTO of Iser their role to DevOps advertise this as the steps you take before you even consider buying a DevOps product there are tons of products on the market that advertise themselves as I want to say most marketers are fairly honest when when it comes to marketing but they label themselves DevOps tools and I think it's important to understand the DevOps processes and prereqs before you even go out and buy a - DevOps is definitely not something that you can buy
a tool implemented and then you're good it's not like vmware vsphere we say ok I want to virtualize my environment so I'll go out and buy vmware vsphere our garden by hyper-v or go out and buy deploy KVM and follow a road map to virtualization straight forward can't do that with DevOps I can't go out and buy ansible and now I'm a DevOps environment very different use cases so with that said let's talk about the business value DevOps brings organization basically why why don't you bother
with DevOps I think the number one thing that it brings a business is business agility the ability to take you know there's this concept cult to cash similar you know idea - cold - production how can I reduce the amount of friction between the business and IT so the IT becomes a partner to the business versus just a cost Center or a new on newest to be managed second it reduces risk so one of the aspects of DevOps is that you implement DevOps practices such as
automated cult review you speed you want add agility and you speed the process to get the cold into production but you also autumn II the checklist associated with implementing that cold so the you take out some of the human factor in errors for cold server builds network changes no matter what your dev opping I'm gonna pan that as a verb dev opping that you have this ability to reduce downtime associated with human error and as a result where as a result you're gonna get less support
calls that's both you notice how that's both a cost reduction in a reduction of risk and then there's the reduced cost this is I think a major driver for many organizations you know when we first looked at the depth term DevOps we thought cloud native and if I'm not in a cloud native environment why should I care about DevOps and then we started seeing tools like ansible network vendor is talking about programmatic networks and api's to network and intent-based networking right now network field day 17
is going on and cisco is talking about all of these devlop like concepts and what looks like legacy IT so we have the ability to implement DevOps automation to reduce overall labor cost associated with things that we traditionally through people with you know we would if you were deploying a new data center you need to deploy you know 30 topper right rack switches you deploy an engineer to configure the clean the command-line interface for each one of those switch switches so that might be an you
know two weeks of man-hours of someone just factory two-point switches versus racking and stacking those pushing a button and automating the deployment of that it reduces the cost associated with provisioning traditional services and we'll talk about how that impacts the development process and the next slide or two and then it allows you to use commodity services you find as you start to automate and dev up and move to a dev op operations that a lot of the fancy services that we bought within like let's say
a server vendor you might be used to what used to be called compacts compact inside and moved into HP inside we're now HP e inside or dale open managed these products that were designed specifically to manage hardware implementations from a particular vendor you couldn't use open managed traditionally to manage your Compaq HPE infrastructure but now you can take things like puppet chef and apply these DevOps principles or cross hardware vendors you've abstracted away that now you've gettin to the point you've restricted way that management and
now you gotten to the point where you can even use white boxes for some of the capability you will have looked to Dell or HP E or Lenovo to do because of their proprietary management solutions the same across this is not just a heart worthy this is across cloud services as well you know we have you know solutions like app formics and cloud templates and cloud forms and they're the list goes on and on to normalize cloud services or the management of cloud services across multiple
clouds whether it's a private cloud or a public cloud Netflix talked about this awful lot in their white paper on Titus there orchestration 2 for managing containers about the need to normalize services across there and public cloud so DevOps does three things provides business agility reduces risk and reduces cost I think those are the primary business drivers for pursuing a DevOps infrastructure or operations so which model of DevOps are you interested in I think that's an important question before you go down to DevOps journey you
may ask yourself Keith I didn't know there was more than one DevOps I get this question well actually I asked this question any time I'm engaged to advise an organization on DevOps I'll get a call from an executive that says hey Keith I need helps with my DevOps and the first question I ask is what kind of DevOps are you looking for I had a picture originally they had on the left hand side where has application centric a picture of Netflix and then on the right
hand side infrastructure centric a picture of VMware and VMware VR VR VR the ops they are fundamentally two different value propositions the application centric which I like to call you know mold one DevOps actual DevOps is when I'm integrating the operations of my infrastructure within the application again Netflix is the best model to kind of hold up and show as an example of this mo1 devops this is where applications are monitored actively monitoring the infrastructure applica skeletal elasticity is built into the application the data center
control plane is part of the application so if there's a failure in the infrastructure the application itself is self you'll alert operator if needed if the issue can be resolved by deploying more workers or more workloads the application calls to the infrastructure to make that happen the overall health of the application is monitored via the application developers and whether their front-end developers and back-end developers are working together to ensure that the application itself manages the infrastructure or operates the infrastructure though where I believe the term
dev ops originally is - from what I call pure Dell DevOps this is the ideal of getting rid of your quote unquote getting rid of your operations team and collapsing your development team operations team into a single team and the application itself controls the infrastructure so obviously there's a lot of value in that from a our previous slide we saw all the things that we love to do that if you're building an application from scratch this makes sense to pursue this pure DevOps model however if
you're in a brown field and you have traditional workloads running in virtual machines bare metal servers etc and you simply want to reduce the cost and risk associated and add agility associated with managing that infrastructure there's a lot of advantages that come from DevOps if I can automate the deployment of a VM then I can reduce the time that a business waits to say oh you know I don't want a new Oracle database and deploy you know a new CRM tool on top of that if
you reduce the wait time from a month to a day or two days then that as traditional tremendous business value from a agility standpoint if you can automate the deployment of a virtual machine so that it's not a form of art every time a engineer builds a server then you reduce the cost associated with deploying a server from a written from a risk and support perspective same thing with our ability to reduce cost last time I have server engineers building servers more money I save so
again both models are DevOps absolutely absolutely are valid approaches but you need to understand which model of DevOps you're going to pursue because they're very different operationally which brings us back to the point of all of this that DevOps is again like any other technology or governance model it's about people process and technology you can't ignore the people and process part of this discussion I think this discussion this this webinar is based on the concept of examining people and process before you even look towards the
technology you need to ask yourself some basic questions when you're looking for a DevOps model one from a people process who will be impacted now the obvious part is of course IT and developers will be impacted when it comes to DevOps but that's not it remember we're trying to add business value to business users so the business will get impacted so let's expand out from just IT and look towards let's pick a group randomly accounting people account for IT infrastructures in a hundred different ways when
you deploy a VM the VM might need approval from the finance team the group the application team consuming the VM security compliance etc if you automate the process to deploy them within your IT organization and it breaks your back in accounting that's a bad thing so you have to get these external groups you have to exam and we'll go walk you walk through a process you have to look through the process and understand when you automate or quote-unquote develop a process who's impacted in that chain
of automation and at least two how will they be impacted do they need to change their own systems do they need to go to the next point more training outside of IT do I have to train my business user on how to consume my DevOps environment if I if I'm providing an API to my data center I have to implement it and I have to implement a API therefore do I need to send my business user to OpenStack training so aw I deploy this whole thing
in AWS so I need to send them to AWS training do I need to have an in-house set of training materials on how to consume the infrastructure that I build now that I fought emitted then process you can't automate what doesn't exist this is probably my most popular tweet ever 110 retweets you can't automate a process that doesn't exist a lot of enterprise IT the reason why we have challenges with support risk associated with downtime is that a lot of enterprise IT for all the science
behind the technology is very artisanal to engineers the point of exact same solution will deploy it in two very different ways so we gave the virtual machine as an example you can have a template in vmware that says deploy virtual machine there will be some steps to configure the virtual machine post-deployment one engineer may have a very good relationship with the person that manages IP addresses within your organization the other person may not even be on speaking terms with that person so one person can deploy
a server get an IP address within a couple hours and have the server deployed in one day where another person would have to get in the queue and wait to deploy a virtual machine because they're waiting on the IP a dress that's just the nature of people processes in technology when we marry those things together and we say we're going to automate it if I can't write down the step by step process on how I do something this is computer science 101 garbage in garbage out
if I can't write the process down then I can't tell a computer to do it for me so we can't automate a process that doesn't exist we're gonna spend quite a bit of time going through a CIA CD process and seeing where some of the holes are when we talk about DevOps which you know to reinforce that point there's no AI for DevOps I can't go to my DevOps tool and say oh I want to implement a CI CD development pipeline process based on what we've
done in the past and my to magically figures out everything that needs to be done in order to automate that process AI for DevOps does not exist so before we get into the CI CVD process I'll pause for questions if there's no questions we'll continue on so a brief 15-second pause for those of you on YouTube watching this all right with no questions we'll go ahead and go on to the continuous integration map that I've downloaded from SlideShare a tip of the cap to EPM systems
for what I thought was a pretty good process that I didn't have to reinvent so we'll start at step one CI CD I've literally gotten this question from a fortune 500 which was we implemented a virtual environment for our developers to create cold and they love the environment however we run into all kind of problems we're trying to deploy to production because now we have this distributed model for the code development but we don't have any controls in place to get that to production keep teeth
help me fix our DevOps well you know what to be honest you don't have dumped their apps you have a bunch of tooling and I'm sure the developers love the tools but there are no processes to automate in order to you know say that you now have DevOps and I thought I'd use this development lifecycle just to call out some of the pitfalls that many companies fall into when they look to automate or adopt a DevOps develop like principles and managing their infrastructure and their applications
so step one development team you know what I I have source code I want to create source code we create environments for developers to create source code the source code is created pushed to a version control system so that's step one or two obviously most people have step one they have developers creating cold most organizations hopefully at this point have some type of version control system whether you're coming from a development operate DevOps environment to a non DevOps environment there is version control that gets complicated
as you get more and more teams and more and more development environments so you might need to look at a new system like git but for the most part version control systems are there then you go to source code build and this is where we start to see some of the first cracks in the system if you have separate development teams creating separate sets of cold and we no longer have this concept of a building so you have to have your revisions in by a certain
point of time a developer can on their container focused development environment on her laptop can build versions of their code at any point in the day let alone the week then that complicates the remaining sets of steps this is something that has to be given some thought if I'm going to distribute the load across several developers and give them independent ability to to code and build and submit source code and I no longer have a single day to say okay cold cold revisions have to be
in it by this point in time so that we can build and now have stat this this process of how I analyze the cold and again people normally fall down at this point because they said oh I've given independent tools I have DevOps know how did these changes impact your down-the-line processes static code analysis these are things that people used to do by hand you may now automate these things and you can't automate them but if you don't have a checklist of how how do you
perform code analysis let's say you want to automate code analysis if you don't have a checklist of the things you check for in code analysis can't automate it can't automate what you haven't written down run automated unit tests again this is something in the past that we've done manually when we have won big cold build day we could do integration testing if you've distributed the workload across several developers and giving them independent schedules on being able to build and test and I'm sorry review cold now
the test of that code has to be automated in a fashion that you know we have a C ICD process that I can update my production application several times a day well you need to be able to automate the text functions within that process if someone has to manually review the code and do manual integration testing then it's very difficult to do C ICD and to the point that if you haven't written it down if test it's not something if if the test process the things
that I test for in my integration process for my development process if I can't script that I can't deploy it to ansible if I can't deploy it to ansible ansible can't automatically approve the changes that I'm gonna make in production cold coverage analysis not really sure what they mean by this in this example but we'll fast forward I think we're getting the point I think if can't get down to the basic principles in detail of all the processes needed to get cold from a coders desk
into production then you cannot DevOps you can you need to first start with this process develop a process for how you get cold to production document the steps in which it takes to do that the details within that steps once you can script that you can automate it once you can automate it now you can go into a mode of DevOps so that's it just overall principle you can't automate what you haven't written down you can't automate a process that doesn't exist if you can't do
that you're dead lops projects won't get the business value or benefits you're looking to get you won't add agility you can't add agility if the processes are broken you won't reduce risk you can't reduce risk if the processes are broken and you can't reduce cost if you can't automate and limit the number of people to have the touch cold they have to touch systems to review and ensure that they meet the requirements of the business the
