devops

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 or Hybrid solutions because it removes the requirement to monitor or restart the agent when they fail.
* Does the tool have a DSL or Domain Specific Language or does it use a standard method for describing work to be done?
    This will tell you how steep an adoption curve you are going to have.  DSL products generally require more training than ones based on YAML or XML.  

This list narrows the field for me.  The how much OS needs to be in place is one most people miss in their lists.  But if you need to roll out machines for something like a Disaster Recovery Drill it can be critical to your timing and person power requirements.  A tool that will go from bare metal to fully functional would be better for that solution.

No solution will be a 100% fit for your environment.  So you need to make trade offs.  If I have a team that can script then customization may not be a problem.  If I don't or if they are all new to it I may want to choose a tool that limits what we can do but does more out of the box.

How the tool works for me is also important.  How do I scale this tool as we grow. Can I set up more than one master server for failover/load balancing?  There is nothing worse than a fully deployed management tool with not management server.

What happens when the Configuration Management tool and server cannot talk for an extended amount of time.  Can the tool maintain the configuration the last known good state?  Does the server alert/log that the server cannot connect to the remote machine?

Once I have figured out a spreadsheet with the names of DevOps tools down one side and my critical items listed across the top.  Below is an example one I filled out for WagsWorld.com(one of my other sites)  If the item isn't a simple yes/no answer I have often used a numeric grading system.  This let's me further refine my rankings of the tools.

If you are a small company working with Linux based systems any of the open sourced tools should be more than enough.   Small companies with Windows systems will have a slightly harder time because that will reduce your Open Source options and may require a small investment in a paid for solution. The larger the organization the more people that have to see how it all works out and the more likely you will choose to pay for a tool.  The good news is that most of them are pretty cheap at this point. 

The bottom line:
* Take your time do your research 
* Make sure it will do at least your list of must haves
* Make sure you understand what it will take to extend it's operations.
* Test it out in a lab before agreeing to spend any money for a tool
* Invest in training if it's available for two or more people to get familiar on the tool

Devops Mastery - Episode 14 Configuration Management - DevOps Tools

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 has to do all the work polling they tend to have more complex to scale. They also can require more risks to take because you have to allow more ports through your firewall. Hybrids allow you to deploy the tool in different ways dependent on the security requirements. So for medium and large companies they tend be a better choice.
How does reporting work? This is what you need the tool to do so paying attention to it is critical. The tools vary widely with the number and type of standard reports they have. They also vary on how easy it is to do custom reports. In more and more cases monitoring tools are pared with a reporting system to handle this issue. Writing custom reports can be as simple as a gui interface. They can be as difficult as a DSL(Domain Specific Language) or traditional programming language to create the reports. If your business needs reports from your systems be sure to confirm that you can create the reports that your business needs to meet it's needs. For instance, can you easily get a report to tell you how many people failed to sign up for your mailing list? Can you tell where people are stopping or failing to complete an action.
Does it do alerting and if so how can you be alerted? Alerting sounds like a no brainer but not all tools do it. Some tools are just built to display a set of stats for people to analyze. Which means they are normally easier to deploy and configure. At the other end of the scale are tools that will try to predict failures and alert you before the problem happens. This sounds great, and is cool, but you need to know a lot about your environment so that you can set the boundaries around good and bad events. That means that it will require a lot of time to tune properly to remove false positives. Also can an alert trigger an action? If it can then you can automate simple things and free a human to sleep or do something more productive. If it can tell you that the disk is filling up can it do the steps your team would do to free up space? This will help a lot with the work life balance.
What dashboards are available out of the box? Can you customize them simply? Most of the tools come with a set of what are called canned dashboards. When you are starting off with monitoring tools it's best to choose a tool with as more than less as long as they tell you something. If the tool has a great dashboard for monitoring Java Applications but your company writes it's apps in Ruby then what good is it to you? All of them will let you customize these dashboards. You can roll up the stats so you can show the entire set of a stat in an environment(Development, Test, Production) in one chart. Be careful though as Techs we love our data and chart customization can get out of hand. Over time you will want to add custom dashboards to make it easier to troubleshoot your devices.
How resource intensive is it on both the server, network, and clients being monitored? This is another one of those it depends discussion. If you are only monitoring a small number of things(computer, network equipment, etc) then this is less of a concern. You always need to be concerned about this because your first instinct is going to be to monitor everything. We can both from a device and data point perspective. I have seen, and caused, situations where we have monitored ourselves to death. For instance, at one company where we had limited bandwidth to our remote sites, we overwhelmed the network with just monitoring traffic. There was no bandwidth left for little things like file transfers and pulling up the company intranet. The problem with this is often until you do a proof of concept with the tool you may not be able to answer it. As a general rule agent based tools can help a lot because they only need to send changes and not everything. In all cases though you need to be sure that you are going to get something from the data you collect. It also makes it harder to filter when the time comes to create dashboards and reports.
The best way to handle most of these issues is to define a set of things you know you need to monitor, things you think you want to monitor, and things you know you don't need to monitor.  Then apply that list to the questions above.  It's a simple flow of can I get the data, can I report on it, can I make a dashboard for it and finally will we have enough resources for all of it. 

The problem I have with this set of tools is that they all have a high level of complexity during the implementation phase. Even the simplest of them can talk several person weeks to get setup correctly and start returning on the investment.  Once you do have it setup you will be amazed at how much it will help you become more efficient.  

You should also be open to deploying multiple tools in this class.  Monitoring a multi-tiered applications completely may seem easy at first but it is difficult to do accurately.   Keep in mind that monitoring anything is a complex process.  It is not uncommon for companies to deploy two or three tools to meet all of their monitoring needs at a complexity level that makes sense for their company.  You may have one tool for monitoring the basic information like disk space and cpu utilization, another to monitor application health, and a third to monitor user behavior.

Ok so what are my recommendations?
Here are a few of my favorites.
Nagios(http://www.nagios.org/) This is where a lot of the following tools started.  It is a great tool but as the number of your systems starts to increase configuration can be difficult to manage effectively.  Which is why the next two started trying to do.

Zenoss(http://www.zenoss.com/documents/datasheet_core_commercial_compare.pdf) - This a freemium modeled application with a community version that does the basics well.  The Commercial version adds more analysis and optimization information. Check the linked PDF for a more detailed explanation.

Groundwork (http://www.gwos.com/pricing/enterprise/) This tool takes a lot of the hard edges off of Nagios.  They continue to add features and let you monitor your first 50 hosts for free with their enterprise tool.

We will be adding a link in the coming months to the site listing as many as we can find and giving our opinion.  These are a great starting point but before you make a decision look at other and make sure they don't better serve your monitoring needs.  

Our sister site has a review of Zenoss and Groundwork that are worth a look even if they are somewhat old at this point.

Devops Mastery - Episode 15 Monitoring DevOps Tools

At the IBM DevOps Symposium I watched as Dibbe Edwards enthralled the audience as she explained how IBM has instituted DevOps and Agile throughout the development cycle. In some cases the results are nearly unbelievable, such as reducing Overall Time to Development from 120 days down to 3 days. I wanted to hear more about how she could create such startling results, so I gave her a call. 

About Dibbe Edwards
Dibbe Edwards is Vice President, IBM Rational DevOps Capabilities  Development responsible for the executive leadership of Rational’s development business covering key aspects of IBM’s DevOps strategy and offerings, including application lifecycle management and reporting, quality and requirements management, systems development and architecture management, SaaS-based offerings, and integration and open software development. Dibbe is additionally driving Rational’s own internal continuous software delivery activities as well as Rational’s on-going transparent development initiative through jazz.net. Dibbe is a frequent speaker at devops events, including recently at DevOps Enterprise . 

She blogs at IBM developerWorks where she most recently authored a blog  about A Day in the Life of an Enterprise DevOps Team.

Dibbe Edwards - DevOps and Open Source at IBM

In this version of our Sound Notes podcast, CST, Dave Prior talks shop with Enterprise Agile Coach, Tim Wise about his experience with DevOps in product development. Listen in as they start their conversation around the buy-in of a pull system, reducing cycle time and the importance of shared purpose and intent in DevOps. From there, they dive in to how an organization can strive for continuous improvement and use a number of different practices, including DevOps and Lean Startup to find their product/market fit faster. 

devops

rxvt