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.
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.
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.
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?~!
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).
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...
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.
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.
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.
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.
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 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.
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.
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:
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.
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.
Information Technology Service Management (ITSM) may not have the sex appeal of Agile or the buzz of DevOps, but it lays a crucial foundation for each within the Enterprise today. So, whether you consider it a necessary evil or the only way to run your IT department, here are a few resources that may come in handy.
Whether a user or not, we all are familiar with the popular microblogging service, Twitter. With over 200 million users, it’s no easy task to maintain their infrastructure. It has been plagued with several outages in recent times including one this week. A product with a die hard user base can face severe backlash for even the slightest of outages.
Here's some of the IT news that caught our attention over the past week
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.
We've been saying it for a while now here at UpGuard but there's something pretty special about Australia's Wollongong when it comes to tech. Talented engineers abound in this not so sleepy New South Wales coastal idyll.