staging-devopsy.kinsta.cloud

Category: Features

  • CFP for DevOps Connect: DevOpsSec @RSA Conference is now open

    CFP for DevOps Connect: DevOpsSec @RSA Conference is now open

     

    300x250_Connect_ad2The world comes to talk security at RSA Conference. Every year in San Francisco the RSA Conference is the biggest information themed security conference in the world. This year there is a new addition to RSA Conference. DevOps Connect: DevOpsSec will be held on the Monday of RSA week at the Moscone Center. Attendance is free and open to all RSAC registered attendees. But you must pre-register at the time of registration.

    The keynote and co-chairs for the DevOps Connect program are author and DevOps pioneer Gene Kim of IT Revolution Press and Joshua Corman, CTO of Sonatype and Co-Founder of RuggedSoftware.org and IamTheCavalry.org Gene and Joshua first introduced “Rugged DevOps” at RSAC 2012 and have been building collaborations and bridges between those worlds ever since.

    Additionally, Mark Miller and TheNEXUS are co-producing this show along with staging-devopsy.kinsta.cloud and of course with the sponsorship of RSA Conference.

    “DevOps is one of the fastest rising trends in technology with a tremendous impact on the information security landscape,” said Linda Gray, General Manager, RSA Conference. “We are excited to hear the direction and insights speakers such as Gene Kim and Josh Corman will bring to this event and to our RSAC attendees.”

    The call for papers is now open to speak at this event. The link for the CFP is: http://ow.ly/I27jQ . If you would like to speak at this event, head over now and submit your proposal. Josh and Gene have given a lot of thought in designing the CFP in terms of what the agenda for the conference will be, so please read it carefully before submitting.

    What are they looking for? Here is the pre-amble to the CFP which should help give you a good idea:

    DevOpsSec 2015: Call for Speakers

    Whether we like it or not, DevOps is upon us. The DevOps Enterprise Summit in October 2013 showed us that it’s not just for Internet startups, but it’s for large complex, and highly regulated organizations such as Disney, Capital One, Macy’s, GE, Nordstrom, Target, U.S. Citizenship and Immigration Services at DHS, and many more.

    DevOps and “continuous everything” is profoundly changing the entire software industry. Our goal is to show how the fittest in InfoSec are adapting (and how we all must adapt). The purpose of the DevOps Connect: Security Edition is to assemble the best practitioners who are forging how InfoSec integrates into DevOps, to grow the tribe, and to build relationships and collaborations with DevOps leaders and luminaries outside of the security “Echo Chamber”.

    Gene and Josh first introduced “Rugged DevOps” to RSAC 2012 and have been building collaborations and bridges between those worlds ever since. For 2015, we’ve asked them to host this day-long conference with the following goals:

    • bring the best and brightest of the DevOps and InfoSec communities together
    • share and codify effective patterns and practices, for mutual growth and benefit
    • for new-comers, demystify the DevOps foundational concepts that every InfoSec practitioner needs to know
    • capture the failures and toughest problems facing our industry, and mobilize to solve them

    We are looking for speakers to discuss the unique challenges of adopting DevOps in the enterprise, and the ways to overcome them. Specific topics we’re looking for include, but are not restricted to:

    • How did you get senior management buy-in, what did you do, and how did you quantify the business value?
    • How did you overcome objections inside the organization?
    • How did you design and implement effective controls to mitigate security risks?
    • Which business area (and application) did you start with, why, and what did you do?
    • What were the top challenges, and how did you overcome them?
    • What were your top mistakes, and what advice would you give as a result?
    • In-progress stories (and even nightmares) are welcome!

    Other submission guidelines:

    • Talk slots will be 30 minutes, of which a few minutes should be reserved for Q&A.
    • Attendees must be able to use the bulk of the presentation’s lessons without buying or using a particular tool or service.
    • While we love consultants and vendors (they’re some of our favorite people!), we are looking for stories from the organizations adopting these practices. We are prioritizing practitioner presentations (or joint ones with their game changing consultant/vendors).
    • You can submit up to three talks for the conference. No spamming.
    • Each submission should end with a slide communicating three things:
      1) A specific challenge you could use help with (people, process, or technology).
      2) A specific offer of how you could help other attendees (people, process, or technology).
      3) If you could wave a magic wand and get any change you want from the DevOps and “continuous everything” toolchains you depend upon, what would it be and why?

    The closing date for submissions is midnight Pacific time, February 15, 2015.

    SUBMISSIONS DEADLINE: MIDNIGHT PACIFIC TIME, FEBRUARY 15, 2015
    LINK:REGISTRATION FORM

    Thanks for your interest in DevOps Connect: Security Edition and we look forward to reading your proposal!

    Thank you!
    Josh Corman, Gene Kim

     

  • Google Hangout: InterConnect 2015 preview from IBM & Nationwide on #DevOps

    Google Hangout: InterConnect 2015 preview from IBM & Nationwide on #DevOps

    Join us for a Google Hangout* with a distinguished panel of guests as we discuss: Adopting DevOps for Two-Speed IT.

    With IBM InterCnnect 2015 just a month away, three featured presenters will give us an Interconnect preview

    *Google Hangouts are FREE.  To participate in a Google Hangouts LIVE, a Gmail  or Google  Profile is required.

     

     

     

    Date: Wednesday, January 28th, 2015

    Time: 3pm eastern standard time

    REGISTRATION LINK:(NO REGISTRATION REQUIRED*) 

    About Our Guests:


    RosalindRosalind Radcliffe,     our guest from @IBM

    Distinguished Engineer – Chief Architect for CLM and DevOps, Member of the Academy of Technology

     

     

     

    Carmen-DeangeloCarmen DeArdo, our guest from @Nationwide

    Director – Tools and Technology Leader

     

     

    sanjeev-sharma

    Sanjeev Sharma, our guest from @IBMDevOps_For_Dummies_2nd_ed_cover

    IBM Worldwide Lead – DevOps Technical Sales (Executive IT Specialist),

    Author of DevOps for Dummies

  • The role of middleware in DevOps

    The role of middleware in DevOps

    Middleware has a very important and strategic role in DevOps, according to Ben Henshall, middleware business unit manager at Red Hat Australia and New Zealand. ‘Rapid everything’ is part of DevOps culture, so the bloated, proprietary middleware with roots in the late 1990s and early 2000s – the pre-cloud era – is a poor fit.

    He pointed to an unnamed government organization that is limited to two major code releases per year, largely because of the complexity of its middleware and associated processes, which means systems have to be brought down completely for a weekend to deploy the updates.

    This is in stark contrast with current thinking, and Henshall pointed to the frequently-cited 2009 presentation by John Allspaw and Paul Hammond http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr that described how Flickr managed 10 full deployments during a typical day.

    Modern middleware is designed with cloud deployments in mind, including a multitenant architecture and a small resource footprint that minimizes infrastructure requirements. The best examples are based on Open Source projects with many contributors and extensive testing, and are developed and tested in the cloud, said Henshall, presumably with Red Hat JBoss Enterprise Middleware in mind.

    It may be necessary to re-architect applications in order to decouple them from old-school middleware so a more modern replacement can be used, but technologies such as containerization can simplify the task, he suggested. While the right middleware and the adoption of Platform as a Service (PaaS) help – along with technologies such as OSGi (Open Service Gateway Initiative, which allows updated Java code to be deployed without stopping and restarting a system, among other things) as implemented in Apache Karaf (which is part of Red Hat JBoss) – but it is important to design applications so they can be maintained without outages, he said.

    PaaS has seen a rapid rise in popularity as it makes it easier for developers to build and test new logic, and for operations staff to manage multiple systems without customization and with the benefits of automated releases. For example, Cisco has released more than 240 applications in around 12 months by using Red Hat OpenShift PaaS, said Henshall, noting that it can run on premises or be consumed as a service run by Red Hat.

    The automation provided by PaaS fits in with the operations goal of running stable, reliable and secure systems, while reducing the need for “operations ninjas” who are potential single points of failure in the event of illness or resignation.

    Henshall said OpenShift customers include a tertiary education institution that adopted OpenShift to speed the development and deployment of new applications and can now provision new systems within minutes, a software vendor that has reduced the time to market for new initiatives, and a major Commonwealth Government department that has been able to meet internal requirements concerning security, supportability and risk reduction since adopting the PaaS.

    Being able to support innovation in the shortest time and with the least risk “is such a huge thing” for organizations, he said, especially when it can be combined with dramatic costs reductions and easier compliance.

    Vendors such as Red Had provide products and services to support the DevOps culture, he said, noting “our software is developed by people facing these issues.”

    About the Author/Stephen Withers

    stephenWithers

    Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/

  • Does DevOps drive agility, or does agility result in DevOps?

    Does DevOps drive agility, or does agility result in DevOps?

    DevOps is a hot topic. Hell, I’m writing this on a site dedicated specifically to DevOps and you’re reading it, so it seems safe to assume we agree on the general premise that DevOps is an important trend for both business and IT. I question however, giving all of the credit for cost cutting, or for more agile and effective organizations to DevOps.

    A recent survey commissioned by CA Technologies titled DevOps: The Worst-Kept Secret to Winning in the Application Economy makes the claim that 88 percent of IT professionals surveyed have already implemented DevOps or plan to within the next five years. It also notes that companies that have already adopted DevOps have experienced 14 to 21 percent improvement in quality and performance of applications and/or faster time-to-market. Clearly DevOps is virtually ubiquitous, and companies that embrace DevOps are all but guaranteed to be more effective and efficient.

    Well, no. Not really. I’m a huge fan of DevOps, and I think there is a very good chance that organizations that adopt DevOps are likely to experience tangible, measurable benefits. However, one does not necessarily lead directly to the other and, in fact, it may be the other way around. Perhaps organizations that are doing the right things to yield improvements that result in more efficient and effective operations are also the organizations that are likely to embrace DevOps. I call this “Does DevOps drive agility, or does agility result in DevOps?”

    For starters, we still can’t even narrow down a concise explanation or definition of DevOps we can all agree on. So when we say that an organization’s success is the result of DevOps, what do we mean? Is it because the company broke down barriers between teams and enabled workers to collaborate together more efficiently? Is it because the company moved its infrastructure to the cloud and automated deployment of virtual servers and applications? Or is it because the company embraced specific tools or platforms like Chef, or Docker?

    There is an argument to be made that much of what comprises the strategic side of DevOps is just a natural, cyclical occurrence in business. There’s always some new management philosophy or business model du jour with a catchy buzzword, and right now it’s DevOps. Part of the reason that DevOps remains such an ethereal concept is that most of the organizations employing DevOps don’t realize they’re using DevOps, and they don’t call it that. Those organizations are just responding to the realities of competing today in the best way they can. That effort seems to lead invariably to embracing philosophies and strategies that have been collectively dubbed part of the DevOps culture.

    The organizations that started it all didn’t sit down and say “OK. We should start by adopting DevOps tools and strategies.” Companies like Netflix didn’t “embrace” DevOps—they created it from scratch, organically, and developed the tools and strategies that form the foundation of the DevOps movement. Everything that follows is an attempt to mimic the success of those organizations.

    If it’s a question of which came first, the chicken or the egg, it seems clear to me that DevOps is the outcome of a culture shift more than the engine or catalyst of the culture shift. To be fair, DevOps has matured, and is evolving into a culture all its own, and the tools and philosophies that make up DevOps are more clearly defined as time goes on. A company looking at it today can explore successful tools like Chef and Docker, and study examples of other organizations that have achieved success through DevOps principles.

    We still need to be careful, though, when breaking down statistics like those in the CA survey. Companies that are more agile, and deliver better quality products more quickly may also have adopted DevOps tools and strategies, but it doesn’t necessarily imply a direct cause and effect between the two. Perhaps as DevOps matures and the definition of the strategies and tools that comprise it becomes more consistent it will be easier to state clearly whether or not an organization has “adopted DevOps” and apply metrics that directly measure the effects of DevOps unique from the metrics the company would achieve anyway with or without DevOps.

  • Why DevOps is like fitness or religion

    Why DevOps is like fitness or religion

    What is DevOps?

    I noted in a blog post last summer that limiting DevOps to a single definition is challenging. The Wikipedia entry for DevOps contains a variety of possible explanations that seem to disagree in some ways:

    • It’s a “software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.”
    • The goal of DevOps is “to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.”
    • It “targets product delivery, quality testing, feature development and maintenance releases in order to improve reliability and security and faster development and deployment cycles.”
    • It “aids in software application release management for a company by standardizing development environments.”

    All of these are true, and yet none of them is necessarily THE definition of DevOps.

    A recent ZDNet post titled Why there will never be one do-it-all DevOps tool proclaims, “There is really no such thing as a specific DevOps “tool”—and don’t buy into the “DevOps” labeling many vendors are attaching to their solutions. Successful DevOps depends upon a multitude of tools and methodologies that can help organizations better align their software development and release cycles.”

    The question, “What is DevOps?” isn’t like asking, “What’s the temperature today in Phoenix, AZ?” or, “What’s the fastest land animal?” Those questions have precise answers that are based on measurable, irrefutable metrics. The answer is the answer and it isn’t really open to debate.

    “What is DevOps?” is more like asking, “What is the best fitness program?” or, “Which religious belief system should I subscribe to?” There is a vast array of answers and passionate beliefs on all sides. But, there really isn’t so much a “right answer” as a “right answer for you”.

    When it comes to fitness, there seems to be as many diet and exercise programs as there are people trying to get fit. Books, magazines, and infomercials are filled with extraordinary examples that “prove” that a given fitness program or philosophy works…at least for the subject of the story. There are some elements that are universal truths like exercise is better than being sedentary, and making healthy eating choices is better than eating an entire cheesecake for dinner. Almost everything else is subjective. There are too many variables involved that make people, and how they respond to different diet and exercise programs, different.

    DevOps is also like religion. Most people don’t choose their faith. They’re raised from birth to follow in the footsteps of their parents, and their religion is more or less predetermined. Religion is also personal. While some will insist that there is only one true faith and that theirs is the only real religion, most people recognize that religious faith is very subjective and it’s a function of finding the belief system that makes sense to you.

    DevOps is like fitness and religion in that what it means to an organization, and how it is first implemented, is influenced by the existing culture and infrastructure—the IT the company was “raised on”. DevOps is also like fitness and religion because there is no “one-size-fits-all” answer to the question “What is DevOps?”

    It isn’t a defined process—it’s more of a concept or philosophy. It isn’t a product or service that can be packaged and sold—it’s more a collection of the products and services that enable you to embrace the concept or philosophy. To some extent, DevOps is whatever works for your organization to automate routine tasks, reduce redundant effort, streamline operations, and remove unnecessary obstacles so people can get things done as efficiently as possible.

  • Gartner gives Docker security an ambivalent thumbs up

    Gartner gives Docker security an ambivalent thumbs up

    As organizations continue to evaluate wider spread use of containerization to enable continuous deployment, security concerns around the wildly popular Docker keep popping up. Last week, an analyst with Gartner published a report that gave Docker security positive marks with some big caveats.

    Written by Joerg Fritsch, the report examined the security properties of Docker. According to Fritsch, Docker is effective at resource isolation and has already just about attained parity in secure operations management and configuration governance with Linux OS and hypervisors . But where Docker containers fall short is on the management end.

    “They disappoint when it comes to secure administration and management, and in support for common controls for confidentiality, integrity and availability,” Fritsch wrote, explaining that this could improve as Docker refines its libswarm and nsenter APIs.

    As things stand, Fritsch recommends that organizations that don’t need to emulate a virtual private system should standardize on nsenter for interacting with running containers, and protect nsenter by limiting the input set. He also recommends that when working at scale, organizations should select a framework for managing resources and deploying containers, and consider using SSL/TLS wrappers for the Docker/Swarm API for the sake of integrity and confidentiality.

    Meanwhile, Fritsch particularly calls out the lack of endpoint protection platform and encryption tools for Docker containers, explaining that the outlook is “grim” on this front.

    “Traditional EPP and encryption vendors have not yet recognized containers as an area that they need to pursue and secure in the future,” he says, explaining that organizations have to mitigate risks through application whitelisting, SELinux or by using a strategic DevOps tool chain to automate and secure their containers, essentially making “containers self-assessing entities.”

    Third party vendors may take more note of Docker as 2015 progresses, particularly if Docker’s growth follows the same trajectory in 2014. From June to October alone, Docker’s downloads grew from 3 million to 21 million. And last fall Docker received venture support for future growth by way of $40 million in additional funding—following up a previous round of $15 million in funding earlier in the year.

    However, security concerns around Docker have started gather like storm clouds. In fact, security objections over Docker were a big reason for the introduction of the Rocket containerization project by CoreOS in early December. That announcement came swift on the heels of the release of the 1.3.2 version of Docker Engine, which took care of a number of vulnerabilities that could be exploited through a malicious Dockerfile, image or registry. It also added added a security feature for validation of images in containers.  However, by late-December, security pros were knocking that verification function.

    “Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest,” wrote Jonathan Rudenberg, co-founder of Flynn, in a long explanation of the insecurities in Docker’s image downloading process. “An attacker could provide any image alongside a signed manifest. This opens the door to a number of serious vulnerabilities.”

  • Ultimate Checklist for Successful App Deployment

    Ultimate Checklist for Successful App Deployment

    Deploying software releases is a mixture of planning, testing, late hours, and celebratory beers. This checklist is intended to be a guide to help improve how your team achieves this complicated and sometimes hairy task.

    Part 1: Planning and Deployment Preparation

    Collaboration Between Development and Operations

    It is important that operations be in the loop when it comes to planning any software deployment. They need to know when the project starts, not at the last minute about your new deployment. Ensure that operations is aware of any infrastructure changes needed well in advance. If the operations team is your front-line defense for monitoring and troubleshooting your app, help them help you by collaborating on how best to monitor the app and discuss early warning signs of trouble to be alerted to. If you’re thinking of setting up DevOp team you should probably read this.

    Build & Release Automation

    Removing the human factor is important to duplicating software deployment success. How you deploy the code doesn’t have to be state of the art. Utilize a basic build server like Maven, Bamboo, or TFS to automate the process or even a simple script that copies the files across the network can be sometimes sufficient. The key here is to make it easily repeatable by anyone on the team and eliminate the possibility of skipping any manual steps.

    Minimize the Amount of Change

    When things break in IT, typically it is because  something changed. When you introduce small changes in each software update it is easier to roll back those changes, or know exactly where to look for the source of the problem. As each release takes a certain amount of work in planning and testing, the key is finding the right balance of frequency and size of your releases that is optimal for your team to handle.

    Create and Test SQL Change Scripts

    Prior to your app deployment make sure you use tools like Red Gate SQL Compareto know what SQL schema and data changes have to be moved to production. to ensure there are no environmental differences that will cause potential headaches, I recommend never to forget to take a backup of production and run the test scripts on the backup copy before the final release. Production data differences or different database software versions can commonly cause hiccups. Also, have a plan to roll back to a previous state if the release has issues. Code is easy to roll back, but SQL requires some planning.

    Know your KPIs

    Every app should have some form of key performance indicators or metrics that can be used to know if everything is running smoothly. These will vary wildly from one app to another. They can be as simple as server CPU, page load times, or database performance metrics. The best metrics are more custom though. Knowing how many orders are happening per minute, or how many messages are being processed off a queue and how long it takes, or how long a certain piece of code takes to execute is a critical part of your app. Make your KPIs the heartbeat of your application and monitor them at all times.

    Setup Synthetic Transactions Tests

    Create a few tests that test things like your login page, key pages within your apps, APIs, etc. This will allow you to feel very confident that all systems are operational after the app deployment. I highly recommend Selenium, the leading open source framework for web automation.

    Notify Your Users and Colleagues
    Don’t forget to notify your users and others within your company about the upcoming changes. Make sure you have time to update documentation, train internal staff about new features, and coordinate with other departments in your company.

    Part 2: After the Deployment

    Monitor Server Utilization

    Make sure servers are all online, in the load balancer, and still receiving traffic. Monitor server and app CPU, memory, network, and disk usage. Noutilization can be as bad as sudden high utilization.

    Monitor Exception Rate

    After a new release your software is likely to throw some new exceptions you have never seen. Utilize an error tracking program so you can immediately identify new errors introduced in the release and to ensure previously resolved errors haven’t been reintroduced. A comparison of your overall error rates before and after the deployment will give you good indication of the release health.

    Check your KPIs

    Keep an eye on your performance indicators that let you know if your application is running properly.

    Watch your logs

    After an app deployment make sure logging is still working and the volume of logging hasn’t changed dramatically. No logging at all can be as bad as sudden high logging rates. A centralized log management tool makes this easy to monitor. You might also want to check the logs of new features that were released to ensure they are behaving properly.

    Monitor Page Load Times and HTTP Error Rates

    Watch the overall page load times of your application and keep a closer eye on 2-3 requests that are mission critical to your app. Also watch out for the rate of 400 and 500 level HTTP requests to ensure they haven’t dramatically changed.

    Monitor Database Performance

    After your deployment make sure database CPU, IO, and overall traffic look normal. Nothing is scarier than a sudden drop in database traffic after a release… unless it’s a sudden spike in database traffic.

    Monitor Key Database Queries

    Setup monitors in your monitoring system to test key queries to ensure they are loading quickly and returning proper results. For example, if some important background processes work based on SQL queries, run similar queries to make sure it isn’t missing work to be done and is working properly.

    Monitor Application Queues

    Monitor how many messages are in your application queues to ensure everything is flowing properly and not getting backed up.

    Cache Server Changes

    Don’t forget about caching. Depending on how you use caching, you may need to clear your caches or make other configuration changes. Data type changes can commonly cause some weird serialization type issues in cache.

    Have a celebratory beer!

    At Stackify we prefer a local joint with some good craft IPAs or the one brewed by one of our developers. Make sure your team has a good tradition for after releases.

    Post Mortem Meeting

    It can be very valuable to stop for a few minutes and discuss how the last release went and how things potentially can be improved. These kinds of conversations can help identify team weaknesses, allow people to vent, and take note of issues that can try to be prevented in future development cycles.

    Summary

    Deployment success over a long period of time depends on being able to automate and create processes that minimize issues for all stakeholders. Creating some automation or scripts around your build and release processes pay big dividends in the long run. Utilizing various monitoring tools or looking for new ones that  can help monitor your server and application health from every angle. Tracking trends over time can help you show off the improvements you’ve made with each release in availability, performance, KPIs, and user experience.

    About the Author

    mattMatt Watson founded Stackify in 2012 and as CEO provides the vision and leadership for the direction of the company. Prior to founding Stackify, he was the founder and CTO of VinSolutions. VinSolutions’ innovative product offering led to rapid company growth and was even featured on the Inc. 500 (#447) in 2010. Matt is an entrepreneur at heart and excels at product and software development.

    Matt studied Computer Information Systems at DeVry University. He started programming when he was in middle school to automate playing video games while he was at school. He hasn’t stopped programming since and loves anything technology related. Other hobbies include working too much, travel, movies, golf, cars, and of course his family. You can reach Matt at  @Stackify, @mattwatson81,  www.stackify.com, https://www.facebook.com/Stackify

     

  • What are the most critical DevOps Tools?

    What are the most critical DevOps Tools?

    What are the most critical DevOps tools categories? According to the results of a new survey by CA Technologies the answers may be surprising. That is just one of the insights reported on. The survey results and report are chock full of other great insights about DevOps usage as well.

    The survey shows that a staggering 88% of respondents either are already utilizing or expect to be utilizing DevOps within the next 5 years.  The over 1400 respondents to the survey represented IT or line of business executives and is a significant increase over last years 66% response rate. This would certainly indicate that DevOps is crossing over in the mainstream and is no longer solely in the realm of early adopters and visionaries.

    So according to the study what are the most critical DevOps tools?

    tools

    APM as the most critical? It is a popular segment with players like New Relic, App Dynamics, Dynatrace (Compuware) and CA to name a few. But I thought that change/configuration management which would include Chef and Puppet would be number 1. Also performance testing and functional testing were 2nd and 3rd. Could this be a case of categories CA plays in being over emphasized, the “everything looks like a hammer to a nail syndrome”?  I don’t know, but the numbers speak for themselves. I was happy to see enterprise security coming in 4th on the list (another area CA plays in).  Bringing up the rear at only 11% was network performance management. I think that may have a lot to do with the fact that with the rise of the cloud, so many organizations are less invested about network as the cloud and Internet has replaced much of the internal LAN.

    I spoke to Andi Mann, VP in the CTO’s office at CA and a frequent contributor to staging-devopsy.kinsta.cloud about the survey. Andi said that it is re-enforcement that despite all of the talk about DevOps being about culture, we should not forget that it is about tools as well.

    So what are the reasons given for this massive adoption statistic. What are the perceived benefits and reasons driving DevOps adoption?  According to the survey results:

    devops benefits

    As can be seen over 40% cited improved quality and performance of applications as the driver for DevOps.  For those who wonder about whether you can have increased speed only at the expense of quality, this would seem to show that you can have both with DevOps. Perhaps equally as rewarding was the 2nd most popular response, improving the end customer experience.

    In any case with 88% of respondents on board with DevOps, one thing is for sure, DevOps is the worst kept secret in IT. However, let’s not paint an overly rosy picture. Not every DevOps effort succeeds. What are the biggest obstacles to DevOps adoption? Again the survey says:

    devops obstacles

    So while enterprise security is a big benefit for adopting DevOps, security and compliance concerns are the biggest obstacles to DevOps adoption as well. I guess that is the Jekyll and Hyde nature of security? I don’t buy the ROI being difficult to justify. Most DevOps examples I have seen show a clear positive ROI.  Identifying the right DevOps consultant firm?  I don’t know about that one either. But then again I am bullish on DevOps, so I may be as guilty of the “hammer looks like a nail” as anyone.  I am surprised though that under obstacles we didn’t see that our culture is not trusting or some other culture related reason.

    You should go have a look at the survey yourself as there are other good insights there. In the meantime here is another indicator of just how deep DevOps is penetrating the IT market.

     

  • When the bad guys use DevOps, you need DevOps to defend yourself

    When the bad guys use DevOps, you need DevOps to defend yourself

    I came across an intriguing headline the other day: Malware coders adopt DevOps to target smut sites. The article, unfortunately, is fairly vague about what exactly that means, but it got me thinking about the potential implications.

    It’s all just a function of rivals competing. Just as Company A has to find a way to work more efficiently and bring better products and services to market faster than Company B, malware developers need to be faster and more agile than their targets. In either scenario DevOps can give one or both parties a competitive boost.

    Although the article in question simply says malware developers are “now engaged in DevOps,” and claims it’s the first time that behavior has been seen from the dark side, the reality is that malware developers—even those in organized cybercrime groups—have always had an element of DevOps to them. By their very nature they’re more inclined to have shared responsibilities and to exhibit the sort of jack-of-all-trades cross-functionality that we expect to find in young startups.

    “It has always been the case that most attackers embrace much more of a DevOps pattern than defenders. Most of these folks were born of the Internet way of thinking and nowhere in their playbook do they have the traditional data center change controls or any other big enterprise methodology,” declared TK Keanini, CTO of Lancope.

    The problem that many organizations face when it comes to mounting an effective defense is a lack of situational awareness of their own environment. In many cases the attackers actually know more about the organization’s network, and the assets connected to it than the organization itself.

    Effective defense also requires agility. Companies need to be able to adapt quickly and implement changes without impacting business continuity. Keanini says, “DevOps is one way to do this and something like the Rugged Manifesto does a great job of capturing the essence of what it will take to battle this threat day in and day out.”:

    The Rugged Manifesto

    I am rugged and, more importantly, my code is rugged.

    I recognize that software has become a foundation of our modern world.

    I recognize the awesome responsibility that comes with this foundational role.

    I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.

    I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security.

    I recognize these things – and I choose to be rugged.

    I am rugged because I refuse to be a source of vulnerability or weakness.

    I am rugged because I assure my code will support its mission.

    I am rugged because my code can face these challenges and persist in spite of them.

    I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.

    The question is, “How?”

    Keanini—ever the strategist—references the OODA loop, conceived by USAF Colonel John Boyd. OODA is an acronym for Observe, Orient, Decide, and Act. The concept was originally designed for military combat operations but can also be applied quite effectively in many areas of business. Applying it to network or endpoint security, the idea is to at least raise the cost of observation and orientation for the opponent—in this case the malware developers.

    “DevOps can deliver this because change can be implemented as a defense whereby the adversary never has time enough to make enough of an observation, or orientation accurate enough for effective decision and action,” clarified Keanini.

    There are a few different elements involved here. Continuous monitoring and continuous incident response are both applications of a DevOps mentality that can help organizations mount a more effective defense against sophisticated attacks. The OODA loop Keanini refers to is less about response, and more about applying DevOps philosophies to take away the strategic initiative from the attackers in the first place.

    One thing is certain, if the malware developers implement policies that enable them to craft and deploy attacks faster, businesses will have no choice but to figure out some way to adapt and defend more quickly as well.

  • Continuous Delivery snapshot: a universe of fragmented tools

    Continuous Delivery snapshot: a universe of fragmented tools

    Technology has ushered in an era of real-time information, immediate feedback and instantaneous response. As a result, there is tremendous pressure on development teams to deliver a continuous flow of updates and fixes to software applications. In support of this objective, development philosophies and methodologies abound: agile, lean, scrum, kanban and extreme programming, just to name a few. Development teams are adopting and implementing these new methodologies at a breakneck pace in an attempt to bring efficiency and speed to the development process.

    This increased velocity has placed added pressure on software delivery teams to build, validate and deploy newly developed code faster and more reliably. Over time, the DevOps movement has emerged, injecting robust automation into the delivery process while spawning a diverse collection of hundreds of single-purpose delivery automation tools. As a result, DevOps has improved delivery speed and quality. Even still, continuous development comes with its challenges. Namely, the lack of a real-time “big picture” view,  of the end-to-end software delivery process.

    New Challenges for CD Teams: The Unified Pipeline

    While highly diversified delivery toolchains can be effective and have increased speed and agility, significant challenges continue to plague the software delivery process as a whole.

    Real-time visibility and visualization – Typically, the delivery process begins as soon as newly developed code is considered “dev-complete.” Often, the sequence of steps and stages new code progresses through on the way to potential release is referred to as the delivery pipeline. In a moderately sized organization, delivery pipelines are comprised of dozens of people performing hundreds of tasks. Without a centralized “delivery portal,” team members have little or no insight into the overall upstream or downstream process flow. While delivery pipelines benefit from diverse automation, they are still a “black box,” largely absent of communication, collaboration and audit/tracking capabilities.

    Data fragmentation – Important delivery data is generated at virtually every step along the delivery pipeline. Disconnected toolchains generate siloed, disaggregated and uncorrelated data that is trapped within a dozen or more automation tools. As a result, team members often lack access to a single comprehensive audit trail document that fully describes the functional and technical contents of a specific release along with any relevant data generated during each step of the delivery pipeline. At a macro level, self-organizing delivery teams do not have the real- time and historical analytic data required to quickly identify and react to exceptions or make performance optimizations across pipelines and/or teams.

    Is dynamic pipeline orchestration the answer?

    While the build and integration stages of a delivery pipeline are largely static and predictable, pipeline flow can become much more dynamic once manual testing begins. Defects can be discovered at any point along the delivery pipeline and judgment calls often determine a dynamic process flow. Often tools designed to automate the build/integrate phase of the pipeline are stretched beyond their original intent when it comes to pipeline orchestration. While these tools automate a critical portion of the delivery pipeline, they are far too static to support a real-world pipeline flow through the manual steps that occur in the later stages of a delivery pipeline. As a result, pipeline orchestration is largely a manual process beyond integration and into the quality assurance phases of delivery.

    What’s Missing?

    When it comes to alleviating the challenges associated with delivery pipelines, what will it take to ease the burden on continuous development teams?

    • Detailed Inventory of Each Bundle-of-Change – As multiple revisions get merged together in downstream pipelines to form a release candidate, a clear understanding of exactly what “changes” have been incorporated within any particular change bundle (release candidate) can become crucial.
    • Current Deployed Environment – At any given time, any revision or release candidate can be deployed to one or more environments or locations. The ability to quickly determine which change bundles have been deployed to which environment(s) is a fundamental need of virtually every stakeholder along the delivery process.
    • Broken code lines – Release candidates that contain known material defects are usually considered terminal and/or not deployable. Identifying a release candidate as broken can dramatically reduce the amount of time invested into a terminal release candidate. Subsequent testing within environments that contain a broken release often leads to wasted effort.
    • Detailed release documentation that fully describes the functional and technical contents of a specific release-in-transit along with all relevant data generated during each stage of delivery.
    • Reporting that describes stalled releases awaiting manual intervention with corresponding wait times.
    • Work queues that outline manual tasks or pending decisions/approvals assigned to a specific individual or group.
    • Travel time details on the average time it takes a release to traverse a pipeline from start to finish.
    • Reporting that describes the “base” release (starting version) and all subsequent change that has flowed thru any given development or test environment. 

    What is the Answer? 

    Without a technology that can oversee the entire development process and fill these gaps, teams often try to leverage Continuous Integration (CI) tools. While these tools greatly reduce the effort required to automate the build/integrate phase of the continuous delivery pipeline, this stretches them beyond their practical limits.

    However, a new type of pipeline orchestration technology that further streamlines and advances the effectiveness of the CD process is emerging and can effectively alleviate the challenges associated with fragmented and siloed delivery pipelines. This technology, often called a “pipeline orchestration framework,” expedites movement and raises awareness of a software “release candidate” as it travels through one or more delivery pipelines.

    So how do they work? Pipeline Orchestration Frameworks:

    • Leverage existing tools and processes – Because Pipeline Orchestration Frameworks sit on top of existing delivery automation tools, there is no need to reconfigure current process flow or abandon existing tooling. Pipeline Optimization Frameworks simply enhance and automate what is already in place.
    • Provide audit trail – Comprehensive audit trail documentation of each part of the process delivers highly detailed and valuable information regarding each new potential release. Having this audit trail ensures higher production quality results, increases cross-team awareness and reduces the time and effort required to perform root-cause analysis when defects are found (pre/post-production).
    • Manage deployments – Efficiently managing the cost and friction associated with dynamic development and testing environments over time can dramatically reduce the cost of delivery. Pipeline Orchestration Frameworks are capable of automatically provisioning and/or refreshing fully formed application environments as often as needed while keeping track of environmental drift or change over time.
    • Workflow automation – One of the goals of continuous delivery is to automate as much as possible along the delivery pipeline. However there are often steps that can’t (or shouldn’t) be automated, such as code reviews, exploratory testing, and manual decisions to automatically move a release into late stage test environments or even production. Pipeline Orchestration Frameworks manage and orchestrate these manual workflows as efficiently as possible, ensuring all delivery team members are aware of items in their “work queue,” and identifying stalled releases immediately.

    What will 2015 Hold? 

    The purpose of continuous delivery is to support development teams’ need to release reliable code faster. Therefore, the delivery team must keep up with an ever-increasing development velocity. Managing the delivery process not only requires managing each of the different phases of delivery, but also orchestrating the delivery process as a whole. That, in turn, requires visibility into every part of the end-to-end process, and a 10,000-foot view of the delivery pipeline. Pipeline Orchestration Frameworks offer CD teams a powerful new tool to unlock the full potential for successful continuous development.

    About the Author

    dennisDennis Ehle is the CEO and founder of cloud sidekick, which provides an automated, self-service integration and deployment framework for enterprises seeking continuous delivery. The cloud sidekick Velocity Pipeline Optimization Platform enables agile development teams to push code through multi-stage pipelines, automatically testing in virtual environments and ultimately publishing reliable code faster. For more information, visit www.cloudsidekick.com.