Going from nothing to automation using one of the many tools available can be a daunting task. How can you automate systems when you’re not even 100% sure how they’ve been configured? The documentation is months out of date and the last guy to configure anything on that box has since left the company to ply his trade somewhere that will more fully appreciate his Ops cowboy routine.
Puppet Labs just released the 2014 State of DevOps Report. The research team interviewed companies from multiple industries and various sizes, from startups to global firms with over 10,000 employees and had over 9,200 respondents in all. The report shows us that not only is DevOps working within the enterprise, but it is also driving higher employee satisfaction.
I recently attended the 2013 PuppetConf in San Francisco and spent most of the Thursday in what we affectionally call the "neckbeard" session. It was the "Product and Technologies" stream and seemed to be highly tailored to the relative minority of developers at the conference, or at least the people in charge of developing and maintaining the low level detail contained in Puppet manifests. Those at one with the Puppet DSL. As a developer this seemed like the only stream I would be interested in, seeing as four of the other sessions had sysadmin written all over them and the last one seemed to be targeted at use cases for sales people. In fact, one of the other devs here at UpGuard asked us at the end of the first day if we'd been called sysadmins all day. Thankfully, I hadn't. It is also a common generalisation that Puppet is designed for sysadmins, having a model based way of defining infrastructure, as opposed to code based approaches employed by products like Chef. I went into the start of Thursday's talks with this generalization clouding my judgement.
Most Enterprise CMDB offerings are a joke. They've always been a joke. Just another white elephant system sucking time and money out of IT Budgets. What most, if not all, become are simply inventory systems. They're not even good for that half the time.
As there's a lot of interest out there in the various IT automation tools on offer I thought I'd do a series of blogs covering getting started on each. In particular I wanted to put them to the test regarding how simple it is to go from zero to "Hello World" *. This way I get to play the truly dumb user (not much of a stretch, I know), which is kinda fun too.
After taking a week off, the weekly updates are back! Here's some of the news that interested us over the past week:
IT testing automation is an important concern of businesses, and a growing field in which IT professionals are able to make a name for themselves. If you are not already involved in automated IT testing, here are a few of the most important skills to have when holding an automation related position.
It's been really interesting to watch the dramatic uptick in activity around the automation space the last year or two. I don't need to go into too much detail on the benefits that automation offers here; consistency and scalability are two of the more prominent that come to mind. What has struck me, though, is that it feels like the way that companies are going about it is missing a key step.
Upon the application of Chef/Puppet with a view towards the automation of system architecture, it is possible to apportion the systems environment piece by piece and start up applications in a heartbeat. This is ideally the configuration management pinnacle of achievement, encompassing a time saving mechanism, highly replicable, and with unrivaled ability to replicate.
OK, so I was supposed to be blogging this weekend but I was bored of blogging so I instead decided to combine two things I'm terrible at, illustration and comedy, and do a comic instead. I deserve to be punished for this so please, flame away :)
While there are many benefits to cloud computing, one of the major difficulties is migrating from the in-house servers to a cloud computing platform. Configuration issues can develop when a company does not have the right tools, and when it lacks clear communication.
Cloud CMDB - Where to Next? Cloud providers and IT shops must engage in unit testing for infrastructure management. A cloud provider is an organization that provides a component of cloud computing to businesses or individuals. The cost is usually based on a per-use model.
The Sinkhole That is Manual Configuration Testing Testing is a crucial part of software development: it involves the execution of a program with the goal of locating errors. Successful tests are able to uncover new errors that can then be corrected before the software is released.
Testing environment configurations in enterprise environments manually with scripts is difficult, just because there are so many factors involved. These can include applications, hardware, and device compatibility issues that can arise at any point within the implementation, areas which may be difficult to determine in the pre-implementation stage. Worse yet, the larger the network infrastructure, the more time consuming and complicated the test and the implementation processes are. This is when Environment Drift and Stateless Systems can come into play.
Before delivery to the intended party, a system should be tested to figure out whether the requirements set forth in the contract have been met. Configuration acceptance testing is the fundamental means to assuage all doubts that the system will fall short of its intended purposes. It is an essential part of the testing phase of the Software Development Life-Cycle (SDLC), and perhaps the most vital in its category. The way in which the components of the system interact is the sure fire means of determining the susceptibility of the system to frequent errors and ultimately the strength of resistance to its implementation. Configuration acceptance testing is pivotal to the SDLC, and as such will be an integral part of the Application Life-cycle Management (ALM) policy of any firm. It reveals any available bugs and inadequacies in the system, enhancing the process of error correction and formulation of a suitable plan of action in the event undiscovered errors manifest and affect the system after it has been implemented.
This is a pretty common response we get from people we're explaining our product to. There is logic to it but we don't believe it's necessarily reasonable. To illustrate our viewpoint on this we thought we'd paraphrase a conversation we had with a prospective client recently.
You've used Chef/Puppet to automate your infrastructure, you can provision your virtual environment from scratch and deploy all your applications in minute. It’s magical. You've achieved Configuration Management Nirvana. What you've built is repeatable, saves time, increases efficiency and removes human error.