Tag: devops

  • Chevy and DevOps: What the Wi-Fi?

    Chevy and DevOps: What the Wi-Fi?

    In DevOps: Rapid Feedback, Rapid Repair

    I’m sure you have seen it too.  Chevy cars now come with wi-fi. How cool. I want that (and so would my kids). I can only imagine the possibilities.

    Screen Shot 2015-04-25 at 11.25.49 AM

    But, this is not all about my needs. Chevy and every other vehicle maker wants this too. And not for the reasons that you might first consider. Quickly, let me introduce you to the recalls of today:

    The glitches were related to cars losing power, erroneously deploying airbags, and other defects. This is just a small glimpse of the software recalls that have happened over the past year.

    But more troubling is this form of software “recall” from BMW showing a security flaw that could allow cyber criminals to unlock doors on 2.1M vehicles. Because every one of the 2.1M vehicles has the same defective software part, criminals effectively had access to a skeleton key to every one of them.

     

    http://i2.cdn.turner.com/money/dam/assets/140731164536-car-hacking-distance-1024x576.jpg

     

    In DevOps: Rule Your Supply Chain

    The reality is, that your new car has more software in it than you can image — about 100 million lines of code.  And, as we know, all software has flaws. But who wants to go to a dealer to get a software update? If my car can connect to the internet and update itself, that would save me an unscheduled trip to the dealer for a repair.

    While software updates to cars models in the past were would take 5 years to feed themselves onto the production line, that is now all changing.  For decades, large automakers like Toyota have been applying excellent management process for their entire supply chain.  And with the introduction of wi-fi in vehicles, they are expanding their highly-tuned practices to include their software supply chains. They know where every piece and version of their software is and who owns it. If a flaw is detected (be it quality, safety, security, or another attribute), they will now be able to automatically update that vehicle. Not only can they remove defects, automakers like Telsa are even making their cars faster.

    While many of us outside the auto industry think of these large industrialists as slow moving organizations, the introduction of wi-fi in cars is allowing them to now apply a core principle from the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

    In DevOps: Version Everything

    For those of you in the software industry, this kind of evolution is at the heart of many DevOps and continuous delivery efforts. Automate everything you can. Version everything you can. Deliver fast, improve visibility, and change fast. In many ways, the addition of 4G LTE Wi-Fi in Chevy Trucks means that DevOps has entered into our auto and software supply chains.

    If you imagine an even broader perspective of this wi-fi feature and software supply chain management, the auto makers are now leading the way to expectations of quality improvements in the Internet of Things (IoT). There is not much difference between an internet enabled truck, thermostat or fitness bracelet when it comes to rapidly improving and updating quality, features, performance, etc. (I’ll cover this topic more in future posts.)

    In DevOps: Optimize Your Software Supply Chain

    What have the auto makers learned from the software industry? And perhaps more importantly — when it comes to software supply chain management and continuous delivery — what can we learn from them?


    A final note on software and auto safety:  I am the Cavalry (@iamthecavalry) is encouraging the automotive industry to commit to cyber safety. The movement recently published a Five Star Automotive Cyber Safety Framework (PDF download) and calls for Automotive Industry adoption. Media outlets from across the US and Europe praised the effort and joined in calling for automakers and security researchers to work together to ensure a safe future.

  • DevOps-in-Name-Only? Don’t do DOINO

    DevOps-in-Name-Only? Don’t do DOINO

    Let’s not be ‘that’ guy. And let’s not be ‘that’ organization.

    You know, the one where “DevOps” is some magic pixie dust that we can sprinkle around, and then pat ourselves on the back for being forward-thinking, modern IT managers. It’s actually harder than that. Harder but simpler. Harder because DevOps involves humans. Simpler because pixie dust doesn’t actually exist. (I prefer software instead.)

    There is thankfully a lot of good “devops” software out there. We are pretty proud of ours too but we fully admit that paying closer attention to human factors of DevOps helps ensure that you get the most from your software whether you buy it or build it.

    Respect

    Any “DevOps” organization worthy of that title needs respect and understanding between Dev and Ops. Each brings their own talents, mindsets and constraints. Those other guys generally aren’t trying to make your life difficult just because they can, or because they don’t care. They are making your life difficult because they may not fully understand your environment, your pressures, your management and even the metrics that define ‘your side’. Or maybe they have pressures and constraints of their own. This isn’t a matter of touchy-feely kumbaya. Getting to know and respect each other is actually just good business.

    Communication

    A DevOps organization should also have good communication. Note that I didn’t say lengthy communication or countless tedious meetings. Just good communication. I also didn’t specify whether that should be verbal or written. It just needs to be good and it needs to fit your organization and your environment. Whether you are a multi-national organization with datacenters across the globe or if your entire IT department can fit in one room,

    1. Focus on sharing what is important for your colleagues to get their jobs done.
    2. Make clear what you need or what you need to know from them so that you can do your job well.
    3. Don’t hide that key nugget or even that bit of bad news under mountains of data. Over-sharing is as destructive as withholding key info.
    4. Say ‘thanks’, ‘good job’ and ‘sorry’ every now and then to your colleagues in Dev/Ops.

    Process

    A) People learn by doing, more than being talked at. B) What gets measured, gets done. So find something that works for your organization and your culture to nudge the DevOps mindset that you are seeking. Maybe it’s a job rotation program (even for a couple of hours per week). Maybe it’s paid company lunches. Or working in the same physical area. Perhaps it’s having Dev report on traditional Ops metrics and vice versa. Or maybe it’s sharing the risk and rewards of holding Dev and Ops accountable for combined DevOps metrics. The point is to foster team performance in a we’re-in-this-together mindset.

    DOINO

    The bad news is that #DOINO (DevOps-in-name-only) is worse than useless. DOINO can cheapen and make a joke of a pretty good concept that should be helping IT teams accomplish more and enjoy their jobs while doing so.

    The good news is that you don’t have to be perfect at all of the human factors of DevOps to make real progress. Your improvements may be sparked by formal cross-functional meetings, informal sharing of more beers or even (my favorite) by clever new software that automates the hell out of tasks you had previously taken for granted. The important thing is to just get started.

  • George Jetson Automation: Chasing the Dream

    George Jetson Automation: Chasing the Dream

    “His job was one simple thing—press a button. That’s all he had to do; press one button and sit back.” – Joe Barbera

    I wanted to be George Jetson when I grew up. Back in the days when watching Saturday morning cartoons in footed pajamas was the high point of my week, George’s life looked as sweet as a bowl of Super Sugar Crisp cereal. Flying cars, robots, and a two-hour-a-day, three-day work week lightened even further by 100% push-button automation.

    jetson_button1

    Contrariwise, my first tech job out of high school was a classic study in manual labor. From 9pm to 5am, I was solitary “Night Backup Operator” for a small data storage company, lone man responsible for continuously swapping reel-to-reel tapes on and off a literal wall of old magnetic drives.

    reels

    It was repetitive, monotonous and boring, and the tapes were prone to jamming and tearing. A lot.

    tapes

    One night I was thumbing through a tech catalog and came across a listing for a new cassette backup system. I mentioned to my boss the following day that our reel drives could potentially be replaced by a unit the size of a large book. He took it to heart, made a purchase, and one evening shortly afterwards I came to work, popped in a blank cassette, hit a button, and kicked back for the next eight hours as 100% of my work was done for me. It was a George Jetson moment. The future had finally arrived. I was blissfully complete.

    They fired me, of course. It actually took them a few weeks to realize that I’d been automated completely out of a job. To their credit, they were appreciative and regretful in parting, but there was hardly any point in paying me to sit on my can reading pulp SF for eight hours every night.

    Regardless, I’ve been chasing that George Jetson moment ever since.

    The magic behind the button

    In the decades since, with a number of (slightly more professional) IT automation projects behind me, I’ve discovered that the “automate-everything” button is usually a lot tougher to achieve, and near-impossible to buy off the shelf. To even get close, you often end up building a significant amount of infrastructure up from scratch.

    But say you could buy a “George Jetson” button; a self-contained, perfect automation solution off the shelf; what do you look for? Setting aside the nuts and bolts of a specific IT problem or project, what does an “automate-everything” button need to do, in essence?

    1.   “Do No Harm”

    At the first sign of an incident, Mr. Spacely (voiced by Mel Blanc, “Man of a Thousand Voices”) pops up and begins motivating with the bellow “JETSONNNNN!”. (I once worked outage calls with an IT director who had the same management style, I kid you not). We don’t want this to happen. So our “automate-everything” button needs, first and foremost, to mitigate risk.

    Security should be the first consideration in risk management, yet it’s an area where (oddly enough) a number of automation solutions fall flat out of the gate. Managed user accounts (ideally, integration with established account management systems), role-based permissions (for pushing the button in various situations, IT environments, and scheduled times), and sensitive information handling should all be covered.

    The ideal automation solution’s back-end infrastructure should be robust, flexible, and professionally engineered. If any pieces are open-source or community-designed, what they do and don’t do should be well-documented, including an understanding of potential situations likely to result in unintended consequences.

    We also want the automation button, once pushed, to never perform the action again if there’s no need to do so. This is idempotence, a valuable concept that’s been around for a long time but has risen to prominence over the last year. Idempotence is particularly important once you start to consider auto-remediation (why push the button manually if it can run automatically?), and efficiency (why spend effort building an automation action that can only be run once?).

    2.   “CYA”

    “Cover Your Automation.” George isn’t particularly smart for a computer operator. But maybe he doesn’t need to be. Let’s say he’s supported by a lower floor full of smart engineering robots. The robots set up the automation actions and push them into an approval queue with just enough information to make a decision on whether an action is needed or not.

    George evaluates each situation and pushes the button if everything looks good to him. Now, the “automate-everything” button becomes more of an “approval” button in a formal change management system. There might be more approvers besides George, each laying eyes on the proposed automation action and passing it along to the next approver as appropriate.

    Most operators aren’t as dumb as George, but everybody has “dumb moments”. Change management needs to be a core part of any automation system.

    Accountability supported by thorough logging is also a key “CYA” aspect of the ideal automation system. “What” happened, “when” did it happen, “who” did it, and so on… if your automation system doesn’t track all essential information, you might not be able to return to your job after Spacely mistakenly fires you.

    3.    “KISS”

    “Keep It Simple, Stupid.” Dealing with complex automation workflows is tricky if they involve a lot of step-by-step actions, as they traditionally have in the past. When complexity clashes with modern, large-scale IT environments, situations arise that are literally impossible to manage manually. “Scale x Complexity > Effort” is the equation desperately slashed across whiteboards in planning meetings these days. Modern automation systems often attempt to reduce complexity and equalize scale through a form of orchestrated states.

    The idea depends on two parts. A desired state is a recent Microsoft-championed concept where the steps required to reach an end result are black boxed in favor of defining a system’s state itself. The usual example: rather than considering a step-by-step recipe for a birthday cake, you describe “a white cake with pink frosting” as your desired outcome and pop your request into an automated system to make it happen. Recent configuration management solutions have made excellent headway in this area.

    But desired states aren’t enough in and of themselves. They almost always need to be orchestrated to reach the final goal. An orchestrated states effort runs more along the lines of: “I need a white cake with pink frosting at the same time as a bowl of orange punch, before the time of the birthday party, but after the house cleaning. Also, yellow balloons.” Real-life IT infrastructure requires at least this level of complexity and timing.

    For a complete “automate-everything” solution, our ubiquitous button needs to orchestrate the states of all necessary systems and services in a way that’s easy for George, our hapless operator, to process, and considers both transitory states and final states as well as the interactions between them.

    jetson_button2

    When evaluating whether an IT automation solution is right for you, you may not be able to find the ideal “automate-everything” button, but make sure you consider it from these three perspectives. The perfect solution may, in the end, just be a dream to be chased by the laziest as we move from one IT automation project to the next. But it sure is fun seeing how close we can come to that blissful, futuristic George Jetson moment.

  • A True Story: DevOps(Sec) Manages Out Elective Risks

    A True Story: DevOps(Sec) Manages Out Elective Risks

    A True Story

    There are over 2000 developers in Bill’s organization.  He is a C-level executive for one of the largest insurance companies in North America. Bill boosted developer productivity by 15% last year after taking a closer look at the company’s software supply chain. And this approach isn’t unique to Bill’s organization.  Many high performance IT and DevOps teams are adopting proven supply chain principles to accelerate software delivery.

    Origins, Quality and Integrity

    The concept was rather simple and straightforward.  Bill’s team recognized that they were consuming hundreds of thousands of open source and third-party software components to build their applications.  But at the same time, they did not apply much scrutiny to the origin, quality, age, or integrity of those components.  Developers simply selected components at-will that met their functional requirements and helped them meet the next delivery deadline.

    Secrets of the Free-For-All

    Deeper analysis of their practice revealed that the free-for-all component sourcing methods were leading to quality, efficiency, and productivity issues.  Here is what Bill found:

    • The company had downloaded an average of 27 versions of over 100 different binary artifacts over a one year period.  Bill knew this meant the quality of their applications was being impacted through the use of outdated software components.
    • The company had also downloaded 13,203 software components with known security vulnerabilities — and 65% of those included alerts earlier than 2014.  Without quality controls in place, Bill recognized they were sourcing in elective and avoidable risks that would impact the integrity of their application, grow their technical debt, and lead to more rework down the road to replace the flawed components.

    Removing Complexity

    Bill decided to take action.  He knew that to accelerate innovation, he needed to remove complexity from the company’s software supply chain.  He enacted three moves to eliminate waste and complexity within the open source and third-party components being used:

    1. Automate the scrutiny of software suppliers to minimize risk and bloat.
    2. Enable real-time traceability and visibility to components used across the development lifecycle, in order to improve response times when defects were discovered – cutting back from days/weeks to minutes!
    3. Reducing complexity, rework and risk by standardizing on specific components types (e.g., web frameworks, logging frameworks, encryption modules), using fewer and more current artifact versions, and managing out elective security risks.

    Want to hear the rest of the story?

    The same principles that Bill applied to his business that boosted developer productivity by 15% are being discussed by Gene Kim (@RealGeneKim), author of The Phoenix Project, and Joshua Corman (@JoshCorman), CTO of Sonatype, on April 30th.  Both Gene and Josh are huge fans of marrying DevOps practices with leading supply chain management principles that enable developers to maximize throughput of features from “code complete” to ‘in production,” without causing chaos.

    If you’re looking to achieve similar goals, be sure to join Josh and Gene for this April 30th, 1pm ET, discussion.

     

    josh corman, gene kim

  • Enterprise DevOps: Standardize for Security

    Enterprise DevOps: Standardize for Security

    Etsy is a shining example of the success that can be achieved with continuous delivery (CD). By 2014 Etsy had doubled its deployment rate, deploying more than 50 times a day. Today the site deploys API changes in 18 seconds and launches a new website every 150 seconds.

    That’s speed, to be sure. Speed that very few enterprises need or want to achieve. But that doesn’t mean that Etsy and CD don’t have valuable lessons for the enterprise, because one of the reasons CD and Etsy succeeds is because of the underlying principle of standardization.  

    Whether it’s standardization of tools or of processes – or both – it is standardization that eventually drives such speed. The use of the same tools and the same processes over and over hones them until they’re an optimized, lean delivery machine. That standardization has other, benefits, too that are as beneficial – maybe moreso – to the enterprise than the speed it eventually brings.

    Standardization of delivery processes in the enterprise, especially when extended to such concerns as security and the network, result in direct and indirect benefits. Directly, standardization allows security and even network infrastructure to ensure that corporate policies are implemented. If all infrastructure – application and network alike – should only be hosting certain services (like HTTP and SSH) and not others, standardization can help enforce that. Template-based (or policy-based, if you prefer) automation along with an “infrastructure as code” approach can assist in ensuring that basic security and network policies are put into place for every application deployed. Customization can (and should) be allowed and encouraged as extensions to the core templates (or policies) deployed during the app deployment process.

    Indirectly, standardization on a common toolset and processes will reduce the stress on network and security operations that comes from trying to implement common policies across a conga line of solutions. There’s no getting around the reality that many enterprises employ sometimes twenty or more “middle boxes” that provide everything from security to monitoring to performance and scalability services. Each one must be provisioned and configured during the app deployment process. This is not a trivial problem. 26% of organizations cited “security policies that are too complex and can’t be enforced with the current network security processes and controls” as a significant challenge in a 2014 ESG survey.  Establishing a standardized template that encapsulates common (required) policy implementations can go along way toward addressing the challenges network security professionals face when trying to secure applications across a growing portfolio of both applications and network services.

    app-cprThis level of standardization is not easily achieved. There is no easy button, and that’s one of the reasons DevOps can be a desirable approach in the enterprise to addressing these kinds of problems. It isn’t just about achieving phenomenal speed, but rather achieving consistency through the standardization of processes and methods used to deploy security policies and controls that can improve the stability and the security of the entire application and network environment.

    DevOps is, in relation to network and security operations, more about CPR for infrastructure services than it is speed. Consistency through standardization. Predictability through automation. Repeatability through templates and by treating infrastructure as code.

    DevOps is an approach to operations and inter-operations that can have just as many benefits in the enterprise as it does for web-scale and startups born in the cloud. The same standardization that benefits Etsy by giving it extreme speed can benefit enterprises by endowing it with extreme security.

  • 31 Reference Architectures for DevOps and Continuous Delivery

    31 Reference Architectures for DevOps and Continuous Delivery

    At QCon London, David Farley (@davefarley77) told the audience that “continuous delivery changes the economics of software delivery”.  I could not agree more.

    If you have been drawn to the evangelists like David Farley, Jez Humble, and Gene Kim, you’ll know that high performance IT organizations are seeing a massive payoff in their continuous delivery investments.  Industry leaders big and small are sharing noticeable results:

    • 8x more frequent production deployments
    • 50% lower change failure rates
    • 12x faster service restoration times when something went wrong

    5 Principles

    How are they achieving these results?  They are following a few key principles that David and Jez outlined in their seminal book, Continuous Delivery (highly recommended).  The principles outlined in their book and in David’s QCon presentation are as follows:

    • Deliver fast
    • Automate almost everything
    • Keep everything in version control
    • Build quality In
    • Empower the team 

    Reference Architectures for DevOps and Continuous Delivery

    In their book, they also provide insight to continuous delivery tool chains and processes which highlight build tools, CI platforms, testing suites, artifact repositories, and many other components. There are numerous examples of reference architectures available, and each of them vary in levels of detail, tools highlighted, and processes followed.  Yet, there is a constant theme among the tool sets: Jenkins, Maven, Nexus, Subversion, Git, Docker, Puppet/Chef, Rundeck, and Sonar seem to show up time and again.

    To help you along your continuous delivery and DevOps journey, I have compiled a set of 31 reference architectures created by users across the continuous delivery and DevOps communities.

     CD and DevOps tool chain

    Each architecture is accompanied by a link to the original presentation or blog where the architecture was referenced to ensure you have access to the full context of the discussion. You can also freely download the presentation from SlideShare where we now have over 7,000 views.

    Offer to help others: If you have a reference architecture to share, please consider posting a link to it in the comments section below.  I am sure others would love to see it and learn from it.

  • 9½ Simple Steps On How To Start With DevOps Today

    9½ Simple Steps On How To Start With DevOps Today

    Isn’t it funny that a lot of people, me included, don’t really know the difference between DevOps and Continuous Delivery? Wikipedia tells that both are pretty much overlapping. In order to continuously deliver one must be familiar with DevOps. Anyway, I will tell you what you can do now to start with DevOps and Continuous Delivery. Here are 9½ simple approaches that tell how you can start immediately.

    (more…)

  • Security and DevOps: the horses are finally here

    Security and DevOps: the horses are finally here

    It doesn’t seem like it was so long ago when it was actually difficult to find enterprises and experts who could speak – from experience – about having successfully managed security in a DevOps environment. Sure, they existed, but they were primarily the so-called “unicorns:” web-based enterprises that had little of the legacy infrastructure in place that also needed to be secured. Enterprises such as Netflix, Etsy, Google, Amazon, and others for who the cloud and virtualization management and DevOps practices are as natural as water.

    Fortunately, we’ve now experienced a year where stories about traditional enterprises having successfully made the DevOps leap are commonplace, from Macy’s and Target and others at the DevOps Enterprise Summit, while Nationwide and many others at IBM InterConnect.

    Like those conferences above, this year the annual RSA Conference (the information security industry’s biggest show), and some of the approximate satellite events this week, will have many sessions relating to DevOps and security. Our own DevOps Connect: SecOps Edition, being held Monday at the Moscone Center, is a daylong event highlighting the intersection of DevOps and information security.

    At DevOps Connect: SecOps Edition there are a number of must see sessions, for me, including David Mortman’s DevOps Myths Versus Real World Realities, Julie Tsai’s Windfall Wins: DevOps Empowers Agile Security and Compliance, and Jez Humble on Continuous Delivery.

    Also, throughout the week there are many DevOps and security sessions throughout the week in application security related tracks. There will be a lot of interesting news and developments coming from those sessions throughout the week.

    Here are some, for those interested in learning more about DevOps and security, that look very worthwhile:

    Continuous Security: 5 Ways DevOps Improves Security

    Joshua Corman, Chief Technical Officer, Sonatype and David Mortman, Chief Security Architect, Dell

    DevOps is upon you and no longer just the provenance of start-ups. Josh and David will discuss how things have changed and five ways security gets better as a result of other teams doing DevOps.

    Enterprise Cloud Security via DevSecOps

    Scott Kennedy, Chief Security Scientist, Intuit; Shannon Lietz, Sr. Manager, DevSecOps, Intuit

    Securing innovation at scale in a cloud environment can be quite challenging. The goal of our talk is to share the lessons we learned about operating under the DevSecOps model.

    How to Avoid the Top 10 Software Security Flaws

    Gary McGraw, Chief Technical Officer, Cigital

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

     Is DevOps Breaking Your Company?

    Elizabeth Lawler, Chief Executive Officer / Founder, Conjur, Inc.

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

      Containers vs. VMs for Secure Cloud Applications

    App developers and PaaS platforms are adopting containers to simplify app packaging, deployment and orchestration. But there has been no pause for thought about security and compliance.

    Participants:

    Simon Crosby – Chief Technical Officer, Bromium Inc

    Christofer Hoff – Vice President and Security Chief Technology Officer, Juniper Networks

    Mark Russinovich – Chief Technology Officer, Azure, Microsoft

    Scott Johnston – Senior Vice President Product, Docker

    How Security Can Be the Next Force Multiplier in DevOps

    Andrew Storms Vice President, Security Services, New Context

    DevOps is the hottest moving target when it comes to software development methodologies. Many people fear that this fast paced, barrier breaking movement will leave information security best practices.

    After the week is over, a great deal more security professionals in the industry should have a stronger grip on how to better incorporate security into DevOps practices and improve enterprise IT outcomes while reducing risk.

  • DevOps Security Talks At RSA USA 2015 Conference

    DevOps Security Talks At RSA USA 2015 Conference

    DevOps and security. Its a muddled mix of waters made even more confusing by the wet ink still on the concept of DevOps. There is no denying the popularity of DevOps and there is a lot of talk on how the DevOps movement functions alongside security teams.

    The annual USA RSA conference is just around the corner and its worth noting a handful of DevOps focused talks deserving of your attention.

    I am anticipating a lot of common themes around integrating DevOps and Security regarding tools, processes and culture. Given the history of these speakers, you can probably anticipate many of them to be on the bandwagon of security and DevOps folks better learn to work together and learn from each other or be prepared to find a new job.

    If I missed a talk that specifically covers the nexus of DevOps and Security at RSA USA this year, please leave a comment and I’ll be sure to get it included.

     

  • Is ALM Dead in the World of DevOps?

    Is ALM Dead in the World of DevOps?

    Has DevOps killed Application Lifecycle Management (ALM)? If the question makes you dizzy, you’re probably not alone; after all, it seems like just a few years ago that ALM was a fresh, new idea — and a key component of most implementations of Agile. So what happened to ALM, and why would DevOps kill it (if that’s what actually happened)? First, a little history:

    (more…)