Infrastructure-as-Code and Configuration Management

migrating to the cloud gives us some very powerful opportunities these opportunities primarily surround infrastructure as code which is comprised of two main legs you have templates that you write the provision your cloud-based resources and service endpoints and then you also have configuration management which goes on and provisions those specific services or provisions those specific servers after they boot infrastructure as code essentially is a way to represent your environment through configuration files typically we work in JSON Gamal also you see it in XML it's a way to describe that environment so you can replicate it over and over and over again and get the same results every time when we talk about infrastructure as code we're really talking about two main component pieces we're talking about some type of template that is declarative and that enables us to order up resources from our cloud provider these resources could be load balancers that could be auto scaling groups they could be individual virtual machines themselves or they could be some type of service like a relational database service or like a cache service configuration management focuses around on rolling out a platform whether it's a Linux platform a Microsoft Windows platform and being able to set that base operating system up and deliver the configuration necessary to run an application whatever that application may be we're going to be front-loading a lot of our work and we're going to be doing a little bit extra work initially inside the test and development phase so that when it rolls out to production what we're actually doing is deploying a manifest of changes that's already been fully written down fully described fully tested and fully inside of version control you have maybe drivers you may have dependency packages that have to be deployed all the way up to deploying the application itself configuration management is nothing other than writing down every single configurable aspect of your system and the main thing that we're trying to banish here is midnight changes to the equipment we're trying to get rid of the need for an operator to actually SSH or RDP into a particular server and kowboy a change immediately it also helps you guard against application configuration drift so you have human hands go in and touch the application you always have the code base the original description there to return it back to operational normality and be able to do that maybe for your dev environment your QA environment your production environment there was always some friction between application developers and infrastructure engineers from the infrastructure engineering side it was very easy to believe that application developers would just chuck code over the wall and walk away and not feel any sense of ownership and then from the other side there's the requirement from the application developers to release new features and to really generate a large amount of value for the business that they can't do if they're being held in place with old versions of libraries old versions of operating systems old equipment or simply a provisioning workflow that takes anywhere from four to six weeks to get a single server racked and stacked inside of the data center the thing that changed to bring these organizations together was this idea of API first service delivery and it's really the major cloud providers that seized on that because of course you're using somebody else's computers they've got to give you a way to interact with those computers and they made a decision that they're going to do published api's of necessity we now have infrastructure engineers learning how to code if they didn't know that before of necessity we have infrastructure engineers utilizing the same tools that application developers have known and learned and loved for their entire career such as version control such as automated tests such as push-button deployments we are often asked hey not using configuration management now what should I do because there are honestly quite a large number of tools and platforms out there we can absolutely help our clients move forwards into an API first-world the way that we do this is one of our particular strengths we bring the knowledge and experience that we have managing traditional IT workloads inside of the data center together with our knowledge of infrastructure is code configuration management and C ICD that's continuous integration and continuous deployment practices a number of clients come to me and they say look I know that I need more automation I know that I need to move faster I know that I need to reduce the amount of manual work that my team is doing how do we do that you know the answer is pretty simple what we need to do is take a look at the incoming work expressed either through service requests tickets or incident management tickets we need to take a look at the things that we are spending the most time on and then we need to aggressively begin rolling out configuration management and other automated solutions to those things that are causing the most manual work that are causing the most incidents we bring tools such as version control chef puppet ansible for configuration management as well as continuous integration tools as well as automated testing bear on these situations and we get into a positive feedback loop where we understand that you don't need to automate everything 100% of the time and you really can begin to make slow steady progress automating the world but you need to do it by taking single steps and by breaking large problem spaces down into their component pieces so with configuration management there's a number of different platforms out there and honestly they all get the job done pretty well I add a nova solution we currently prefer chef because it's domain-specific language it's dsl is just plain ruby and you can do just about anything that you want to with chef and because the DSL is just Ruby chef recipes look very very similar regardless of if you're writing them for Linux or if you're writing them for Windows and that really gives you a force multiplier when it comes to training and documentation and the process necessary to get into a good workflow with configuration management we are bringing traditional infrastructure engineering people much closer to a software development workflow we're storing all of our code inside of version control we're using linting and automated testing Suites to do continuous integration on this infrastructure code and then we're also using continuous deployment to get it out into production after we've verified that it's been tested and limited and acceptable to the team we have shifted everything over to infrastructure as code all of our internal systems are set up primarily using AWS cloud formation templates all of our internal servers are set up with configuration management so we can absolutely help our clients move forwards into an API first world the way that we do this is one of our particular strengths we bring the knowledge and experience that we have managing traditional IT workloads inside of the data center together with our knowledge of infrastructure as code configuration management and C ICD and we merge those together with a very practical approach to what is the most painful thing that we are currently experiencing ANOVA solutions knows that journey because we've done it ourselves while we were working for fortune 500 company and because we've walked alongside of many clients on their journeys as well

Channel: Innova Solutions Inc.

Views: 2,347

Rating: 5 out of 5

Keywords: infrastructure as code, configuration management, steve craig, robert toups, devops

Id: PiX_DhHEutc

Length: 9min 39sec (579 seconds)

Published: Thu Nov 03 2016