devopsy.kinsta.cloud

Author: Tony Bradley

  • Experts Weigh In on the Evolution of DevOps

    Experts Weigh In on the Evolution of DevOps

    DevOps is an ethereal concept. It means different things to different organizations and individuals. It also is going through an evolution, which means that as quickly as we might think we have a grasp on what it is and how to effectively employ it, DevOps has moved on. There’s no way to accurately predict whether DevOps will even still be a thing in another five years, or if it will have faded into oblivion—replaced by the next hot tech or development model. We can, however, take a look at how DevOps has changed in the past year, and what the immediate future holds for it.

    It isn’t an easy question to answer because first we have to agree on what DevOps is. Are we talking about DevOps as a culture or business model, or are we referring to the evolution of the tools and applications generally used in a DevOps environment? I reached out to the DevOps community to get some expert insight.

    Current State of DevOps

    “The technology question is a common one when it comes to DevOps. We are still faced with the problem of a clear definition of DevOps. So what makes this difficult is … I’m squarely in the camp that believes DevOps is more about culture than tools or tech,” explains Andrew Storms, vice president of Security Services at New Context. “That being said, a well-rounded and mature DevOps organization does require a shift in people, processes and technology. A lot of people will likely point to orchestration of infrastructure as the most important DevOps tool. However, I think the bigger driver of orchestration has been virtualization and cloud.”

    One of the defining characteristics of DevOps from my perspective—aside from the IT culture aspect—is the fact that we continue to raise the bar for automation. Each new automation tool further streamlines the process and puts a spotlight on the next bottleneck. Eventually, a new solution is developed to automate that as well.

    Chef CEO Barry Crist believes that one of the most important evolutions in the world of DevOps in the past year is continuous delivery (CD)—or the process of rapidly developing software and iterating through quick, small-batch releases. “Continuous delivery was previously exclusive to the web innovators like Facebook, Amazon and Google, but over the last year companies have realized it’s a primary key to unleash an organization’s innovation engine. When the whole stack—infrastructure, compliance, security, microservices and apps—are all expressed as code, IT is able to deliver value more quickly.”

    DevOps also has introduced more common ground between developers and security/compliance officers. In high-velocity organizations that have embraced DevOps, IT can deal with security threats more quickly by assessing a vulnerability, creating a fix, testing it and deploying it rapidly before damage is done. DevOps is also starting to automate and define compliance. When compliance is defined as code, the software can be managed and tested like any other piece of code in the organization.

    The Evolution of DevOps

    Storms stresses that the immediate future of DevOps revolves around it becoming more mainstream—the new normal. “We are already seeing the business value of DevOps. Companies are getting code out the door faster and at a more efficient means. Other departments, like those of security, are starting to see the value of DevOps and looking at ways to incorporate key points into their departments,” he says.

    Crist sees DevOps as evolving beyond IT itself. “In the next few years, the DevOps tent will expand beyond ‘devs’ and ‘ops’ to include executives and other business units,” he says. “DevOps is really about building high-velocity organizations. Mature DevOps organizations see both innovation and quality increases that drive more profit and shareholder value, as well as advances in security and safety.”

    Only time will tell how DevOps will actually adapt and evolve. I tend to agree with Chef’s Crist that the natural evolution is to take the core principles and practices of DevOps and expand them beyond development and beyond IT to streamline all aspects of the organization. I guess the real question is whether or not we’ll still refer to it as “DevOps” at that point.

  • Does DevOps Help or Hinder Compliance?

    Does DevOps Help or Hinder Compliance?

    DevOps tools and principles have revolutionized IT across many industries in recent years. But companies saddled with requirements such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLBA) and Payment Card Industry Data Security Standard (PCI-DSS), for example, tend to be more cautious when it comes to adopting cutting-edge solutions.

    There are specific industries—health care and finance are two—that are strictly regulated and more reluctant to change. But even beyond those industries, there exist various compliance frameworks under which the rapid pace of change associated with DevOps may be seen as a risk. The flip side of that coin is that the agility and automation associated with DevOps actually might streamline and simplify compliance.

    The DevOps and Compliance Challenge

    Ken Cheney, vice president of Business Development at Chef, agrees. “Today companies are faced with increasingly detailed security and compliance requirements. For organizations in highly regulated industries like health care, financial services and the Federal space, detailed compliance can impede the ability to innovate.”

    One of the biggest concerns DevOps organizations fear is that compliance and audit will create a “Wild West” ecosystem where everyone has access to all production systems and data. However, DevOps doesn’t have to automatically result in systems access chaos. In fact, the use of orchestration actually can lend a hand to making a more compliant organization where nobody gets direct access to production systems.

    “Instead, mature DevOps organizations actually remove all direct administrative access to systems,” says Andrew Storms, vice president of Security Services at New Context. “The ability to make changes all go through a central orchestration tool, where access can be abstracted forced through a change management automation system.”

    Better Compliance Through Automation

    The consensus among DevOps experts is that DevOps does more to help compliance than hurt it. It isn’t so much a question of whether a regulated business should or shouldn’t adopt DevOps tools and principles—it’s more a question of how.

    “DevOps tools and practices establish compliance through consistency. They help improve compliance by reducing complexity and variability within the environments,” notes Derek Weeks, vice president and DevOps Advocate at Sonatype. “For test and operations teams, configurations, tests and deployments can be automated to ensure execution is consistent. For development teams, consistent versions of binaries ensures use of compliant components, leading to more compliant applications. The automation capabilities of DevOps tools enable consistent, automated execution of compliant practices.”

    Rather than conflicting with such initiatives, DevOps can be a crucial element in simplifying and streamlining them. “The key to making compliance an advantage is to specify compliance requirements as code, allowing it to be tested just like any other piece of code in the software development pipeline,” Chef’s Cheney says. “Previously manual verification tasks—often tracked through spreadsheets or other arduous methods—can now be proactively addressed as embedded tests in an automated workflow. Security risks are brought to the surface early for faster remediation, so out-of-date software is identified and updated quickly.”

    Weeks concurs: “Not only does DevOps introduce more consistency and reduced complexity of operations, it also allows for fast feedback loops when things are identified as out of compliance. Waterfall cycle times that might have required weeks or months to fit changes or corrections into systems can now be achieved in a fraction of the time in DevOps practices.”

    It’s important for DevOps organizations to think a bit differently when it comes to compliance, though. They may be forced to implement the same types of controls using different tools or slightly different processes to conform with specific requirements. But Storms notes DevOps ultimately is a huge benefit for achieving and maintaining compliance.

    “Gone are the days of showing the auditor your physical paper trail of server build checklists,” he says. “Instead, businesses need to learn to work with their auditor to find new solutions that, in the end, actually enhance and optimize the process.”

    Rapid change can seem scary to IT and security admins. The pace of DevOps may seem to be in conflict with achieving and maintaining compliance, at least at face value. Done properly, though, DevOps enhances and automates compliance to make it as streamlined and simplified as possible.

  • IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    Thousands of people descended upon Las Vegas last week for the annual IBM InterConnect conference, where IBM shares its vision with customers and developers and makes big announcements. One of the biggest things Big Blue unveiled was BlueMix OpenWhisk, an event-driven programming service designed for a serverless computing environment.

    OpenWhisk uses an event-driven model, automatically executing code in response to external events such as incoming sensor data or designated triggers. (Event-driven programming is also called serverless programming, because the events themselves more or less become the foundation on which the programming is built.)

    Al Hilwa, program director of Software Development Research for IDC, declared the BlueMix OpenWhisk announcement to be one of the most interesting revelations at the IBM InterConnect conference. “This is IBM’s play in the hot area of serverless back-end computing supporting an event-driven application model like AWS Lambda, Google Cloud Functions and technologies from players like iron.io,” he noted. “This is the new face of PaaS, where developers do not have to worry about infrastructure.”

    I recently wrote that advances in DevOps increasingly seem to marginalize the “Ops” part of the equation, essentially making it obsolete: I noted that what you’re left with essentially is developers with the processes and tools to automate the infrastructure back end. Technologies such as containers and services such as AWS Lambda simplify greatly the process of programmatically generating, modifying and maintaining the underlying infrastructure.

    As I summed up in that article, though, Ops won’t really go away. Advances in DevOps and technologies such as serverless computing simply free operations teams. They can spend less time putting out fires or maintaining mundane configurations and focus more on big-picture issues that improve performance and help the company innovate.

    OpenWhisk is evidence of that future. It has the potential to transform IT and accelerate DevOps even more. Developers can develop and deploy applications faster and more seamlessly without the need to worry about the servers or middleware traditionally required. OpenWhisk will handle the necessary code.

    IBM suggested developers can use OpenWhisk to create microservices-based applications, where each individual task or component is developed and maintained separately. Different teams can operate in parallel on their individual elements.

    OpenWhisk joins other serverless computing platforms including Amazon’s AWS Lambda and Google’s Google Cloud Functions. As Hilwa pointed out, there are also emerging players such as iron.io. The unique value that OpenWhisk brings to the table is that it is integrated with the BlueMix platform, which means developers have immediate access to all of the apps, analysis and services BlueMix has to offer.

    IBM will open source the codebase of OpenWhisk itself. That isn’t a surprise, since BlueMix itself is based on open source code and IBM is a major proponent and benefactor of open source projects. The true potential of a tool such as OpenWhisk can be realized more quickly with the community at large helping to evolve it, but IBM can continue to act as consultants and provide deeper services for customers to help them maximize the value of OpenWhisk.

  • The Difference Between DevOps and Anarchy

    The Difference Between DevOps and Anarchy

    DevOps is about being more efficient. It’s about breaking down silos and removing traditional business obstacles that get in the way of just getting things done. It’s about enabling teams and individuals to collaborate more seamlessly.

    None of that, however, means that DevOps is about turning your IT into some sort of “Wild West” anarchy, where anyone and everyone can just push code to production. That would be insanity.

    One of the primary catalysts that started the DevOps movement was the frustration of developers trying to deal with an operational bottleneck. As developers evolved from the old-school Waterfall development method to the much faster-paced Agile, developers were able create better software more quickly. That simply resulted in a “hurry up and wait” scenario, though, because the Operations and IT infrastructure side of the house couldn’t keep up.

    Fast forward a bit and DevOps was born. Since its inception, however, there has been confusion about what exactly DevOps is or isn’t. That might be a function—at least in part—of the fact that there was no “inception” of DevOps; nobody developed a thing and then rolled it out to the world with the announcement, “This is DevOps.” DevOps was an evolution that occurred organically and out of necessity. It meant different things to different organizations and was implemented in ways that were largely subjective and often not called anything in particular. Organizations were simply struggling to address challenges and coming up with solutions that worked.

    Suppressing the Anarchy

    Although traditional IT operations were the roadblock that sparked the DevOps movement, DevOps doesn’t mean developers get to simply do their own thing. I’ve worked in the trenches as an IT admin at a dotcom startup—I’ve experienced firsthand the disastrous fallout of a developer pushing untested code onto a production server, and I’ve witnessed the wrath of executive leadership when that happens and the proverbial “stuff” hits the fan. It’s not pretty.

    No, DevOps does not mean eliminating Operations from the equation and functioning as an IT anarchy. You’ll note that DevOps is a very obvious portmanteau of developers and operations—implying that operations is half of the DevOps solution. DevOps is about developers working more closely and cooperatively with Operations—not developers bypassing IT Operations.

    There are two components to successful DevOps: culture and continuousness. First, organizations need to shed the traditional mindset of separate siloed teams and departments and let individuals focus on working together in whatever way makes the most sense for efficiency and effectiveness. Empowering individuals to do what’s necessary to collaborate and get things done is a big part of DevOps.

    The other component is continuousness. When developers adopted Agile and started producing code faster, they discovered that Operations was a bottleneck. When developers and Operations started working together more seamlessly, new bottlenecks were identified, and solutions were developed to automate as much of those tasks and processes as possible.

    The ultimate goal of DevOps is continuous delivery—to continuously deliver new solutions and features. Rather than a lawless void where developers just push code out onto production servers willy-nilly, organizations adopt continuous development, continuous testing, continuous deployment, continuous monitoring and other tools that enable their teams and those developing solutions to do so with as little friction as possible.

  • DevOps Brings IT Out of the Shadows

    DevOps Brings IT Out of the Shadows

    One of the biggest threats to organizations today is shadow IT—unsanctioned and unknown technologies and applications being employed by maverick users. Shadow IT represents a security risk for your company—the IT department can’t defend and protect technologies and assets it doesn’t know about—and should be eliminated. One of the best defenses against shadow IT is DevOps.

    When I worked in the trenches as a one-man IT department—part network admin, part tech support—there always were one or two individuals who knew enough to be dangerous. As frustrating as it was to deal with completely clueless users who didn’t know the difference between the computer and the monitor and weren’t even really sure where the power button was, those who knew enough to go rogue and reconfigure their devices or introduce new applications and services were a more existential problem for the organization. In today’s era of BYOD and cloud services, shadow IT is a scourge significantly greater than what I faced.

    Don’t get me wrong—I’ve also been on the other side of that equation and I understand the motivation that drives shadow IT. Users just want to get their jobs done, and the people in the trenches know better than anyone what the hurdles are and how to fix them. Requesting new technologies or capabilities from IT is a cumbersome and tedious process at many organizations, so in the name of expediency users just do what they need to do on their own.

    DevOps can help solve the shadow IT problem in a better and more sustainable way, though. There are two benefits that DevOps brings to the table that minimize the potential for shadow IT: More rapid development and empowering individuals.

    First, an IT organization that has embraced DevOps will be quicker to respond to requests from users. Replacing the traditional software development life cycle with a more agile and continuous pace of development means that feature requests can be incorporated much faster.

    Second, one of the cornerstones of DevOps is the underlying culture—the breaking down of silos and removal of barriers and bureaucratic nonsense that get in the way of efficient progress. Essentially, those rogue technologies and applications that comprise shadow IT in other organizations are simply a part of the larger DevOps whole in an organization that has embraced DevOps. There is even a term ascribed to users outside of traditional IT/developer roles who develop solutions: “citizen developers.”

    The 2015 State of Citizen Development Report explains in more detail what a citizen developer is: “Citizen Developers are empowered problem-solvers from the various lines of business who have the drive and determination to engage in app development even though they lack traditional coding skills.”

    That isn’t to suggest that in a DevOps world everyone can just go set up virtual servers, or store data on personal cloud services and that it’s OK. It just means that when users are given the tools and freedom to develop solutions that have the blessing of IT and the rest of the organization, they don’t need to function in the shadows.

    Embracing DevOps and the citizen developer movement enables IT to work in harmony with users to develop solutions that work rather than fighting against each other and ending up with shadow IT servers, applications and cloud services that IT isn’t even aware of. Organizations that are concerned about the impact of shadow IT should look at ways to harness the power rather than just trying to ban shadow IT completely.

  • Continuous is the Engine that Drives DevOps

    Continuous is the Engine that Drives DevOps

    It has been stated time and time (and time and time) again that DevOps is primarily a matter of shifting IT culture. The tools and practices that comprise DevOps play a secondary role. But that is only partially true: In reality, the culture shift revolves around continuity, and the applications and tools that fuel continuous delivery drive the DevOps engine.

    I alluded to this point in a post in early 2015. I stated, “Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response … or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”

    That post last year was a bit tongue in cheek. I have since refined my position, however, and come to the conclusion that the hint of sarcasm was perhaps unwarranted. That continuous continuousness is the crux of the culture shift. It is the thing that separates DevOps from non-DevOps.

    On the Continuous Journey

    Speaking on the topic of continuous security, Andrew Storms, vice president of Security Services at New Context, explains, “Smaller incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes. Try finding the single change in a monthly release that resulted in an unexpected security hole in your database configuration vs the release with only two changes that was just developed and released in the last few hours. Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection.”

    That sentiment extends beyond security to all of IT. When we talk about the culture shift in IT required for DevOps, we are generally talking about breaking down silos and removing the barriers between different teams. The goal of the culture shift is to shed tedious bureaucracy and red tape and empower employees to freely collaborate and cooperate to get things done. In other words, we want to eliminate barriers and roadblocks so productivity can be more continuous.

    Assuming the DevOps transformation begins at that level, it creates an environment of continuous collaboration which becomes continuous development. What follows is a natural evolution of continuity. Continuous development becomes continuous delivery, which requires continuous testing and continuous deployments, followed by continuous monitoring, which provides the metrics and feedback that take you back to the beginning of the loop.

    All of the “continuous” tools and solutions may seem to be part of the technologies and practices that come after the DevOps culture shift, and to some extent, that is true. However, they are also indispensable and inseparable from that DevOps culture shift because without all of the various gears meshing together smoothly—and continuously—what you’re left with is a more traditional approach to IT where everything comes to a halt.

    Is DevOps more of a cultural shift than a collection of tools? Absolutely. That culture shift revolves around continuity, though. Continuousness is the culture shift that drives DevOps.

  • Will Microservices Make the ‘Ops’ in ‘DevOps’ Obsolete?

    Will Microservices Make the ‘Ops’ in ‘DevOps’ Obsolete?

    DevOps is a portmanteau of “developers” and “operations.” The concept of DevOps is about shifting IT culture in a way that enables developers and operations to work together more seamlessly. As more and more elements of DevOps become automated and leverage microservices such as container platforms, though, the operations side of that equation plays a diminished role.

    Microservices and Automating Ops

    What you’re left with essentially is developers with the processes and tools to automate the infrastructure back end. Technologies such as containers and services such as AWS Lambda simplify greatly the process of programmatically generating, modifying and maintaining the underlying infrastructure.

    AWS Lambda seems to be a step toward removing the Ops from DevOps. It creates a system for use and runs code via APIs. The instance is spun up, the code is run and the instance is spun back down. AWS Lambda can decrease provisioning time and enable developers to be even more efficient than working with traditional virtual machines in partnership with operations.

    Container technologies such as Docker allow applications to be broken down into very granular elements—many of which can be leveraged repeatedly. The ability to reuse containerized functions across different apps and to drive that process through APIs enable substantially greater automation.

    With each step forward in the evolution of DevOps, organizations find new bottlenecks or roadblocks, and then look for or develop solutions to address them. In this API-based, automated future, the APIs themselves become a challenge. Organizations have to find ways to effectively manage and update a rapidly growing library of APIs.

    Ops Will Live On

    If you work in operations, or aspire to someday work in operations, don’t fret: Operations still will exist on some level.

    The role played by operations will simply evolve. “Operations is not going away, but the job is definitely changing,” says Shannon Williams, VP of Sales and Marketing at Rancher Labs. “Automation and microservices are technologies that are enabling operations teams to spend less time ‘firefighting’ to maintain configurations, etc., and more time on bigger-picture issues that will help improve performance and resiliency, [and] help bring down costs for the business.”

    That’s a step in the right direction. In this future scenario—next-gen data center—those in operations will be able to invest their time in more valuable endeavors. They will be able to automate routine, mundane infrastructure tasks and focus on incorporating new technologies that enable the organization to derive greater value from DevOps and IT in general.

    “What is going away is the time spent arguing about what went wrong, not operations itself,” Williams suggests. “Given the additional time that automation will free up for Ops, they can start to find ways to improve their specific business unit. They can now be focusing on optimizing for performance, costs, etc.”

    Evolution of DevOps

    I have pointed out before that every roadblock in DevOps is actually an opportunity. As DevOps principles are applied in new areas, and new tools are developed to automate more tasks, it just accelerates everything to the next bottleneck. Rinse and repeat.

    To some extent, the infrastructure side of IT and DevOps are two of those roadblocks. That’s why tools are emerging to allow many components of infrastructure to be automated, freeing the operations team to focus its efforts on whatever the next roadblock is.

  • 3 Tips to Avoid Painting Your DevOps into a Scalability Corner

    3 Tips to Avoid Painting Your DevOps into a Scalability Corner

    When everything is firing on all cylinders, DevOps can be awesome. Teams work together seamlessly. Routine tasks are automated. Continuous delivery is continuously integrated, continuously tested, continuously deployed and continuously monitored. All is well, and right with the world—unless your DevOps needs begin exceeding the capacity of the platforms and tools you depend on. Scalability is a crucial element of DevOps success.

    Wikipedia defines “scalability” as the capability of a system, network or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth.

    The need for scalability is one of the primary reasons that DevOps and cloud computing are so integrally linked. While it’s possible to do DevOps on some level using physical hardware or virtual servers running on hardware in a local data center, it can quickly become impractical—if not impossible. Cloud computing using platforms such as AWS, Rackspace or Microsoft Azure enables an organization to increase server capacity exponentially at the push of a button.

    “Many of the issues and challenges experienced before the advent of cloud are no longer issues: Engineers now working on cloud implementations remember working at companies that feared the Slashdot effect—a massive influx of traffic that would cause servers to fail,” explains Jason McKay, VP of Engineering for Logicworks, in a blog post.

    Tackling Scalability

    There are a number of factors impacting scalability in your environment, which could impact the success of your DevOps. Here are three things to keep in mind to ensure your environment is ready to scale:

    1. Make sure your tools and apps are scalable

    The ability to scale capacity on demand—automatically—is one of the chief advantages of cloud computing, and one why cloud computing is so important to DevOps success. There is more to scalability, however, than just server and network capacity. You must also ensure that the tools you rely on can seamlessly scale with the infrastructure, and that the apps you’re delivering through your DevOps environment are designed to take full advantage of the increased capacity as well.

    2. Continuous optimization

    Some tools and apps will continue to run as the underlying infrastructure scales up or down, but may not run optimally. Make sure that the tools you use and the apps you deploy are able to continuously adjust to changes in server, bandwidth and storage capacity. The tools and apps should be able to take full advantage of the resources available to ensure the best performance possible at all times.

    3. Don’t forget about storage

    Most apps have a data component and that means there is data storage that must be scaled as well—either as a function of the broader network infrastructure scaling or just in response to increased demand for data storage.

    Dan Leary, VP of Products, Solutions and Alliances at Nimble Storage, believes that scalability is emerging as a differentiating factor between storage solutions. “Due to the high performance offered by many vendors of flash-optimized storage solutions, performance will no longer be the primary differentiating factor when considering one vendor over another. Instead, a much greater focus will be placed on the array’s reliability, data integrity, scalability, manageability and in-built data-protection capabilities. We are now getting to the point where performance in storage has been democratized and will change the way people purchase storage.”

    There is one more thing to remember when considering scalability: cost. While it may be easy to automate scalability on cloud platforms, it’s not free, and the DevOps tools you depend on may include licensing fees that could be impacted as your usage scales, so keep that in mind.

  • Machine Learning, AI Driving DevOps Evolution

    Automation is the fuel that drives DevOps. Automating routine, repeatable tasks is one of the defining characteristics of DevOps culture. As artificial intelligence (AI) and machine learning improve, the scope and complexity of the tasks that can be automated increases, which raises the bar for all of DevOps. The humans behind the DevOps will be freed from even more mundane tasks and able to focus on more innovative and creative endeavors.

    It makes sense, if you think about it. The trend from physical services in an on-premise data center, to virtualization, to cloud services, to DevOps has been a steady march of raising the bar for automation. The more applications and entire infrastructures can be developed, deployed, monitored and managed programmatically and through automation, the more efficiently and effectively an organization can function.

    As tasks are offloaded to automation, humans can address other challenges. That focus inevitably leads to identifying other new tasks that can be automated. AI and machine learning represent a quantum leap in this evolution, however—with AI and machine learning, the automation can begin to identify and improve itself. When the automation can identify bottlenecks and inefficiencies and automatically adapt to overcome those obstacles, human input and interaction could become almost obsolete.

    In a recent interview, Christian Beedgen, CTO of Sumo Logic, shared some thoughts about the impact of machine learning on DevOps. “Machines will enable greater productivity among teams and businesses through the advances that machine learning and automation can offer,” he said. “A necessary component to augment human contributions, machine learning will finally give humans the power to review millions of bits of data.”

    Automating routine tasks is crucial, but there’s another factor that plays into the role that AI and machine learning have with the future of DevOps. The reality is that there are some things humans simply can’t do as well or as fast as machines—especially at scale.

    Steve Burton stressed in a blog post that humans are capable of observing, digesting and interpreting only so much information at one time. Some feel like the Holy Grail solution is some sort of application performance management (APM) dashboard that can aggregate and correlate real-time data so human IT personnel can monitor metrics and identify issues manually. “This all sounds good in theory, except it’s completely unmanageable in reality when your applications have thousands of components, billions of metrics and hundreds of changes every day,” he wrote. “Humans can no longer cope with this complexity, they now need machines to do the leg work, process this Big Data and provide operational insight into what the f**k is going on.”

    Beedgen agrees. He suggested, “Increasingly, businesses will adopt machine learning technology for its usefulness in augmenting human understanding of complex interaction and large data sets by uncovering the unknown unknowns.”

    On some level this all sounds a bit scary. It seems as though the more we succeed at DevOps and the more DevOps evolves, the less humans are even a necessary part of the equation. Conceivably you could be so good at DevOps that you DevOps your way right out of a job or inadvertently launch SkyNet—or both.

    That scenario is simultaneously feasible and far-fetched. I suggest that you don’t fear that future or look at it as machines stealing your job or taking over humanity. Embrace the future of DevOps driven by AI and machine learning and find the silver lining. Seek out the new frontiers and horizons, because there always will be tasks that the machines simply can’t do without us—and that is where innovation happens.

  • Big Room Planning: Getting Everyone on the Same Page

    Many organizations—or even teams within organizations—are attempting to embrace DevOps. The operational and strategic advantages of DevOps over traditional business methodologies make it a virtual business imperative. One of the prevailing ideas about DevOps is that it’s about a culture shift more than tools and principles—and a big part of that culture shift is making sure everyone is on the same page.

    Rally Software—which was acquired by CA in May of 2015—provides software and services to help customers succeed with Agile development. One of the main components of the services side is to educate customers about the importance of working in harmony and guiding customers through a process called Big Room Planning. DevOps is a natural extension of Agile development principles to the rest of the business, so Big Room Planning can be an effective tool for DevOps just as it is for Agile development planning.

    I spoke with Steve Wolfe, director of Product Marketing for Rally, who explained the goal of Big Room Planning is to teach customers how to be more collaborative and help them get to a position where they’re able to respond faster to customer demand or market pressure. The idea is to foster an environment of collaborative planning that brings in the whole organization.

    “At Rally we’ve learned that delivering the most value from your software usually requires multiple, coordinated development teams—often distributed—working together and with the business,” Wolfe noted in a blog post. “Building software at this level is complicated, with a lot of moving parts, dependencies and competing priorities.”

    Many organizations—particularly organizations that already are familiar with Agile development—understand the value of consistent feedback and frequent iterations. Collaboration is a keystone of Agile. However, when you take that to a broader scale with DevOps, it becomes critical that all parties impacting—or affected by—the project be represented in the collaborative effort.

    Wolfe noted even in companies that use Agile development effectively, problems arise when teams work in isolation. Teams create plans that they agree on in their group, but aren’t realistic or don’t align with broader business goals. Meanwhile, other teams or departments don’t feel committed to plans they had no part in creating. The result is more like the traditional business model than DevOps: You end up with a situation in which any one team can halt progress and create a bottleneck.

    The Big Room Planning approach is intended to address that problem. The entire organization must be engaged, with full support from all of the affected roles and departments in the planning process. As the name implies, you need to get everyone together in a big room (or virtually via web conferencing, if necessary) and collaborate on a grander scale to make sure everyone agrees with and is committed to the plan.

    Wolfe also stressed that leadership support is essential. He recommends finding someone to champion the concept—an executive to lead the Big Room Planning effort. In and of itself, this idea doesn’t seem all that revolutionary; common sense dictates that development will flow more smoothly and business will function more effectively when everyone is on the same page and working toward the same goals. The crucial part is to not take it for granted and to use a strategy such as Big Room Planning to ensure more effective cooperation and collaboration.