Devops Mastery

A lot of people new to automation are very nervous about letting a script or program like Chef change a production system. That fear can really slow the advance of a DevOps movement. But ignoring those people's fears is not the answer. So here are some tips and tricks to get everyone, including yourself, to be more confident about writing world changing scripts. Whenever possible create virtual environments. The use of virtual machines or cloud servers gives you considerably more options and abilities than bare metal hardware. Simply the ability to snapshot a server and revert back to it in minutes is a game changing concept. It let's you run any automation from beginning to end virtually without fear. I say virtually only because you occasionally run scripts that affect systems that cannot easily be virtualized. This is now more the exception than the rule. If you take a snapshot of the server, run the automation, find a mistake/error/bug you simply revert the server back to the starting point, fix

Bob from Minneapolis sent us some great feedback and a couple of great questions. In this post we are going to tackle communicating what scripts are available and what they do. I spend a lot of my time as a consultant writing up documentation. At most sites I am pretty sure the work is lost before I get out the door on my last day. So how did I try to handle this before as a Tech Lead? To be completely honest it always seems to be hit or miss. I have never found a single solution that works for all purposes and with all types of people. Let's face it we as WetWare are the most difficult to communicate with. Hardware wants power and bits to process. Software wants data and other inputs. But humans, a.k.a WetWare, all want something different. There are all kinds of factors from Gender to skill level to happiness with their current job that can affect and require different types of communications. Since we can't solve all of these problems, and at least one is unsolvable, we need to focus on what we

Everyone loves a new toy. New tools help us do our jobs better, faster and more accurately. Which is great when you understand exactly what you want the tool to do for you. How often does that really happen though? As an Enterprise Architect I am asked on a regular basis to help companies deploy tools. The problem I run into the most is they don't completely understand what the tools can do for them. They know it will fix one problem but may not realize that it could be fixing others. Then there is the situation where the competing tool could have solved even more problems and easier. So why don't my large enterprise clients go through a process that prevents this? Every company is different, but sometimes it's a time factor. Other times it's not understanding the problem they need to solve. Each company is unique on what their specific issue is. Usually the core issue is that the selection process didn't have enough parameters or ignored parameters altogether. In a lot of situations and evaluatio

If you are really going to master DevOps you need to master communications. At least the ability to clearly motivate and pull people into the discussion and the goal you are trying to achieve. Spending an extra fifteen or twenty minutes writing an E-Mail can save you days and sometimes weeks of discussions, arguments and apologies. I have a lot of tips about how to be more effective in communicating ideas but today I am going to give you my top six. What is the goal of your communications? A goal is essential to forming any effective communications. If you don't really know what you want to achieve with the message how will anyone else. Some common goals for me when I was an operations lead were getting help with a Memory Leak, let everyone know about upcoming patches to the middle ware, or getting someone to help figure out why a build or deploy is failing. Once you know what the goal is you can easily expand on it and form a complete thought and translate it into a communications. What is your motiv

What follows are the criteria I use to determine what to script or automate first, second, and so on. It's another of the "it depends" questions that never have an easy answer. I will try to help you make some rational decisions but ultimately it's your world to live and you need to decide. The thing I see everyone want to do first is automate and that takes the longest to do. That task takes the better part of a week to complete because you are constantly getting pulled in a hundred different directions. This is not the first thing you need to automate or should automate. Not that the duration of the task isn't important but the number of times you have to do it, is more important. I may only spend 2-3 minutes compressing some logs on a development web server. If I am doing it on 10-20 various servers every week it's not only annoying but it's sucking a lot more time because of the context switching it's causing. There is also the cost to your company in the time spent by the users of the system try

Automated Deployment or Automated Build tools are all complicated to give a true evaluation. Before you even try to evaluate the tools, working through the complete process manually is normally the best place to start. You need to understand how the deployment process works before you can figure out what tool will meet your needs. Things to take note of is the tests you will need to run, the operating systems involved, and how you plan to do the deployments to production. You are trying to achieve consistency across all your environments so deploying a tool designed for web applications may not have the features you need to deploy smart phone apps. This isn't to say that most of the tools can't do both just that you need to probe deeply to make sure all your requirements are met. Below is my top list of things to look at when choosing a tool of this class. As with all the other articles on tools I have written this list probably isn't complete. You will need to assure that you are meeting all of the "

Before we begin this discussion remember this one thing while you read this; what you use to manage code is less important than making sure you manage it. Management in this context means version tracking, an ability to roll back changes in code, and being able to compare two versions of the code in question. The time people spend trying to track which is the latest version of a backed up file far exceeds the time it takes to learn any repository management tool. Wasting time arguing the merits of the tools is just that a waste of time. While I am not a fan of certain tools in this class they all can handle the basics I have outlined above. I believe so strongly in this that I am not going to share my personal choice or make a recommendation in this article. This tool set has been the domain of developers in most organizations since the dawn of computing. With the focus on software defined infrastructure operation teams need to use these tools. They need to become as adept at using repository managemen

If you think there are a lot of tools to configure your systems you haven't looked at the tools available to monitor your stuff. The set is so large that it is easy to get overwhelmed. So again in this article I am going to give you a list that I use to narrow the field. Then I am going to give you a list of my favorites. Is it agent, agentless, or hybrid? As with most configuration management tools this question cuts both ways. The best in this class of tools with agents have well documented deployment paths that use various configuration management tools. For instance, they will have Chef or Puppet packages that cut down your time to deploy them tremendously. The choice on this question is how much time you have to deploy it and how fast a response do you need from the tool. Agent based tools are faster in most cases. Agentless tools rely on some form of remote execution tool like ssh or remote powershell and an SNMP(Simple Network Monitoring Protocol) agent. Because the server in an agentless system

Configuration Management DevOps Tools are plentiful. So we will start this primer off with what I look for in a tool and why. Then we will talk about my current top paid and open source choices. When I am evaluating new tools in this class look at the following things: * Is it OS restricted? If I need to manage Windows Machines and it only supports Linux then the solution obviously won't work. * Does it support the application platform we need to support? This is generally more of an Enterprise problem where you are deploying Application Servers. * Can I write custom scripts? If we have a team that can or is willing to learn how to script we can fill in any minor missing pieces. * How much OS needs to be in place before I can start using it? Will the solution allow me to go from Bare Metal(i.e. no Windows or Linux) to fully installed? Or does it require that we have some basic level of an operating system. * Is it Agent Based, Agentless, or a Hybrid? I tend to lean towards Agentless