Technology conference season is in full swing, with so many events going on that even large ones like PuppetConf and Amazon Re:Invent have been forced to overlap. While part of the UpGuard team traveled to Las Vegas, two of us stayed in San Francisco for a different style of conference. Far from the madding crowds of general interest vendor-backed extravaganzas, we presented at FinDEVr, a conference with a few hundred people and a sharp focus: improving the technology of financial services.
The way businesses handle the risks posed by their technology is changing. As with anything, adaptability is survivability. When the techniques, methods, and philosophies of the past aren’t working, the time has come to find something better to replace them. Cyber resilience is a set of practices and perspectives that mitigate risk within the processes and workflow of normal operations in order to protect organizations from their own technology and the people who would try to exploit it. This includes all forms of cyber attacks, but also applies to process errors inside the business that put data and assets in danger without outside help.
So I've finally gotten the go-ahead from higher-ups to join the twenty-first century and use cloud hosting. Now I need to prove that running in AWS is not just easier than maintaining our own farm, but more stable and secure. To do this, I need to be able to monitor each of my instances for configuration drift, ensure that they are properly provisioned, and maintain visibility into dependencies like load balancers and security groups. Fortunately, UpGuard provides all of this information, so even if something were to go wrong I could catch it before someone else does.
At the start of 2015, Gartner predicted that DevOps adoption would evolve from a niche to mainstream enterprise strategy, resulting in 25% of Global 2000 companies drinking its Kool-Aid by 2016. And while the hype—tempered by the realities of implementation—has more or less died down as of late, the methodology's value to enterprises is no longer a debatable matter. Here are some highlights from 2016 detailing how the year panned out for DevOps and its practitioners.
This is not an opener for a sex-ed public service announcement, but in fact the million-dollar question for today's enterprise CISOs and CROs: which vendor in the supply chain will prove to be the riskiest bedfellow? With 63% of all data breaches caused directly or indirectly by third party vendors, enterprise measures to bolster cyber resilience must now include the evaluation of partners' security as part of a broader cyber risk management strategy. Easier said than done: most third parties are unlikely to admit to their security shortcomings, and—as it turns out—even if they did, most firms wouldn't believe them anyway.
Chances are you’ve browsed to an online IT community looking for information about a technology. But taking full advantage of them means understanding how they work and what they can do for you. Interaction with a tech community usually happens for one of three reasons:
Methodologies and frameworks may come and go, but at the end of the day—tools are what make the IT world go 'round. DevOps is no exception: as the term/practice/movement/[insert-your-descriptor-here] rounds its 6th year since entering public IT vernacular, a bounty of so-called DevOps tools have emerged for bridging development and operations, ostensibly to maximize collaborative efficiencies in the IT and service delivery lifecycle. Subsequently, a common issue these days is not a dearth of competent tools, but how to integrate available tooling into one cohesive toolchain.
Though the widely publicized failure of the ObamaCare website (a.k.a Healthcare.gov) back in October of 2013 has all but faded from memory, the public sector’s persistent lag in technological innovation coupled with recent calamitous data breaches means there is no shortage of press fodder for critics. What will it take for the U.S. government to transcend its current dearth of agility and innovation?
The Ponemon Institute just released some unsurprisingly bleak findings in its annual study on healthcare data privacy/security, including data showing deliberate criminal attacks now accounting for most medical data breaches. The report goes on to illustrate how the healthcare industry— sitting on a treasure trove of valuable data— is ill-equipped to counter these attacks. Perhaps forward-thinking enterprise healthcare leaders should start considering DevSecOps as a viable strategy for surviving the perils of the information age.
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.
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?~!
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.
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.
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.
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.
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?
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.
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.
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.
Gmail is amazing, but it isn't perfect. In both 2014 and 2016, the popular service suffered severe outages.
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.
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.
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.
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.
At UpGuard we've got many decades of experience in large enterprises and are very familiar with the sorts of problems that arise in those sorts of environments. Even for those who have lived through it though, it can be hard to explain to people who haven't. That's why we require all our new employees to read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and George Spafford. It does a great - and surprisingly entertaining - job of describing these issues. It also explains how the lessons learnt from years of Lean Manufacturing apply directly to IT. We know that no tool is a silver bullet, but if the employees at Parts Unlimited had UpGuard then it may have been an entirely different story. I've chosen some key excerpts from the book so that we could see how things may have been different.
What is Quality Assurance? Well in time honoured fashion I shall quote directly from wikipedia: Quality assurance (QA) refers to the engineering activities implemented in a quality system so that requirements for a product or service will be fulfilled What does this mean for DevOps though? Well the end product is the software or application being provided so most people focus on its requirements when talking QA and DevOps.
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.
You're never safe in Enterprise IT. Just when you feel you've gotten a handle on the last hot topic you're hit with another. SOA, BPM, Agile, ITIL; You feel like screaming "Enough!" but you know resistance is futile. Gartner have said it's important so you know full well that you'll be asked to "do" it by management.
Converging IT development and operations into DevOps have come a long way, and yet, the two should have grown together like Siamese twins. Developers need sysadmins as much as sysadmins need developers. Collaboration is the way winning software and infrastructure are built. And that's all the market wants: effective systems with which to run businesses. DevOps can claim substantial ground today, thanks to the persistence of players from both sides of the sysadmin-developer divide. While the segment is still evolving, various tools have been developed to help the Devs and the Ops collaborate more effectively.
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.
Today represents the hottest time to be in financial markets - nanosecond response times, the ability to affect global markets in real time, and lucrative spot deals in dark pools being all the rage. For companies who do business in these times, it is a technical arms race, worthy of a Reagan era analogy.
Those of us who haven't worked in the Enterprise probably don't know a lot about ITIL (Information Technology Infrastructure Library). ITIL may even be a source of amusement for them. C'mon, they would say, how much practical use can you get from a methodology that is defined through a set of books that is actually referred to as a "library"?
In this blog, we're constantly covering and discussing the concept of DevOps. At this point, most folks in departments related to a company's infrastructure (i.e. Developers, System Administrators) have some understanding of this idea. But where do these people learn about this relatively new and young concept?
DevOps is a concept that has materialized fairly recently, yet is already adored by so many people. Obviously, the fact that it bridges the chasm between software development and operations is pretty exciting, but there seems to be something extra that people love. So without throwing around too many corporate buzzwords (besides “DevOps”, of course), what could that extra something something be?
Many enterprise network workers are now adopting automation technology as a means of completing operational tasks, and of creating a more efficient environment within an IT enterprise. One of the advantages of adopting IT automation is that it helps to deliver optimal IT management, without the need for any significant capital investment.