Having just started working for ScriptRock as a software engineer my journey understanding GuardRail and its place in the IT automation ecosystem is just beginning. This places me in a unique position to provide a series of blog posts that will start from the ground up in getting started with GuardRail. Today we'll work through the steps required to connect and scan a Ubuntu linux server using SSH.
"Did you really just say 'thought leader'?"
Everyone laughed. The open space topic we'd gathered to discuss was "DevOps as an Echo Chamber." The room was full of people who wanted faster, more stable deployments, and none of them were getting help from the DevOps blog-industrial complex.
So a cat walks into a bar. No, that’s not right. He walks into a box. The cat gets bombarded with radiation. It used to be a bar but a lot of people died from the radiation so they turned it into a box. Is the cat dead or alive?
If you’re working with IIS 8 then you know that preventing configuration drift is as important as it is time consuming. In the best case scenario you’re monitoring configs daily to keep development, testing, and deployment running smoothly. In the worst case—well, all-nighters make good war stories but aren’t much fun.
To help, we've prepared an automated test of forty-three must-have settings for IIS servers. It's free and takes less than a minute to run. (Yes, it is faster to use GuardRail than to finish reading this article.) If you want to learn more about how to run this scan, you can read or watch the video in our documentation section.
It's a topic that comes up frequently for us here at ScriptRock. Our customers are always keen to know how they can take control and simplify their configuration management processes. We've all experienced at some time or another that issue that was the result of a database migration that didn't complete, a column that has mysteriously changed data type or an old version of a stored proc or view being restored to a new database.
I was perusing through Twitter-land recently and ran across a tweet talking about a DevOps meetup in the Los Angeles area that was underway. And it went on to denote that the first opening question posed to the entire group was: What are the minimum requirements for DevOps? Huh?~!
DevOps still lacks a commonly accepted definition, as discussed recently in the blog post The Problem with Defining DevOps. Kind of obvious in retrospect, but this really complicates meaningful usage of the word, particularly when used outside of the DevOps community.
You know what, I am starting to despair of the IT industry, just a little bit.
I’ve been working in IT for just over 20 years - I was very lucky to ride the greatest wave we’ve seen, the dawn of the Internet (I worked for the largest corporate ISP in the world, UUNET, from early 1996 to 2001), and I’ve worked in the slowest, most immobile companies you can imagine (Investment Banks). And in the last 5–10 years I’ve seen less and less common sense be applied. And now we have this word that nobody can truly define. And it’s creating even more silliness. People are spending energy, lots of energy, debating this phrase and its definition (the irony of this post is not lost on me).
There's an old idea in Hollywood— if you can't pitch an idea in one sentence, it's too complicated. The term "DevOps" is about 5 years old, and the community still has no consensus on what that word really means, even though it's full of thought leaders who'll claim to be able to tell you.
DevOps is a relatively new concept in comparison to Agile development, so it should come as little surprise that IT enterprises have a myriad of experiences and instances of Agile approaches. And there is no need to throw everything out and start over - both Agile and DevOps are complimentary. But what if after careful deliberation inside of your enterprise you've decided to evolve from Agile to DevOps? How can you ensure that you keep all the good things that Agile provided yet apply some of the learnings from the early adopters of DevOps principles? Building a DevOps state of mind requires more than giving developers root, installing a configuration management tool, using a source code repository, and proclaiming ‘yes, we’re a DevOps shop.” At the end of the day all aspects of the people, process, technology continuums get impacted by DevOps. Here are 5 key steps to work through when implementing DevOps in an IT enterprise where Agile rules: