Category: Features

  • Why You Need to Embrace Automation

    Just in case you hadn’t noticed: The robots are coming.

    Well, you probably had noticed. It’s hard to miss. Newspaper articles and blogs everywhere herald their arrival. The stories usually follow the same general formula: A catalogue of amazing things that robots (really, AI systems) can do. Debate about forced unemployment vs. people freed up to do more interesting work. And then some comments about whether it’s for the good or bad. You can generally infer the general tone from the choice of image accompanying the story: a cute Japanese robot with a plastic smile or a more sinister face with the Terminator’s jawline.

    Of course, workplace automation has been around for almost as long as we have had workplaces. Each new wave of technology disrupts the employment landscape in its own particular way. However, this time it’s serious: It’s not just manual labor that’s under threat, but increasingly, we’re told, white-collar workers are being supplanted by machines. A recent McKinsey report has generated a wave of headlines: “Even the CEO’s job is susceptible to automation,” wrote Patrick Nelson at Network World; and Ana Swanson at the Washington Post reported, “How robots will even affect the jobs of people we thought were immune.”

    Not surprisingly, a closer read of the McKinsey material gives a more nuanced appraisal than a headline can offer. Few of us will actually be replaced by a robot, but many workers will lose some part of their current jobs to automation. The McKinsey report states that up to 45 percent of the activities that employees perform today could be automated, but very few occupations will be automated entirely in the near or medium term. The things that require creativity and emotion remain uniquely in the domain of humans, and they are likely to remain there for quite some time.

    It’s against this background that we see a steady increase in what is often referred to as robot journalism: machines writing news stories. So far, these applications rely on scenarios where the general ‘shape’ of a story remains pretty consistent because of the regularity of the data underlying those stories. For example, a report on stock performance is always going to mention the current stock price, what the stock price was at some particular point in the past, the price highs and lows, and perhaps something on volume or analyst sentiment. These reports often are found in the back pages of a newspaper, and are the stories that few journalists actually want to write, since they allow almost no space for creativity and emotion.

    The reality is that today’s news-writing software is still a long way from replacing human journalists. Which is not to say that what a robot journalist produces isn’t useful; it surely is. Last month I spoke about robot journalism at the news:rewired conference. It was fascinating to see how most of the major news media are exploring how to get robots on staff. So while we’re going to see more robot journalists, it doesn’t necessarily mean fewer human journalists. A recent study by researchers at Oxford University and Deloitte explored how susceptible various jobs were to automation—journalists ranked 285th out of 366 jobs, with an ‘automation risk’ of just 8 percent.

    But if you really want to see where the action is regarding automated writing, just look at it from a different angle. Rather than Natural Language Generation displacing people from their jobs, it’s offering a solution to the problem of shortage: A shortage of workers or expertise. And that story isn’t about news; it’s the Big Data story. You can take issue with the astounding numbers that are thrown around, but even if they’re out by a factor of 10, they’re still significant: by 2020, about 1.7MB of new information will be created every second for each person on earth. But less than 0.5 percent of all data is ever analyzed.

    In 2011, McKinsey noted, “The United States alone faced a shortage of 140,000 to 190,000 people with analytical expertise, and 1.5 million managers and analysts with the skills to understand and make decisions based on the analysis of big data.” And subsequent reporting points to massive year-on-year leaps in demand.

    Regardless of how few or how many people are displaced by robots, they are not all going to become data scientists. The only way this volume of data will be analyzed and explained is if we have machines doing it for us. And that’s the real calling and promise of Natural Language Generation (NLG). Interactive visualizations and dashboards don’t cut it; the meaning in all that data will be lost unless we call in the robots. But you need more than robot journalists, tirelessly churning out one formulaic story after another. You need articulate robots that use sophisticated NLG to construct fluent narratives from idiosyncratic data sets. So, accept the data reality, embrace automation, and find an NLG robot to explain the insights buried in your data.

    About the Author:

    2,41 CWDr. Robert Dale, Chief Technology Officer and Chief Strategy Scientist at Arria NLG, is recognized as one of the world’s foremost experts in Natural Language Generation (NLG) research and Development, having authored or edited seven books and 160 papers on computational linguistics. He was a Professor in the Department of Computing, Director of the Centre for Language Technology at Macquarie University.  He co-authored the seminal textbook “Building Natural Language Generation Systems” with Arria NLG Chief Scientist and co-founder Professor Ehud Reiter.

  • 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.

  • Jenkins Founder Kohsuke Kawaguchi Talks DevOps Leadership, part 1

    Jenkins Founder Kohsuke Kawaguchi Talks DevOps Leadership, part 1

    Kohsuke Kawaguchi, founder 0f open source continuous integration tool Jenkins, was an early leader in DevOps, guiding the development of the Jenkins Project during his time at Sun (and later, Oracle) and plotting the course it would follow.

    “This project started as a hobby while I was at Sun,” Kawaguchi says. “From the project’s inception, it was not popular. During those early days, my leadership was really just to keep the project going. It was easy for me because the project was so useful that I didn’t need any external encouragement.”

    Once Jenkins steadily gained acceptance, Kawaguchi worked on polishing it and making it more user-friendly. “Writing software that works for you is much easier than writing software that works for other people, especially first-time users,” he says, noting he drew from his experiences supporting users to make Jenkins a better tool.

    Kawaguchi applied his previous open source project experience to make Jenkins an application/project that others could join, invest in and enjoy using. “As the project grew even more popular, I expended more conscious effort into those initiatives, specifically into extensibility and incentivizing sharing,” says Kawaguchi.

    Kawaguchi’s Vision for Extending Jenkins & Incentivizing Sharing

    Kawaguchi decided to use a plugin model for extensibility to solve the potential bottleneck of using an increasing number of contributors while managing change. Sensible software development does not permit unbridled change; developers must propose changes or at least innovate in an environment where they can retract changes that create issues.

    To attract more contributors into Jenkins, Kawaguchi decided to let people add whatever they wanted to it, through plugins. “Selling me on a software change need only happen when a change affects my use, so if we can split things up such that your change is in your plugin, I’m not affected by your change so long as I don’t use your plugin,” explains Kawaguchi. “This enables developers in the Jenkins Project to go from idea to implementation without getting blocked by someone, which reduces organizational overhead and encourages innovation.”

    But while this approach solves the extensibility issue, it also can create a new one. Without any incentive to share plugins with other users, extensibility can lead to siloed development in which only the group that created the plugin benefits from it. It then becomes difficult for the open source community to locate, leverage and improve on others’ advances, leading to plugin abandonment should the developer of that extension relocate to another project.

    Kawaguchi pressed for an update center and set a rule that plugins listed in the update center must be available to the entire community. “This created a positive feedback loop that encourages users to install plugins through the update center and developers to bring their plugins to the community,” says Kawaguchi.

    Breaking Down the Walls

    While extensibility and sharing accomplished much, the Jenkins Project faced another hurdle. Other projects such as the Apache Project use apprenticeships (the “committerships”), an approach designed to create a stable of tried-and-true contributors. But it also can be a hurdle, discouraging many developers.

    The Jenkins Project, however, simply asks that contributors apply good judgment when considering whether a plugin/change is good for the larger open source project and its community. “This might sound scary to some, but it really strikes the right balance between the speed of progress and quality,” says Kawaguchi. “Besides, everything is version-controlled, so if we later find a problem, we can always roll things back.”

    Stay tuned to devopsy.kinsta.cloud for the rest of Kawaguchi’s DevOps journey with Jenkins.

  • DevOps in 2016: The Year of Implementation

    DevOps in 2016: The Year of Implementation

    DevOps is the default software delivery approach for modern IT organizations and hyperscale startups that have incorporated the culture into their everyday integration and delivery activities.

    However, over the past year, these organizations have also started to recognize and acknowledge that there are challenges in certain aspects of the DevOps approach, including precarious security infrastructures, R&D team member burnout, and the need to close gaps between operations and development with dedicated personnel such as site reliability engineers (SREs).

    In 2015, we saw larger enterprises beginning to migrate to Amazon Web Services (AWS) and sketch out their plans to incorporate agile and DevOps methodologies. The implementation process necessitates changing cultural norms, and incorporating new tools and organizational processes. And with DevOps’ great benefits, my prediction is that in 2016, these enterprises will move from the drawing board to implementation.

    1. Companies will stop talking and start implementing. In 2016, DevOps culture will finally become mainstream (and not only for startups and tech-savvy companies) as more traditional enterprises jump on the bandwagon and start implementing real DevOps principles. IT leaders will need to figure out how to restructure their teams, adapt DevOps values, concepts and tools, and incorporate continuous integration and continuous delivery practices to do a better job of meeting user expectations of fast and agile delivery.

    Having said that, traditional IT organizations that deal with sensitive data and tight change management processes — such as those in the health, finance, and some government sectors — cannot compromise their strict IT delivery standards, especially if they have to comply with security and compliance protocols. Therefore, 2016 will still be just the beginning for enterprise-grade DevOps implementation in several specific industries and verticals

    2. SREs will bridge the gap. The growing movement of site reliability engineers (SREs) is being led by Google and has been introduced to the world as part of a practical and more mature DevOps adoption. SREs are software engineers who work in operations and are in charge of availability, change management, emergency response, and monitoring (among other things).

    Even early DevOps adopters such as LinkedIn have begun looking for dedicated individuals to fill SRE positions, which require ops as well as code-level management skills. In 2016, we will see an increasing number of discussions on SREs as well as more job opportunities for them, making this new class of engineers key players in DevOps implementation.

    3. High demand will mean high salaries. What we have seen within our company as well as among our customers is that dev and ops engineers with strong experience in working with and implementing DevOps are still a rare breed. As more and more IT leaders recognize the need to move to DevOps, the higher the demand and compensation will grow in 2016 for the limited number of experienced engineers.

    According to Puppet, DevOps engineers make noticeably higher salaries than most other IT positions and 55% of U.S. DevOps engineers earn $100,000 per year or more. While large IT organizations are building their own education and training plans in anticipation of the move to DevOps, the demand for experienced engineers will still continue to grow in 2016 and beyond.

    4. We will have more Big Data benchmarks. Over the past two to three years, the IT industry has embraced Big Data. Technologies such as Hadoop and MongoDB are commonplace now when it comes to extracting values from large data repositories. Today, companies in industries ranging from Adtech to online gaming to finance are already utilizing Big Data to enhance their core capabilities.

    Over the past year, we saw the rise of more solutions that help with implementation and presentation that aid in generating insights and enhancing user experience. Beginning next year, these big data solution vendors will leverage their unique positions and advanced technologies (such as machine learning) as well as their vast amounts of data to create specific industry benchmarks and best practices that will ultimately enhance customer satisfaction.

    5. Some companies will reverse-migrate to on-premise. Don’t get me wrong, we’ll still see AWS, Azure, Google Cloud Platform (GCP), and others continue to grow their user bases among next-gen companies as well as traditional organizations such as, the Guardian, which recently failed to build an OpenStack private cloud and consequently decided to go all-in with AWS.

    However, companies that have been using the public cloud for the past year or two will see their cloud bills start to soar (if they haven’t already) and look around for cloud solutions that better meet their resource-utilization levels and business model. I think we’ll see more of this so-called “reverse cloud migration” as the cloud business matures in 2016. This is actually a sign that this market is maturing and that people are past the super-hype phase and seeing the pros and cons of the public cloud.

    In Summary

    Of course, no one can predict the future, but the events of 2015 may hint at what we will see in 2016 — and that points toward an increasing implementation of DevOps practices.

    Some companies will manage to complete their DevOps cycles and have full-blown, continuous deployment straight to production. However, the majority will be challenged by even the basic implementation processes and needs such as which DevOps tools to use, how to reconstruct their organizations, and what state of mind to have.

    Still, DevOps will eventually be the norm when it comes to software development and delivery — it is just a matter of time.

  • What happened to the “Ops” in “DevOps”?

    The wave of digital transformation that has been enabled by cloud computing has provided both new opportunities and fresh challenges. On one hand, it is now possible for application developers to provide innovative new functionality to end-users almost instantaneously. One the other hand, this agility has created an environment in which users expect constant improvements and demand ever-higher levels of service. Indeed, the need to increase agility and quality simultaneously is largely responsible for the growing popularity of DevOps practices.

    When I ask customers who say they are “doing DevOps”, the conversation always seems to revolve around speed. Iterate faster. Turn out more innovations and new features – multiple times a week. Pull in microservices from this cloud provider over here, program in polyglot languages over there, virtualize and automate everything on no-name infrastructure, and do it all as quickly as possible. Leverage continuous builds and immediately push to production in a perpetual beta model. Test only at code-time, or even not at all and instead let the end-users test it for you. Forget about run-time instrumentation and monitoring — just get the feature out the door, wait for social media to report any problems, and in the meantime, move on to coding the next feature.

    It all sounds fun and productive, in the same way that dot-com-era rapid application development was fun and productive. And it certainly can reduce the cycle time on new features and provide opportunities to introduce new innovations. But that scenario as described isn’t truly DevOps, and it is built around a dangerous assumption about unlimited end-user tolerance for failures.

    Take a break from coding the next feature, stop, and read the first paragraph again. If you look at it, the only actual “Ops” in it is the automation used to enable the development process and push to production. In other words, it’s all “Dev” – as if all important activities stop the moment an actual user touches the application. But does that make any sense? After all, aren’t we building all of these cool new features for end-users? And isn’t the reason that we want end-users to consume these features that the applications support a business goal of some kind? And for end-users to consume these features, isn’t it important that our applications actually work and provide high levels of service in production scenarios?

    Here are a few tips to ensure there is some “Ops” in your DevOps efforts.

    1. Stop denying there is a problem. IT Operations is “so ten years ago,” many say, because the infinite elasticity of cloud and built-in exception-handling of modern programming environments renders all of that old-school NOC stuff as antiquated as the pager those folks used to wear. But that assumption is patently incorrect – just look at November 2015’s “Black Friday” shopping season, which was a mess for many online retailers, as noted in the Wall Street Journal, Business Insider, CBC, Express and the Independent. IT Operations is more important now, not less. DevOps without Ops is not sufficient.
    1. Eliminate operational information silos so you eliminate finger-pointing. Collaboration is a central tenet of DevOps and yet most people troubleshoot through inefficient “war rooms” full of individual component owners who are feverishly looking through their individual consoles to try and ensure the problem isn’t with “their” stuff. Many of those well-intentioned component owners bang their own heads against the table in frustration about how hard it is to even access the information they need in the first place, not to mention the fun job of trying to manually correlate timestamps and hostnames between their and others’ individual operational data stores. There’s no reason to perpetuate the silos of yesteryear – instead, put your operational data in one place, and let today’s machine-learning-powered management tools do the heavy lifting for you. You will certainly reduce finger-pointing, troubleshoot faster, and you may be able to eliminate the “war room” entirely.
    1. Monitor what (really) matters – your actual end-users. The concept of real end-user monitoring (monitoring the actual activity inside of browsers, mobile devices, etc.) has been around for a while, yet remains an under-utilized capability in most DevOps organizations – perhaps because it used to be technically hard to implement. But that was in the past – today’s next-generation application performance monitoring tools make end-user instrumentation simple to deploy. It’s important to see real user activity not only because end-users are the whole point of the exercise, but because server-side monitoring alone doesn’t tell you what’s actually going on. As late as June 2014, in an Oracle Applications User Group/Unisphere survey entitled “Performance Under Pressure: The State of Enterprise Web App. Quality and Availability,” 85% of customers reported that usually learn about application problems from end-user complaints – a staggering number which is actually up from 79% in 2009. There is simply no excuse for such a reactive view of monitoring.
    1. It’s in the logs! Logs are everywhere, but most organizations don’t use them because they are overwhelmed – logs contain too much data, they are too widely dispersed and too hard for humans to decipher. However, logs represent one of the best ways for development and operations to collaborate together, since the logging that is enabled by application and platform developers only becomes full of information in production. Next-generation management clouds that are designed to ingest big data at enterprise-scale can cope with today’s log data volume and velocity – which can be on the order of terabytes per day. Once the information is collected, your unified management regime automatically takes you to the few individual rows in the few individual logs that correspond to the exact problem you’re looking for (at the moment you’re troubleshooting), this mountain of data can become a treasure trove of information. Similarly, if machine learning algorithms can discover patterns and anomalies automatically, your logs can become ongoing sources of high-value IT and business insights. The data is there, you just need to use it.
    1. Planning is an everyday activity. DevOps organizations are necessarily often focused “in the moment” – but future business results depend on accurate advance planning. In most organizations, planning takes place in artificial time windows (calendar year, budget year, off-season, etc.) with incomplete information and a whole lot of guessing – and is often performed by analysts with no direct connection to the operational context. Instead of viewing planning as a once-a-year exercise in an ivory tower, regularly leverage analytical capabilities against your unified store of operational information to answer a variety of forward-looking questions. Your DBA wants to know if she has enough database capacity for next year? Analyze at the individual instance level. Your marketing people are worried that you can’t support their upcoming launch? Analyze at the application level. Your CIO wants to know where people are spending their troubleshooting time and the corresponding health of your entire infrastructure? Analyze across your entire estate. If you’ve followed my advice in steps 1 through 4 above, you have all the data you need already available. Now it’s time to use it.

    But hang on a minute, you say. Let’s not forget that we are doing DevOps for speed – and all this management, while clearly useful, could take forever to implement and slow everything down in the process. A few years ago, you might have been right. But technology marches on and today’s cloud-based management regimes can be leveraged instantaneously, with no changes to your infrastructure, and start providing the kind of value you need within minutes. With cloud-based IT Operations Management, your DevOps efforts can truly combine development and operations best practices while still delivering the speed you need.

    No more excuses. Put the “Ops” back in DevOps.

    About the Author/Dan Koloski

    UntitledDan Koloski is a software industry expert with broad experience as both a technologist working on the IT side and as a management executive on the vendor side. Dan is a Senior Director of Product Management for Enterprise Manager – Oracle’s integrated IT operations and Hybrid Cloud Management product line. Dan holds a B.A. from Yale University and an M.B.A. from Harvard Business School.

  • Never Mind the Bollocks, Here’s the DevOps

    Never Mind the Bollocks, Here’s the DevOps

    What is DevOps?

    “DevOps is a cultural and professional movement” –Adam Jacob

    [movement (n): a group of people working together to advance their ideas.]

    So, who are these people and what’s the big idea?

    The people are system administrators, developers, product managers, QA technicians, security analysts, network engineers, and anyone else involved in the business of developing software.

    The big idea is to increase the value your product or service delivers, more quickly with less effort.

    (Having a product or service that is designed and built well isn’t inherently valuable. The value comes when your customer is able to use your product or service to solve a problem. DevOps is all about delivering value quickly and effortlessly.)

    DevOps practices and technologies are evolving, but here are some of the core concepts paraphrased–be sure to read the links in the footnotes for the full explanations:

    The Three Ways

    • Systems Thinking
      • Learning how everything is interconnected, from concept to customer
    • Amplifying Feedback Loops
      • Cutting the time between action and reaction, failure and success
    • Culture of Continuous Experimentation and Learning
      • Recognizing failure is important data about how and where to improve

    CAMS

    • Culture
      • It’s about how people relate and work, not something you can buy
    • Automation
      • Faster, less error-prone processes help amplify feedback loops
    • Measurement
      • You can’t get where you want to be until you know where you are
    • Sharing
      • Effective teamwork ignores organizational boundaries

    ICE

    • Inclusivity
      • Everyone is responsible for (and benefits from) these practices
    • Complex Systems
      • Because simple systems are simple
    • Empathy
      • Real collaboration requires real understanding of another’s point of view

    That’s the theory from a very high level; the following Q&A provides some broad explanations of related concepts. These are actual questions I was asked in a recent discussion of DevOps.

    Q: What specific skills or experience do I need before I can put “DevOps” on my resume?

    A: It depends. At this point in time when recruiters and/or hiring managers list DevOps in a job posting they are almost always looking for a “DevOps Engineer” (i.e. a sysadmin who knows just enough coding to be dangerous), or a “full-stack developer” (i.e. a developer who knows just enough about system management to be dangerous). The reality is that (as of today) there is no DevOps certification, organization or even manifesto, so anyone who pretends to authority on what is and isn’t DevOps is overstating their case at best, a charlatan at worst.  

    Q: What is source control?

    A: Source control is a repository for files that make up a modern software application during development. It maintains a historical record of changes so it’s easy to review (or rollback to) changes made to an application’s source files. The most popular source control technology today is Git, and GitHub is one of many online services used to manage Git repositories.

    Q: What is Jenkins?

    A: Jenkins is to task engines or “build servers” what Kleenex™ is to facial tissue. It’s currently the most widely used software product for automating various functions of software build and deployment. For example, a system might be configured such that any code change pushed to source control triggers a job in Jenkins to build, test and deploy that code.

    Q: What is configuration management (e.g. Salt, Ansible, Puppet, Chef)?

    A: Configuration management is a means of scripting server configurations so it’s easier to track, deploy or make configuration changes to large groups of systems.

    Q: What are containers?

    A: In the same way that server virtualization allows you to have many isolated “virtual machines” on a single physical machine, container technology allows you to have many isolated application environments on a single operating system. Containers have been around in Unix/Linux for a long time, they just boomed in popularity when Docker came along and made them easy to use. The next version of Microsoft Windows Server (2016) will introduce Windows containers.

    Q: What are microservices?

    A: Microservices are small, independent components of a software application that are built, tested and operated in isolation from the core product. Using microservices enables development to be faster and more nimble than possible when working with a large, monolithic application.

    Q: What is Continuous Integration/Delivery/Deployment?

    A: Continuous Integration is the practice of continuously integrating (and testing) new code with your existing source code. Continuous Delivery is the practice of automating as much of the build/test/release process as possible while still requiring a manual push to production. Continuous Deployment is the practice of fully automating build/test/release all the way into production.

    Q: Are there any conferences or meetups I can attend to learn more?

    A: Yes! The original DevOps conference is DevOpsDays and there are many of these events around the world annually. A popular conference with large enterprises is the DevOps Enterpise Summit.  Various DevOps-related meetups (#CoffeeOps on Twitter) are springing up around the country. Check the CoffeeOps.org website for details, or search for DevOps at Meetup.com.

    Q: [Do I need to understand everything above | Is this all I need] to be or do DevOps?

    A: Absolutely not, on both counts. You can successfully implement a DevOps way of thinking/working by incorporating all or just some of the above, and there are many other tools and practices around delivering value more efficiently. Naturally there are extensive resources available (a few linked in the footnotes) to do a much deeper dive on all these subjects.  

  • 7 things 2016 has in store for the future of DevOps and IT

    7 things 2016 has in store for the future of DevOps and IT

    With only a couple weeks left in 2015 it’s time to start looking ahead to what next year has in store. Let’s be honest—most of us have already mentally checked out for the holidays anyway, so it’s already 2016 for all intents and purposes. I spoke with a handful of industry experts to get some thoughts on what we have to look forward to in 2016.

    Let’s just jump right in:

    1. Log Management will play a larger role

    According to Christian Beedgen, CTO of Sumo Logic, log management will emerge as the most underrated opportunity for IT. “Thinking about log data may seem too far in the weeds for most tech industry professionals. However, using analytics to monitor, manage and gather insights from logs will be the only near-perfect way to make sense of the increasingly complex and cloud-based architectures.” Log management isn’t exactly new or cutting edge, but Beedgen believes that 2016 will see more vendors trying to move into the log management space, and more organizations trying to use log management to make sense of their big data mess.

    1. Business leaders will demand better insight

    On a similar note, Rick Fitz, senior VP or IT Markets for Splunk, believes that analyzing data and metrics will also play a role from a business strategy perspective. “In 2016 we will see data science demystified, moving from Ph.D. to MBA, with easier ways emerging to consume, analyze and correlate machine data. As business leaders increasingly go digital, this will result in greater “digital insight” into engagement, satisfaction, competition, effectiveness, response, revenue and other business goals.”

    1. Sharing economy will transform IT

    Companies like Uber and AirBnB have transformed entire market segments. The sharing economy has changed the way businesses engage customers and deliver services, and that includes IT through aspects such as cloud services, microservices, APIs and more. Fitz predicts, “Next year this ‘Uberfication of IT’ will turn into a ‘Balkanization of IT,’ driving stakeholders to demand better insight, governance and control of federated technologies to integrate adoption, usage, monitoring, security, cost control and more across shared services.”

    1. Enterprise DevOps will grow rapidly

    The DevOps revolution has taken IT and app development by storm in recent years, but most of the traction has been in startups or smaller businesses that have more freedom to shift gears and embrace new concepts. Enterprise adoption has been growing, but at a much slower rate. Andi Mann, chief technology advocate for Splunk, said, “In 2016 we will see rapid acceleration of DevOps with 50 percent or more of large businesses finally adopting ‘Enterprise DevOps’ — a pragmatic, scalable approach to adopting the culture, process and technology changes at the heart of DevOps.”

    1. The singularity approaches

    OK. That may be an ominous over-statement. In a nutshell, Sumo Logic’s Beedgen claims that the line between machines and humans will continue to fade. The foundation of this is automation—leveraging technology to perform mundane or routine tasks and sift through mountains of data exponentially faster than a human can. As artificial intelligence evolves, though, the scope of what can be automated expands as well. “In automating processes, a human can today wield the power of a legion of operators with a single hand,” stated Beedgen. “Likewise, machine learning will increasingly be adopted for its usefulness in augmenting human understanding of complex interaction and large data sets by uncovering the unknown unknowns.”

    1. Automation and analytics will improve IT service health

    DevOps and microservices have transformed many areas of development and IT infrastructure, but many organizations still rely on decades-old monitoring tools, arcane metrics, and specialized admins dedicated to managing the cumbersome process. Splunk’s Fitz thinks that is getting ready to change. “In 2016, IT analytics will be liberated as easy-to-use dashboards will correlate all sources of service health—legacy tools, APIs, mobile apps, Web logs, wire data, containers and more—while predictive analytics will automatically respond to prevent quality issues.”

    1. DevOps is here to stay

    From the point of view of DevOps practitioners or companies that have adopted DevOps tools and practices, this may seem both painfully obvious, and yet still be good news as well. Christian Beedgen predicts not just that DevOps is here to stay, but that the importance of DevOps and the sphere of influence affected by DevOps will expand. “Increasingly, DevOps will permeate all manner of businesses that rely on information technology to compete. Bimodal IT (the practice of managing two separate, coherent modes of IT delivery) will become the equivalent to “private cloud”—the last forced resistance of the old guard. Both will be forgotten in a short number of years, as public cloud and lean and agile processes dominate the businesses that still compete.”

    There you have it. Now you can enjoy your holiday break in peace and come back in 2016 with an idea of what you have to look forward to in the year ahead.

  • Getting Rugged DevOps Right

    Getting Rugged DevOps Right

    Two Perspectives

    Jack, an accomplished application security pro, tells me, “The developers won’t talk to us.  It’s like we speak a different language.  They are releasing new builds so fast, how could they check each one for security vulnerabilities?  We can’t move as fast as they do.”

    Then in the next moment, Diane, a DevOps pro, let’s me know, “Our current security team’s tools and practices can’t keep up with the pace we have now established.  If it doesn’t fit, it doesn’t get done here.”

    I have heard this little ditty ‘bout Jack & Diane so often in the past two years, it could be a hit record. I imagine you have heard it too.

    The Slow Lane Won’t Lead to Rugged DevOps

    Let’s visit Jack’s world, first.

    When visiting a well-known bank last month, they shared insight on their current application security practice.  They have 10 full-time people employed (offshore where personnel costs are lower) to analyze a set of 100 applications.  The bank has over 2000 applications, but the security practice can’t scale to access their entire portfolio.  In 2.5 years, they had only been able to cover 5% of the application portfolio.

    The application security team employs an application security tool originally built for waterfall-centric development timelines.  As much as they want it and need it to move faster, it is not really for “continuous” velocity.

    Each scan of an application can require anywhere from four hours to two days to get an assessment report.  The reports average about 30,000 potential defects which then require further analysis.  That analysis may take up to two weeks in order to sift through thousands of false-positives and false-negatives.  While this security practice is critical to the bank, it cannot keep pace with development practices that are aiming to go much faster in order for the bank to remain competitive in their industry.

    The Continuous Gap

    Sound familiar?  It should.  This scenario is playing out all across the DevOps and Continuous Delivery landscape.  It is reflective of what I call “The Continuous Gap”.

    Leaders in Rugged DevOps practices aim to minimize the “Continuous Gap”.

    In Diane’s world, DevOps teams pursue “shift left” strategies in an effort to build quality in from the beginning.  Shifting left enables them to bake in the right code, components, configurations, and practices from the beginning.  When done right, velocity increases dramatically, while operating costs are minimized, and unplanned/unscheduled work is reduced.  Investments can then shift more in favor of innovation over upkeep and maintenance.

    The Old-School Rub

    Jack’s world of traditional application security practices often wait to check for security vulnerabilities at testing or release stages of the SDLC.  There are two reasons for this: (1) some security tests like static or dynamic analysis can take hours or days to perform and (2) security teams cannot embed themselves earlier in the SDLC (due to political, organizational, or operational obstacles) without dramatically slowing development in a high velocity world.

    If you are using old-school application security tools, you will continue to be blocked from getting more deeply entrenched in development.  New velocity requirements call for new approaches.

    The New-School Shifts Left

    A number of newer application security solutions and practices been introduced recently that are development and developer-centric.  For example, imagine if build managers could analyze every open source component used in every build for known security vulnerabilities.

    What if, developers could access information inside their IDE that would inform them if a component they were planning to use in an application was known to be vulnerable?  What if developers had access to spell-check like alerts of security issues as they were creating their code?

    Furthermore, imagine if information was available that not only told the developer of a known security defect, but directed them to an alternative safer version of that component to use.  Components would be automatically vetted against corporate security policies at the instant they were chosen by a developer.  When 90% of an application is composed of open source and third party components today, automatic analysis early in the lifecycle save millions of dollars.  This how Rugged DevOps rolls.  This is Diane’s world.

    The evolution of Rugged DevOps is forcing application security practices to shift left.

    But Diane’s world (and your’s for that matter) are not just about increasing velocity.  All organizations need to consider operational costs to both detect and remediate security vulnerabilities in their applications.  We all realize that the further along we are in the application development lifecycle the more costly fixes become.  Feel free to apply your own cost figures to the chart below, but you should also note that these calculations do not include breach cost, help desk calls, maintenance, time-to-market, reputation or stock price.

    Rugged DevOps
    Cost considerations for Rugged DevOps practices compared to waterfall approaches.

    Rugged DevOps: Shifting Gears…Quickly

    Shifting from old-school to new school approaches doesn’t take long.  On a recent visit to one of the largest insurance companies in North America, they shared their tale of transition.  Of five major applications that run their business, one in particular had 40,000 different files that needed to be analyzed.  Their old-school approach involved a lot of manual code investigation and required about two-and-a-half weeks to complete the analysis of that large application.  The new approach that used automated analysis of security vulnerabilities took two minutes — and produced identical results.

    A government tax office wanting to shift security analysis of applications from hours (outside of development – Jack’s world) to seconds (inside of development – Diane’s world) was able to complete the first pass analysis of their existing portfolio of 600 applications within two working days.  The security team was not only faster at identifying known security vulnerabilities in applications, but could also quickly identify alternative open source and third-party software components that were safer to use.  The security team was not simply discovering issues, but the new class of Rugged DevOps solutions were aiding in guided remediation.

    Questions to Ask About That Rugged DevOps Solution

    There are several companies and open source projects that now offer application security solutions that work at extremely high velocity.  When exploring solutions to match the velocity of your Rugged DevOps practices, consider asking the following questions:

    1. How long does it take to complete the analysis of a small, medium, and large application?
    2. Do developers use these tools, or are they only meant for security personnel?  Do you have members of development teams that act as positive references for your tool?
    3. Does the analysis require further investigation of the findings, or does it pinpoint the root cause of the issue?
    4. Does the solution only identify vulnerabilities or does it help guide remediation of issues?
    5. What is the balance of false positives to positive alerts generated by the solution?
    6. How many people are employed to support the solution in environments similar to ours?
  • DevOps and IT Support: 4 Principles to Keep Your Team Ahead of the Curve

    DevOps and IT Support: 4 Principles to Keep Your Team Ahead of the Curve

    Here’s the million-dollar IT question: what is DevOps and why does it matter to IT support?

    Short answer: DevOps advocates collaboration between Development and IT Operations. It’s about constant communication, breaking down silos and a culture of collaboration. The DevOps movement has made great headway and many companies have adopted and are employing DevOps practices – Netflix, Amazon and Google to name a few.

    But where do IT support teams fit into a DevOps environment? 

    When developers launch new features and services, it’s the support team that deals with issues and interactions with frustrated customers. Change is often the enemy of stability. But because innovation can’t be stopped, IT support teams need to catch up. That means making their operational environments resemble the way their software is developed. The problem is that IT agents and developers have different methodologies, work in different systems, and practically subscribe to different technology religions.

    The silos only exacerbate the challenges that the support team ultimately faces:

    • Scattered data limits incident and problem understanding.
    • Deployment failures have a high risk of downtime. And too often, changes are made that IT support doesn’t know about.
    • Support feedback often represents customers, and doesn’t always get communicated to development, product owners and product managers.

    DevOps is ultimately a culture change. When all teams commit to a collaborative approach and common goals, it can shift the entire mindset from silos to working together to deliver better services. Agile, Lean and Kanban are popular approaches that facilitate rapid iteration, learning and information sharing. This means you shorten the feedback loop necessary to drive business agility.

    CAMS, DevOps and IT support

    How do we put DevOps principles into practice for IT support? Over the past 20 years, IT has built up a strong governance model based on ITIL and that can’t be forgotten overnight. While putting new practices isn’t easy, the best way to make big concepts real is a model that covers people, processes and systems. Luckily the CAMS mode coined by Damon Edwards and John Willis at DevOpsDays Mountainview 2010 [1].

    It stands for Culture, Automation, Measurement and Sharing.

    Principle 1: Culture

    The model leads with culture, as it’s the most important facet to DevOps. Support teams learning from and supporting DevOps practices requires a cultural shift. While command and control is comforting, DevOps calls for speed and agility. Daily or weekly rituals can facilitate this cultural shift. Some rituals you can apply to your IT support team include:

    Be sure to focus on results, not just the activities. It’s not about the number of changes but the results of those changes.

    And finally, understand team behaviors. Culture is a result of habits. You need to understand how your team works together, and what you can improve.

    Principle 2: Automation

    To move fast, you can’t do everything by hand. Automation is another principle of DevOps, but is most effective when it supports the people and processes in place.

    Go from trapped knowledge to shared knowledge

    • Known errors should be tracked at the time of deployment and communicated to support. Sound simple? You’ll be surprised how often it doesn’t happen.
    • Support should link articles to incidents and problems, so everyone understands what’s causing the issues

    Shift from orphaned tickets to linked tickets

    • All teams should be responsible for ticket linking and documentation- including the service desk, admins, developers, and operations, so everyone knows what’s going on.
    • Link incidents, problems and requests to all associated changes and releases.

    Don’t just deploy, but support

    • Continuous integration, continuous delivery, and continuous deployment are core to the First Wave of DevOps – thinking about the performance of the overall system. Support needs to be prepared to support, operate and ensure their ability to restore services. They need to know what’s being deployed and when, so they can give the right answers to the customer.

    Help with testing

    • Automated testing is key to a DevOps environment. Every time a developer commits code, they need to make sure all the code is operating the way it is expected to. If it breaks, tests can catch failures before anything is deployed and delivered. Support teams hold data about various customer environments that should be continuously fed back to testing.

    Keep up with monitoring data

    • Proactive monitoring helps developers stay ahead of problems before they snowball. In the same vain, support teams can identify customer problems faster by keeping aware of proactive monitoring and linking it back to their own incident management systems.

    Principle 3: Measurement

    Keep track of metrics that matter. Once you’ve established your individual and team goals, It’s important to measure how you’re tracking to those common goals. How long does it take to recover from failure? Try measuring ‘Mean Time To Repair’ (MTTR) and whether it increases or decreases over time. Here are a few other metrics your support team should keep in mind:

    • How many repeated issues do you have? Measure repetitive incidents and how often they occur in a period.
    • Are you meeting your targets? Measure service level targets in your service level agreements and operational level agreements in the context of deployments.
    • What are your costs? What’s your cost per incident, along with the total cost of support? Take this in context with downtime costs. In some cases, increasing support costs may be the best thing to do to minimize impact to the business.

    Principle 4: Sharing

    And lastly, when it comes to sharing, ask yourself these questions:

    • Does the organization understand what we’re doing? Do we share that understanding?
    • Do all teams understand each other’s goals, hardships and priorities?
    • Does your team’s outputs of processes flow with other team’s processes?
    • Is knowledge shared across teams? If it’s in a system, is it accessible?
    • How is your team collaborating with others? Are there unbarred channels for communicating?
    • Are the right stakeholders kept in the loop of your projects, even if they’re not in your immediate group?
    • Do your IT groups – development, operations, testing, support and even the business – share ownership of successes, failures and learnings?
    • Do teams share tools and information? If not, do those tools integrate with each other?

    Faster, better IT service is about culture, sharing and tools that enable your teams

    A collaborative culture is critical to success in DevOps. Aligning support and development can help your organization understand what services the business wants and needs to be productive.

    About the Author/Sid Suri

    Sid Suri-2Sid Suri is the Vice President of Marketing for JIRA Service Desk. He’s worked in various technology marketing roles over the last fifteen years at Salesforce.com, Oracle (CRM), InQuira (acquired by Oracle) and TIBCO Software. He has an MBA from the Haas School of Business and a bachelors in Economics and Italian from Middlebury College. He lives in San Francisco, California.

  • Why we are still fighting with the same problems in DevOps as 15 years ago

    Why we are still fighting with the same problems in DevOps as 15 years ago

    One thing that continues to fascinate me is how after so many years I can still walk into IT organisations and see basic practices not being followed (e.g. Software Configuration Management or Continuous Integration or …). Shouldn’t we all know better?!? I recently came across some slides from the late 90s and early 2000s that pretty much read like something that comes from a DevOps conference today. So I wonder what is it that has prevented us from being better today and I think I found a feasible answer to my question.

    For illustrative purposes I have used the Accenture DevOps maturity model, but feel free to use any other model here as the tendency would be similar. I believe that as an industry we used to be better than we are today (of course all generalisations are dangerous, including this one). While it is hard to find hard evidence for this, let me try to justify my perspective.
    DevOps Journey

    More than 10 years ago we had much more custom development to solve the big problems and most work was done onshore in collocated teams. The only way to be more productive and reduce cost was to have better engineering practices and leverage more automation, hence companies invested in this. We used to be on the mature end of consistent in many places. Then two trends caused us to regress as far as engineering practices are concerned:

    • Offshoring – With the introduction and mastering of offshore delivery, the industry had an alternative to automation and good engineering practices as labour arbitrage was providing a quick fix to cost reduction. It was potentially cheaper to do something manually offshore than maintaining or introducing automation onshore. Of course this couldn’t last as the labour cost offshore increased steadily. Some organisations stayed the course of engineering practices and automation others lost maturity along the way. This trend is similar to the same trend in manufacturing where manual labor became so cheap that automation wasn’t a critical element to cost reduction anymore. Those companies who went offshore did not sufficiently focus on automation and good practices as it was harder to oversea this with across locations and cost reductions were easy to achieve.
    • Packaged and proprietary Software – As we leveraged more and more packaged and proprietary software we relied on those vendors to provide the solution to our productivity challenges. This led over time to island solutions, which supported specific packages, but are not open enough to integrate into the IT ecosystem. How do you baseline an enterprise wide software package when configuration management is hidden in a package or worse still configuration is only possible through a graphical user interface with no access to the underlying source code/text files? The pre-packaged software was a quick fix to get functionality, but again the good engineering practices were lost out of sight. And many organisations make so many customisations that they should really treat the original “COTS” just like any other application with the same rigor. The other problem that packaged software introduced is that the people customising them are often considered or consider themselves not to be programmers (which means they don’t have to worry about those practices that the custom application developers use), a dangerous mistake in my view.

    “Speed is the new currency of IT and businesses”

    This was all well and good when cost as expressed by the cost of a day of labor was the main driver for optimisation in organisations. This paradigm has shifted and nowadays speed to market is driving incentives and behaviour. Organisations across the globe are trying to find ways to speed up their delivery processes without risking quality. But how do you now revert the trend that many organisations followed – your IT organisations is mainly outsourced and/or offshored, you have an application architecture that is a mix of packaged software, proprietary solutions and custom elements and you lack the engineering experience and skills to fix it.

    This is where we need to acknowledge that DevOps is a journey that is different for every organisation. Of course there are the engineering driven organisations like Etsy, Amazon and Facebook that have engineers/IT people in their C-suite of executives who intuitively understand the importance of application architecture and good engineering. I believe they won’t ask you for a business case for what is ultimate an optimisation for speed and flexibility – they understand how important good IT is – at least I believe that to be the case. They will also consider which applications to introduce into their ecosystem and making sure that those are open products for which good engineering practices can be employed. In other organisations the adoption of DevOps practices needs to be supported by business cases that are often difficult to create (especially in the middle maturity levels where the pain is not at mission-critical levels and the full benefit of highest maturity is not yet in arms reach). Organisations that are on this journey with the majority of us in the industry need to acknowledge the sometimes intangible nature of improvements. Speed to market and other cycle time measures should be the guides for your journey.

    “Everyone is on the DevOps journey, whether you know it or not”

    The question whether “you are doing DevOps or not” is not valid in my view. We are all on the DevOps journey, it’s the journey of improving delivery of IT solutions. DevOps is a broad field and provides us with an ever growing toolkit of practices and tools. All of us IT Executives are on the search to improve our organisations and our delivery capabilities. What label we use for that doesn’t matter as long as we keep moving forward and keep experimenting. Is there a goal to this journey? No, I don’t think there is concrete goal, a state when we declare we are done. I think the best of us will keep pushing forward no matter how good we are getting at it and from what I have seen during my travels there is still plenty of road in front of me that I can see and I don’t need to worry about getting “there” anytime soon in any case. Join me on the journey and may our paths cross to share stories of our adventures on the road.