Rugged DevOps is a method that includes security practices as early in the continuous delivery pipeline as possible to increase cybersecurity, speed and quality of releases beyond what current DevOps practices can yield alone. (1) “Rugged “describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure and resilient software. (2) As business increasingly relies on agile software development, the absence of matching fast-moving security methodologies in the delivery pipeline will essentially increase the risk of a security breach or a cyberattack. Security staff must be imbedded into cross functional teams to ensure a more sustainable and less risky continuous deployment value chain (continuous integration, continuous delivery and continuous testing). The bad guys have already acquired these skills and the use of automation to engage in a continuous attack on our defenses. Security was named

A short while ago I was asked this question from one of our reader: “ I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?”   I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes? Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warranty they are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM pr

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.” Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ( (formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt. The discipline of SRE can begin to reduce this dilemma by

What isn’t? With the internet of things there are so many options available to consumers that were not available even one month or one week ago.   With technology and job role functions evolving so fast, the best way to stay current is to become educated.  Here are just a few bits of interesting information. New for Every Day Consumers: In a  recent update Google’s Virtual Globe has introduced a feature called "Voyager." No longer will you be limited to only exploring places you've heard about, nor will you have to resort to randomly clicking on areas of the planet in hopes of finding a gem. Instead, "Voyager" presents you with dozens of curated journeys around the globe. Each voyage is centered around a theme. “Museums Around the World” will take you to a Street View of museums in every corner of the globe. If natural formations are more your speed, " Earth View " will show you "the most striking and enigmatic landscapes available in Goog

Historically, many companies have had a single strategy for selecting, deploying and managing applications. They have had a defined structure for classifying applications by value or functionality, but failed to recognize that applications are fundamentally different based on how and when they are engaged by individuals and the organization as a whole and the pace at which these tools need to be changed and updated.   Many organizations are finding themselves with an enterprise application strategy that fails to satisfy the needs of the business community, which has often led to underutilized applications throughout their portfolio. Gartner’s Pace Layered Application Strategy is a methodology for categorizing applications based on how they are used and how fast they change.   This strategy helps IT organizations rationalize the use of DevOps practices that ensure a faster response and a better ROI, without sacrificing integration, integrity or governance requirements.   The

I learned about ‘The Diffusion of Innovation Theory’ in a DevOps Foundation training course.  I wanted to get my DevOps certification but more than that to learn about what makes a DevOps initiative successful.   When I mentioned the Diffusion of Innovation Theory to a coworker he said “It sounds like Sheldon talking to Raj on “The Big Bang Theory” TV series.  Although the name sounds Big Bangish the usage of this theory could be the real difference for success in any transformational change including DevOps. To start let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in.   De

Integrating Development and Operation teams as well as other functions that have previously been silo’d is key to any development project for all service providers today.   We hear a lot about this in DevOps training and certification classes.   What about security?  You may have heard the term DevSecOps.  This idea and term was coined to ensure that architects and developers include into our requirements and code those things necessary for security. Design architects will also want to ensure that security is integrated throughout the value stream of development, deployment and operations and it is done in such a way so that the complexity is as transparent as possible to the functional teams involved.   How can we do this without impeding our flow of work?    How can we still be able to meet compliance for legislative, legal or regulatory requirements relating to security? This is where Automation comes in.  Collaboration and measurement are key values but automation is also