Whenever there's a lot to lose, UpGuard is the solution to ensure correct configuration state. Often this means working the enterprises in banking, transportation, and ecommerce, but the Internet of Things introduces risks to the most mission critical system of them all: your home.
The fate of CSO John in The Phoenix Project is a good parable for illustrating the dynamic and often conflicted relationship between Security and IT Operations. Security can either become a separate, obscure, and increasingly irrelevant group that everyone else resents–sounds pretty good, huh?–or it can be integrated into broader framework of the development cycle. Security John goes through a mental breakdown before finally understanding how to adapt and survive, but it doesn't have to be that hard.
As a group of concepts, DevOps has converged on several prominent themes including continuous software delivery, automation, and configuration management (CM). These integral pieces often form the pillars of an organization’s DevOps efforts, even as other bigger pieces like overarching best practices and guidelines are still being tried and tested. Being that DevOps is a relatively new paradigm - movement - methodology - [insert your own label here], standards around it have yet to be codified and set in stone. Organizations are left to identify tools and approaches most suitable for their use cases, and will either swear by or disparage them depending on their level of success.
If you're one of the unfortunate ones who woke up to a frantic text from their boss this morning, there's some small consolation: today's OpenSSL vulnerabilities probably aren't as horrific as Heartbleed! Hooray, great job everyone! The bad news is that you still have to patch your environment, and before you can even do that—do you even know what you've got? There's a kind of configuration "fog of war" over IT that's been a fact of life for as long as IT has been around, especially in established environments. Sure, you could manually dig into each machine and run openssl version, or spend the afternoon scripting a solution if you're fancy, but that amount of work will only get you through today. You need to make room in your tool chest for a universal configuration scanner and system of record.
Sarbanes-Oxley (SOX) compliance—it’s like checking for holes in your favorite pair, but with consequences beyond public embarrassment. For publicly traded companies, the ordeal is a bit like income tax preparation for the rest of us: a painful, time-consuming evil that—if not carried out judiciously—may result in penalties and fines. Throw in an additional bonus of prison time for good measure, if you’re a C-level executive and discrepancies are found on your watch. Yes, the SEC is serious about SOX compliance, and you should be, too—especially if you’re in IT.
This week, Apple’s App Store and iTunes Store suffered a downtime of about 10 hours. For the better part of the day, customers were unable to access the stores, purchase music or apps, or make payments using the Apple Pay payment system. The problem has been attributed to “a configuration blunder” of its DNS setup.
Audits are one of life’s greatest pleasures, right up there with root canals and childbirth. Firms love them, too; alongside tax audits-- financial audits, records audits, and compliance audits make life splendid for businesses. Unfortunately, compliance is an unwieldy but necessary evil-- that is, unless you’re America’s 2nd biggest health insurer.
We rewrote the UpGuard agent as a connection manager to reap the benefits of agentless monitoring. Why get rid of agents? Because agents must be updated. They are like a free puppy–it's easy to take them home but you have to feed them, take them to the vet, and clean up after them for years afterward. The new connection manager allows for an agentless architecture while keeping all SSH/WinRM activity behind your firewall. It's fast, light, easy to maintain, and secure.
Microsoft has announced a vulnerability in Samba, the widely used SMB/CIFS protocol for Windows/*nix interoperability. The vulnerability exists in versions 3.5.0 to 4.2.0rc4 and allows malicious clients to manipulate the host such that clients can execute code via a netlogon packet.
We know you're sick of updating OpenSSL so we'll keep this short. There is a new SSL vulnerability named FREAK with a published proof of concept. FREAK affects a significant portion of websites, including big names like American Express and the NSA. Like POODLE, FREAK takes advantage of support for legacy cryptographic protocols.
In Part 1 of this article, we presented an overview of Amazon AWS and UpGuard, and discussed how the two marry the best in cloud computing and DevOps. We also learned how UpGuard is not just the premier solution for configuration monitoring, control and automation of AWS offerings like EC2 and S3, but can also work with any number of RESTful services. But enough waxing philosophical—time to put theory into action. And what better way than to follow a fictional organization as it sets up UpGuard monitoring for its AWS cloud infrastructure?
It's not pleasant to think about, but the fact is that when we go to work we are expected to do things. But what are the things that need doing? If we can answer that question without hours of meetings or dozens of emails we can finish our work and do...other things. UpGuard's new Tasks feature provides a lightweight project management system designed especially to maintain quality in a rapidly changing environment.
In July of 2014 Jon Hendren, also known as @fart, began a journey to become a DevOps thought leader. Using his audience of 70k+ followers on Twitter, he spread a simple message: Jon Hendren is a DevOps thought leader.
Over the years, Amazon has become the poster child for all things cloud-related, and for good reason: as one of the initial vendors to embrace the cloud computing paradigm, they were the first to offer widely accessible commercial cloud infrastructure services when it launched EC2 and S3 as part of AWS back in 2006. And now, almost a decade later, the tech giant continues to dominate with a 27% market share of the cloud services market. It's therefore not surprising that for many, Amazon comes to mind first when thinking of cloud computing.
When we set out to create a cloud-based tool for configuration monitoring, we used the tools we knew and wrote UpGuard using JRuby. For our application, JRuby had many good qualities: getting started only required a one line install, the agent only needed to talk out on port 443, and it was platform agnostic. Using JRuby we demonstrated the value of system visibility, attracted our first cohort of customers, and raised the funds to expand UpGuard. Now we're not only scrapping that agent, we're moving away from agent-based architecture altogether. Here's why.
In a recent episode of the Enterprise Initiatives podcast, our own debonair cofounder Alan Sharp-Paul sat down with host Mike Kavis to talk DevOps, and especially one particularly memorable blog post in which Alan advised that's not wise to look before you leap and "don't automate what you don't understand." That point has been known to cause some contention among certain DevOpserati who often maintain the movement is primarly based on a cultural shift coupled with automation.
This week Qualys announced a vulnerability in certain versions of glibc that is now being called GHOST. The vulnerability allows remote execution of code by calling gethostbyname() and is considered critical. We won't cover what others have already said: you can read the original Qualys post here, a summary from ZDNet here, and advice on updating your OS version here. If you aren't sure what version of glibc is used on every one of your Linux machines, read on. We have created a one-click solution for validating the security of all your nodes.
UpGuard was initially designed to solve the problems we faced every day in the world of enterprise IT. Technical debt, documentation rot, and configuration drift consumed untold hours of our lives. UpGuard was designed to make those problems a thing of the past.
As a trusted partner of financial institutions, healthcare providers, retailers, and businesses of all kinds, we take seriously our responsibility to handle your data securely. UpGuard's container-based architecture, compliance testing, encryption at rest and in transit, and bug bounty program bolster our code-level security. But there is always the human factor, and for that we have two factor authentication.
There's no doubt that in 2015 DevOps is real, and strong, and it is your friend. If you aren't investing in DevOps now, you should be. Ask anyone, or just be quiet while they yell at you, and you'll hear that you need DevOps. We can get behind that to a certain extent. We love the principles of DevOps, we take it seriously in our own development practices at UpGuard, and we design our software to be equally usable by Devs and Ops to solve their shared problems. We've been listening and contributing to the DevOps conversation for a few years. Here's the problem: almost nothing has changed in that time.
Email is a mission-critical application that is relied on to power business communication and collaboration capabilities on a day-to-day basis. It is a vital component of modern business and being able to send and receive email securely and reliably is of paramount importance. If you were to make a list of applications to track and control configuration changes of, email would be at the top of that list.
We've seen a landslide of vulnerabilities announced in the last few months, from ShellShock to Poodle, and it looks like that trend will only continue. The discovery of a critical vulnerability in Windows SChannel–and the even worse problems introduced with a hasty patch–has added a heap of unplanned work for Windows IT pros. UpGuard provides a really easy way to validate that the update has been successfully applied and the registry keys deleted. In addition to giving you validation that patches have been applied now, our Schannel check can be run automatically to protect against regressions.
UpGuard attended the DevOps Enterprise Summit recently, and we had a blast. We talked to people non-stop for three days, gave countless UpGuard demonstrations, caught a few talks, made some new friends, and learned a lot from attendees about the kinds of challenges they face implementing DevOps. (And hey, did you guys try those breakfast burritos they had on day 2? Delicious.)
A vulnerability was recently announced by Google, named POODLE, which targets SSLv3 connections. SSLv3 is an older encryption protocol in the SSL/TLS family. Most modern browsers default to newer versions of TLS instead of SSL, e.g., TLSv1.2.
News about the major bash vulnerability dubbed Shell Shock is reaching far and wide at the moment, and for good reason — its effects have the potential to reach even further than its distant cousin Heartbleed had previously. IT departments have been scrambling not only to patch machines, but to even find affected machines on their own networks. As config monitoring becomes commonplace, however, today's headache will probably be remembered as something that could've been just a simple nuisance. While both OpenSSL (responsible for Heartbleed) and the bash shell (where Shell Shock gets its name) are found in datacenters and businesses in every corner in the world, that's where the similarities end. The mechanisms exploiting the two vulnerabilities are entirely different, despite the tech media continuing to compare the two.
Some people, we won't say who, have taken to poking fun at the idea of thought leadership in DevOps. We'd like to set the record straight: here at UpGuard, the only problem we have with thought leaders is that there aren't enough. Since we believe in continuous improvement, we've taken the first step to addressing this issue. With our elegant "DevOps Thought Leader" shirt anyone can be part of the DevOps intellectual elite.
When you want to win, you don't attack where your opponent is strongest; you hit them where they're weakest. Quarterbacks throw to the receiver covered by an injured corner, bike thieves look for the bike with the weakest chain, and lions drag down the wildebeest at the back of the pack. The larger the surface area, the more likely there is to be variation in the strength of defense, and the larger the difference between the strongest and weakest points.
In theory, DevOps is good for every business. But if there's one thing I've learned from talking to people in the DevOps community, it's that theory doesn't always translate perfectly to reality. Theory is an advertisement; reality is a data set. That's why UpGuard partnered with Microsoft to sponsor a DevOps study from Saugatuck Technology.
There’s no right place to start with DevOps, but there are reasons that different people choose to start. There are also ways of communicating that make it more likely to take succeed in your organization. Being aware of the people you are talking to and the processes they work within can make your DevOps experiments more likely to grow into a business-wide culture.
Imagine this — you're rolling out a new version of your web app. Works great in the dev environment, and it's been signed off on in staging, so it gets rolled out to production. Things seem fine, so you call it a night. Then the support requests begin flooding in. Something's broken somewhere, and it's not immediately obvious how. Performance monitor shows the machines are running well, so it can't be that. Ah well, better crack one of those neon-colored energy drinks, it's time to roll back and log into these machines to look through logs and config files for a potential cause. "How could this be happening," you ask, "I mean... these machines are all configured the same, right?"
Today we're proud to show one of our newest features to UpGuard: support for your CloudFlare powered website. As a next-generation CDN (Content Delivery Network) CloudFlare purports to make your site faster to load, optimize your content, provide a swathe of ridiculously powerful and easy-to-understand security mechanisms, provide exclusive analytics insights and even has an app marketplace. To give you an idea of just how big this Cisco combatant has become: As of 2016, CloudFlare delivers over 1 trillion page views per month The company has at least half a million customers. Claims to have protected those customers from hundreds of billions of incidents Adding your CloudFlare site to UpGuard is easy and enables you to discover, track and control all of your CloudFlare DNS and Zone configuration settings including A, CNAME, MX and SPF records.
Having just started working for UpGuard as a software engineer my journey understanding UpGuard 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 UpGuard. 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 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. A proactive approach is much better. UpGuard automates configuration testing at scale, to find out if your IIS servers are hardened and as expected. We'll look at how UpGuard can help with these five major problems as an example of what we do. Here are the top five critical configuration problems we see on IIS servers and how we fix them.
It's a topic that comes up frequently for us here at UpGuard. 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:
The rise of DevOps teams is upon us. The most recent State of DevOps survey found that 16% of respondents were part of a DevOps department with 55% of respondents self-identifying as DevOps engineers or systems engineers. Interesting. And if you simply Google ‘DevOps jobs’ you get over 4.5 million hits. So like it or not, this DevOps thing is going mainstream.
Most leading IT enterprises have some form of Agile development in place in their organization. Thereby, many organizations, websites, blogs, and companies exist to provide information about and support for Agile development. Here is a list of 10 key online resources to support your Agile journey.
Just like just a few years ago when we were in the early days of the cloud, we’re in the early days of DevOps. The DevOps Summit had by my estimation 50-100 people talking DevOps this year and I would imagine this will exponentially increase over the next few years as this topic continues to turn IT on it’s head. It is the shiny new toy for Enterprise IT! I was thankful to have the opportunity to be there and hear some of the best and brightest. Here are a few of the things I heard.
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.
Here at UpGuard, we like to look at DevOps through the lenses of Collaboration and Automation. Almost all vendors in the DevOps space focus on the latter. We've written about how this creates Zero Sum DevOps and how these 'pockets of automation' can lead to silos of expertise around specific tools which is counter to DevOps principles to begin with. Furthermore, we've have talked about how there are 3 Reasons IT automation tools suck at collaboration.
DevOps is awesome. Or at least the promises being made with DevOps are: faster deployments….more stability, resiliency & availability….save tons of money through automation….and make IT more relevant to the business. I definitely can understand why there is such tremendous interest in DevOps. Break me off a piece of that!
It goes without saying that automation in the enterprise is critical to keeping up with today’s dynamic business demands. Unfortunately, automation isn't a set-it-and-forget-it process. You need to carefully monitor the environment to know exactly how much to automate and when to adjust for environment changes. To exasperate the issue, the concept of DevOps is still confusing to many and some still inappropriately equate DevOps to automation. But that isn’t stopping leading enterprises to create automation initiatives, have DevOps skunkworks projects popping up, and to name whole teams DevOps for the sake of it.
"The new phone book’s here! The new phone book’s here! Boy, I wish I could get that excited about nothing. Nothing? Are you kidding? Page 73 – Johnson, Navin R.! I’m somebody now! Millions of people look at this book everyday! This is the kind of spontaneous publicity – your name in print – that makes people. I’m in print! Things are going to start happening to me now." - The Jerk
For the past 3 months I've been publishing a series of posts around DevOps culture and lessons learned from Patrick Lencioni’s leadership book The Five Dysfunctions of a Team - A Leadership Fable. As much information as is contained here, the reality remains that teamwork ultimately comes down to practicing a small set of principles over a long period of time. DevOps success is not a matter of mastering subtle, sophisticated theory, but rather embracing common sense with uncommon levels of discipline and persistence.
This is the fifth in a series of posts around DevOps culture and lessons learned from Patrick Lencioni’s leadership book The Five Dysfunctions of a Team - A Leadership Fable.
It is almost summertime, so time to dust off your reading material and cozy up with a good book. Recently I asked our expert panel from our most recent DevOps webcast what was their number one resource they would recommend to a friend if they wanted to brush up on the ins-and-outs of Enterprise DevOps. And in truth, they had a hard time narrowing it down to just a few. But if you're looking to stock up your bookshelf on all things DevOps then you can't go wrong with this list of the Top DevOps Reading List.
As it has been said many times: DevOps is not a technical problem, it is a business problem. The struggle for a large, entrenched Enterprise IT shops can't be underestimated and the legacy factor has to be dealt with (aka. why fix something that isn't broken). However, there is mounting evidence to suggest that independent, discrete teams are in fact becoming more common in these large Enterprises. While the fully-embedded model (sometimes called NoOps because there is no visible/distinct Ops team) that the unicorns have deployed work for them, a more discrete team to learn how to 'do DevOps' makes a lot of sense for the larger Enterprise.
As IT managers and engineers, we can sometimes get so deep in the details of what we do that we struggle to answer the simple questions for our user base and the higher ups. Sure, we can write scripts to automate builds and we can train users on the tools to implement configuration management, but we can also freeze when asked why organizations should have configuration management teams, processes and tools. If this has ever happened to you, remember that you’re not alone.
For those of you who follow us more regularly here at UpGuard, you're preconditioned to know that we have a wicked sense of humor and love to have a good time. This week anoints ChefConf as the center of the DevOps universe as it brings together the who's who of thought leaders and practitioners. We thought it might be fun to play a friendly game of DevOps Buzzword Bingo during the event to entertain those in attendance and keep you on the edge of your seat waiting to fill out your card.
I recently had the opportunity to sit down with Mike Kavis (@madgreek65), VP/Principal Architect at Cloud Technology Partners, in preparation for a webcast we’re hosting next week and asked him a few questions. He was kind enough to entertain my line of questioning and provide some of his thoughts. If you don’t know Mike, you should, but here is what you need to know...
We received a lot of positive feedback regarding our last article on Controlling SQL Configuration Drift so thought it might be a good idea to continue along that same theme of analysis and follow it up with an article about DNS configuration and some simple steps you can take to prevent configuration drift.
This is the fourth in a series of posts around DevOps culture and lessons learned from Patrick Lencioni’s leadership book The Five Dysfunctions of a Team - A Leadership Fable.
Many large enterprises over the last decade made a deliberate shift to an agile development process as a response to the ever-changing demands of the business. One key tenet of the agile development process is to deliver working software in smaller and more frequent increments, as opposed to the the “big bang” approach of the waterfall method. This is most evident in the agile goal of having potentially shippable features at the end of each sprint.
If you do not feel you have a good handle on all the ways DevOps can benefit your enterprise and bring positive return on investment, you are not alone. While the concept of DevOps dates far back to 2009 (prehistoric times in our world!), the evolution and implementation of the procedures and tools that facilitate its use are still evolving. As has been discussed countless times - DevOps is not something you buy, it is something you do. And in order to 'do DevOps' you need to connect it to your business in a meaningful way to ensure long-term success. But let's pretend for a moment (shouldn't be hard to imagine) that your non-technical resources / upper-level management is holding out on making any changes that bring you closer to the DevOps principles of collaboration, culture and communication. How do you get them to invest in DevOps in your enterprise?
Trying to translate the concept of Configuration Management for those who do not understand its efficacy is like explaining surfing to an Inuit. It is simply not an inherent part of their culture. Without question, the benefits of Configuration Management can be challenging to grasp to the uninformed. One of the best ways to understand the benefits and use cases is to learn from other enterprise's experiences.
Controlling database configuration drift is a tricky subject. It's a topic that comes up frequently for us here at UpGuard and customers are always keen to know how they can go about taking 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.
ASP.NET Applications get many configuration settings from their web.config or app.config file. Being able to run the same application across multiple environments used to mean keeping control of different copies of the config file to deploy or even worse manually editing the settings after deploying to each new environment. In recent years it has become possible to do transformations of the web.config files at deploy time using Visual Studio. No matter which method you use, deploying to a new environment and detecting drifting config settings has always been a problem. UpGuard helps to quickly and easily detect these sorts of problemsand make configuration management a breeze.
The UpGuard team is thrilled to announce the addition of Kevin Behr (@kevinbehr) to UpGuard's advisory board. You may know Kevin from his pioneering work he and Gene Kim (@RealGeneKim) have collaborated on over the last decade. Behr has over 25 years of experience in business management, technology and thought leadership as a Chief Information Officer, Chief Technology Officer, and Chief Operations Officer. In addition to his leadership roles in public and private companies, Behr also co-founded the IT Process Institute with Gene Kim, and served as its President for the first five years. Behr is the author of five renowned books, most noteworthy as the co-author of The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.
I have a confession to make. My first job in IT wasn't as a rails developer in a hot startup. It wasn't managing cloud infrastructure. It didn't involve cool open source projects or cutting edge technology. Quite the opposite in fact. My first job was a graduate trainee analyst programmer at an Australian Funds Manager. What was I trained on? ADABAS NATURAL. Yep, I was a mainframe developer.
This is the third in a series of posts around DevOps culture and lessons learned from Patrick Lencioni’s leadership book The Five Dysfunctions of a Team - A Leadership Fable.
There has been plenty of discussion as of late regarding whether the DevOps movement has left the “enterprise” behind, plus where automation and the cloud fits in DevOps. There is more and more evidence that automation creates less collaboration and shows signs of a turf war between the chasm of tools that are needed to ‘do DevOps’. In the spirit of trying to address and debunk some of these myths, we asked Kevin Behr, the co-author of The Phoenix Project: A Novel and the VisibleOps Handbook to join us in a discussion about some of the trends plaguing enterprise IT as they struggling to align legacy IT infrastructure to business goals while becoming more agile.
Anyone who has been following what we're doing at UpGuard knows that we like to keep things simple. With this in mind, we like to look at DevOps through the lenses of Collaboration and Automation. Almost all vendors in this space focus on the latter. Why is this? Well, automation tool vendors do it by definition. In reality the collaboration angle is avoided by vendors because it is hard. If you're looking to the market for assistance in "doing" DevOps then you'll be drowning in offers for help with automation. Help with collaboration? Not so much.
Automation. If you're somewhere on the DevOps spectrum then it's surely good for what ails ya. The answer to all your problems. For many it defines their DevOps journey, its destination representing the promised land of stable environments, consistent builds and silent pagers.
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.
One of the easiest ways to build applications programmatically into containers through Docker is to use a Dockerfile. Dockerfiles are the Makefiles of the Docker world. A ton of blog posts and tutorials have sprung up over the last few months about how to set up Docker, or how to set up a LAMP stack and even a LEMP stack in Docker.
We've been working with a lot of Windows shops recently and IIS configuration seems to be a big pain point for many enterprises. Other than a brief stint in mainframe purgatory after university, I started life as a .Net developer and these conversations reminded me of my fun with IIS back in the day. In reflecting on this, I realized that the developer/operations interaction around IIS configuration is a near perfect example of the type of conflict that gave birth to the DevOps movement.
I shouldn't have to explain the concept of configuration drift to most of you, but just in case, it is the phenomenon where running servers in an infrastructure become more and more different as time goes on, due to manual ad-hoc changes and updates, and general entropy. If you're more of a visual learner, I strongly encourage watching this video from Sesame Street.
DevOps and I sort of have a love/hate relationship. DevOps is near and dear to our heart here at UpGuard and there are plenty of things that I love about it. Love it or hate it, there is little doubt that it is here to stay. I've enjoyed a great deal of success thanks to agile software development and DevOps methods, but here are 10 things I hate about DevOps!
DevOps is a human problem and a leadership problem. Building a DevOps culture 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. However, there is little doubt that the people aspect has the most to gain (and the biggest challenges) for anyone who is considering, or already on, the journey to becoming a DevOps ninja.
It is no secret that we here at UpGuard love DevOps and we're not ashamed of it. I know that opinions vary as to what exactly DevOps is or isn't, but the more important part of the movement is whether we as individuals want to push the limits of what we thought was impossible only just a few years ago. We've been 'doing DevOps' for some time and have a cautionary tale to tell as well, but we believe that DevOps can be transformational for IT enterprises and advocate for organizations to activate DevOps in their businesses. I know how we all love lists, so here is my Top 10 Things I Love About DevOps:
I always love going into those meeting rooms where there are different color post-it notes all over the room that looks like a 3M sales rep threw up everywhere. For the longest time I just considered it one of those strange things R&D did. Then one day I was extremely early for a meeting and actually got to spend some time studying what was cluttered all over the glass wall and I began to realize there was a definite method to the madness. This Kanban board concept wasn't just for the engineers, it was for everyone to see where work was being performed and its status. I loved the visual nature of it, and the fact that I could get accurate information without reading release notes or technical requirements documents was refreshing.
Update: This is a preserved post detailing new (at the time) UpGuard product features, enhancements, or tutorials. The screenshots below may be out of date and/or make reference to GuardRail or ScriptRock—old names for the same great product. There are also many newer features that will drive you wild. Node Groups A Node Group is a way of logically grouping Nodes with common functionality. Instead of managing the same set of Policies on each Node you can now manage one set of Policies on the Node Group that will automatically get applied to any Nodes in the Group. Their use is best highlighted with examples. All of your Linux servers might need to comply with an underlying security policy, group them together using a Node Group called "Linux" and apply your security policy there. Your front-end web servers are identical behind a load balancer, add them to a Node Group called "Front-end Web Server." How you organize them is up to you, they can be as general or specific as you like.
So you do a bit of IT automation. Maybe you throw in some functional testing for that IT automation too. You have monitoring. You have a top notch engineering team. You're doing enough then, right? Nothing could go wrong?
My mom used to tell me 'quality over quantity' back in high school when I was dating girls. Of course that meant that I completely ignored her and would date a girl if she was breathing. What in the hell would you expect an awkward 17 year old boy to do?! I've heard that same sentence used in lots of other ways too: when writing, when speaking, when eating, when working out, and so on. What does that have to do with DevOps? As I continue on my journey through the DevOps movement, it seems to me that we have a bit of a conflict here - the goal is to release at a higher velocity (quantity) with well tested code (quality). Is this really possible? I know that some of the 'high-performers' like Amazon, Etsy, Flickr and Netflix are proving that it can be accomplished, but I keep wondering if slowing down can actually help us deliver more extraordinary things.
We've all been hearing a lot of chatter in the media, in tech-geek circles and everywhere else you go in your daily life about Bitcoin. There was a really interesting OpEd piece in the NY Times yesterday from Marc Andreessen entitled Why Bitcoin Matters that essentially anoints Bitcoin as the greatest invention since the wheel. If you still are not clear as to what Bitcoin is, I would highly suggest watching this video that does an effective job of describing it. So if Bitcoin is the greatest invention of all time, why is it so hard for everyone to understand it, why does it have different definitions depending on who is talking, and why in the hell don't I own any?!
I've been thinking a lot lately about the intersection of DevOps and Information Security. I'm definitely not the first to have considered the implications, but I am undoubtedly a complete cynic when it comes to InfoSec and how it can align itself to the DevOps movement. Why am I cynic you may ask? Well, I spent almost 10 years in the security/governance arena interacting with CISOs and their teams trying to help them 'reduce risk' and 'pass audits', but I've watched countless organizations fail miserably. What is the main reason why? Because the business fails to see the value of security and doesn't understand it. Better said - the business invests in what the business understands.
You may have already heard (or experienced) that Dropbox suffered an outage late last week that took the popular file-sharing service offline for 2.5 hours with some services being out the entire weekend. It was recently reported by Dropbox on their blog that they were trying to upgrade some servers' operating systems Friday evening in "a routine maintenance episode" when a buggy script caused some of the updates to be applied to production servers, a move that resulted in the maintenance effort being anything but routine.
Many of the darlings of the technology universe have adopted DevOps as their approach, are pushing boundaries once thought untouchable and realizing tangible business benefits as a result. The 2012 State of DevOps Report states that high-performing DevOps shops can ship code 30x faster with 50% fewer failures.
We all know that DevOps is the glimmer in our executive's eye, the savior that will solve world hunger, and the most important thing to happen since the wheel was invented. But all joking aside, there is little doubt of the business benefits it can bring to organizations big & small. So now what?! You've decided (or been told) that DevOps is critical to your 2014 success, but where do you start and what are the foundational elements you must work through before claiming victory? Here are 4 prerequisites for DevOps success that you can use as your blueprint to making sure you achieve your business objectives.
Michael Davis over at InformationWeek just wrote a compelling article on DevOps and some of the mixed results that people are understandably getting into. There are a number of very interesting results that he shares as part of their DevOps survey including:
Wow! 2013 is over, done, kaput. It's hard to believe. Time flies when you're having fun (or building a business). Now is the time to look back though and reflect on what 2013 meant for DevOps, myself and UpGuard. This post will by no means be exhaustive. It's written through my eyes and based on my experience, and my head has been down working for large chunks of the year. I'll add an additional warning that it will be a little tongue in cheek. I make no apologies for that ;)
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.
Tonight I gave a talk on comparing containers and generating Dockerfiles. Instead of providing the slides, which are pretty lame by themselves, I thought I'd write up the talk in a proper context. UpGuard has a number of use cases, one of which highlighted for the talk was migrating the configuration of environments from one location to another. Traditionally we have helped some of our customers scan their configuration state and generate executable tests based on those configuration items as well as allow scanned configuration from multiple machines to be compared.
There's a certain something in the air within the DevOps community right now. The movement is, to a certain extent, becoming a victim of its own success. For where there is buzz in tech, there is money. And where there is money, there are recruiters, there is marketing, there are misinformed and over-simplified tech articles and, let's face it, there are carpetbaggers galore.
Cyber resilience is a fundamental change in understanding and accepting the true relationship between technology and risk. IT risk (or cyber risk, if you prefer) is actually business risk, and always has been. And the cybersecurity industry, for what it's worth, has generally avoided this concept because it goes against the narrative that their respective offerings—whether it's a firewall, IDS, monitoring tool, or otherwise—would be the one-size-fits-all silver bullet that can keep businesses safe. But reality tells a different story.