staging-devopsy.kinsta.cloud

Tag: devops

  • Why the DevOps Trinity is Key for Digital Transformation

    Why the DevOps Trinity is Key for Digital Transformation

    As digital technology continues to disrupt and transform businesses across industries and around the world, the ability to deliver high-quality software rapidly will make the difference between survival and extinction for many companies. DevOps seeks to change the dynamics in which operations and development teams interact. Ultimately, successful adoption of DevOps and the process of continuous delivery are likely to determine whether an organization thrives or fails in the digital age.

    To build a sustainable DevOps culture and achieve true DevOps success, organizations need to consider the DevOps Trinity—people, processes and tools—and understand how to connect all three:

    People and Culture

    The core tenet of DevOps is a culture of collaboration and shared goals, which eliminates finger-pointing and promotes teamwork, with everyone working together in support of the same outcome—reliable software quickly delivered to production. In essence, the goal is to enable the different stakeholders in the software development and delivery process to reach the mutual understanding and empathy needed to drive alignment on shared goals. To achieve this change, teams need to have trust, honesty and responsibility.

    Process and Practices

    DevOps aims to achieve predictable, efficient, secure and sustainable operational processes. Using a DevOps approach, simple processes become increasingly programmable and dynamic. Automation supports this objective by using technology to streamline the steps within the process.

    Tools and Technologies

    Some categories are more essential in a DevOps toolchain than others, especially continuous integration (build) and infrastructure as code (configure) tools. The common elements of the toolchain include applications for coding, building, testing, packaging, releasing, configuring and monitoring. Often, rather than a single tool, there are sets of tools (or toolchains) of multiple tools, that make up the process.

    A sustainable DevOps organization cannot be achieved without all three components of the DevOps Trinity.

    For those looking to learn more about people, processes and technology needed for successful DevOps implementation, join us in San Francisco Sept. 16-19 for DevOps World | Jenkins World. With this year’s conference theme “TRANSFORM,” attendees will learn how organizations are transforming software delivery, adopting DevOps and returning business value to their organization from DevOps initiatives.

    Don’t miss Viktor at DevOps World | Jenkins World! Be sure to register today for 20 percent off your registration using the special staging-devopsy.kinsta.cloud code just for our readers: JWDEVOPSCUST

    — Viktor Farcic

  • When DevOps and ITSM Collide: Mistakes to Avoid

    When DevOps and ITSM Collide: Mistakes to Avoid

    In many ways the DevOps movement evolved as a reaction against the worst elements of IT service management (ITSM). IT leaders wanted to get from under the yoke of overly complex processes, bureaucracy and red tape to speed up software delivery, and to just get stuff done. Now that DevOps has kicked into full gear at so many organizations, the question remains: What do we do about ITSM?

    While the instinct in some may be to completely ditch ITSM or to just let the ITSM team operate in a separate orbit from DevOps practitioners, experts say that would be a big mistake.

    “DevOps aims to deliver high-quality software to the business faster and in shorter cycles,” explained Krishna Mohan Reddy, vice president and deputy global head of Cognitive Business Operations at Tata Consultancy Services. “However, it still does not eliminate the need for controls.”

    In many ways ITSM is the yin to DevOps’ yang—the two operating philosophies do offer contrasting viewpoints but when the operate in a single system they can be extremely complementary and synergistic.

    “Maintaining the proper balance between the ITSM and DevOps helps the organizations to scale and grow and become more organized,” said Sachin Agarwal, DevOps engineer and solution architect for Mantra Labs. Operating at DevOps speeds with ITSM frameworks in place keeps finger-pointing at a minimum and reduces the risks of failed deployments. “Both in harmony will increase the efficiency and reduce the blame-game within the organization.”

    As organizations try to figure out how to achieve that harmony, here are some pitfalls they should seek to avoid:

    Letting Each Tribe’s Preconceived Notions Hold Back Overall IT Progress

    It can be easy to get wrapped up into dogmatic fervor that your particular philosophy is the One True Path for IT success, but that really does nobody any favor. Organizations that want to pick up the best of both ITSM and DevOps need to encourage stakeholders to approach the table with an open mind.

    “You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications,” said Andi Mann, chief technology advocate for Splunk. “And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

    For DevOps practitioners, it’s important to keep in mind that ITSM controls such as service requests, change management or structured management of incidents and problems don’t have to stop a team from delivering quality software at speed, said Troy Vetter, COO of Coda Global.

    “In fact, speed and quality are actually helped by being closely monitored. In IT, just like in science, if it isn’t seen, measured, and “reproducible, it doesn’t really count,” he noted. “So, ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

    Failing to Address the Elephant in the Room: Change Management

    Analyst Roy Atkinson agrees that ITSM has a lot to bring to the table for DevOps workflows. ITSM’s rich history in thinking about and tracking operational best practices offers tons of value in improving the customer experience with the software being delivered. But on the flip side, ITSM teams can’t continue to operate as they did in the past. They need to compromise and learn new ways of accommodating DevOps approaches—particularly in the area of change management.

    “Change management has often been where DevOps and ITSM collide,” said Atkinson, who analyzes the service management market for HDI. “The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

    The good news is that thought leaders in the ITSM world have been thinking hard about this issue and have been evolving practices so they can embed change management controls into a DevOps framework without holding back continuous delivery.

    “There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment,” Atkinson said.

    Maintaining Separate Toolchains

    Often times one of the big reasons ITSM will remain a roadblock for DevOps isn’t because the ITSM folks aren’t willing to collaborate, but simply because each team relies on completely separate toolchains.

    “You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool,” said Donna Knapp, curriculum development manager for ITSM Academy and author of the DevOps Institute’s course on ITSM for DevOps. “So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

    As Vetter explained, a lot of the knee-jerk DevOps reaction against ITSM has to do with an aversion to the historical view of ITSM requiring manual inputs in monolithic ticketing systems. But the technology of ITSM controls has advanced—it just needs to be appropriately implemented.

    “Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools,” he said.

    — Ericka Chickowski

  • Revisiting My Bet on DevOps

    Revisiting My Bet on DevOps

    On Dec. 29, 2015, I bought some stock. It was a bet on DevOps that my wife kindly tolerated. Since then, the S&P 500 has risen 31 percent and my DevOps portfolio is up 113 percent. This blog is a retrospective on a bet that worked out.

    I was inspired by Nicole Forsgren’s talks and the “State of DevOps Report,” whose data showed better profitability, market share and stock price performance among companies claiming to do DevOps well. DevOps, after all, exists to help the business win, and as digital transformation sweeps industry after industry, technologists increasingly are in a position to make that difference.

    My process has been very, very simple: Companies whose talks at DevOps conferences convincingly convey a passion for DevOps are ones that I would consider buying. Would I do deep research on each one? Nah—whatever I could research aside from DevOps would already be priced in by people who understood that content better than me.

    At the one-year mark, I summarized the results. The crazy project was up 12 percent against an S&P that was up 8 percent—a nice little win. The first six months of 2018 have been tremendous, though: The S&P is up almost 2 percent and the portfolio is up 42 percent.

    A key disclaimer is that I am trying to read corporate culture from the outside. For insiders, I am sure I will have some of this comically wrong.

    Remixing the Strategy (and Portfolio)

    Over the past year and half, I’ve made a handful of trades based mostly on two triggers.

    The first trigger is a signal that a company is losing its commitment to DevOps. I did this with Nordstrom: Its DevOps leaders all moved on to different companies. For example, Courtney Kissler went to Starbucks and Suzanne Conniff was off to T-Mobile. About the same time at a meetup, a Nordstrom employee told me that DevOps had fizzled. I was out. In the last year, Nordstrom is up 7.5 percent while retailers I kept are up: Target 46 percent and Amazon 74 percent. That said, Target is a bit of a difficult case.

    The second trigger is silos. I worry about an either IT-centric view of DevOps or DevOps in just a small slice of the business. Before I invest in a new stock, I want to know the transformation is taking root enterprise-wide.

    Barclays for Bank of America is an example of chasing the all-in company that didn’t work out: negative 8 percent growth versus 25 percent at BoA. Overall though, shifting toward all-in and unicorns has been solid.

    Who’s in Today

    • Amazon: 121 percent
    • Barclays: -15 percent
    • Capital One: 26 percent
    • Cisco Systems: 52 percent
    • Etsy: 340 percent
    • Live Nation: 93 percent
    • Netflix: 235 percent
    • Nike: 20 percent (since December 2017)
    • Target: 0 percent

    Amazon: Amazon’s net gain at 121 percent looks a lot like the portfolio as a whole (113 percent). The shares I purchased in 2015 are up 150 percent. The company is a natural fit, given that its CEO wrote the “two pizza rule” and demands microservices. It is also a hedge, as the company directly competes with much of this list including Target, Netflix and Etsy. With cloud and DevOps often joined at the hip, Amazon’s cloud revenue is also a rough proxy for DevOps growing overall.

    Barclays: Did I invest in a British bank shortly after the Brexit vote? Yeah. It was a bit of a test of the “Everything except DevOps is already priced in” rule. This one hasn’t panned out, but from the outside Barclays is among the banks doing best at DevOps.

    Capital One: Has performed about average among banks that I looked at this morning. I adore its start-up attitude and how the company goes about getting talent and contributing to the community.

    Cisco Systems: Cisco has had some great talks and is undergoing a digital transformation of sorts of its own. The company is doing fine.

    Etsy: Holy cow, Etsy. Etsy is an interesting case in that it has been a DevOps darling for many years. With the stock flagging a bit, the CEO and the CTO (our DevOps hero, John Allspaw) were shown the door and the perception was the grown-up business types were taking over. I increased my bet based on the thought that technical foundations pointed ruthlessly at business problems might work out. When the stock price doubled, I cashed out my original investment.

    I’d be better off had I not sold any, but with as volatile as Etsy is, I was happy to route some of the winnings over to a bet on Nike.

    Live Nation: I saw a great talk from a Live Nation guy at DevOpsDays Rockies, and the company’s stock has paid off nicely since, nearly doubling. Live Nation gets it, and shows a passion for satisfying customers. Being Ticketmaster, it has had a risk of digital disruption knocking it down for years and has built up a strong innovation capacity—exactly what incumbents need to do.

    Netflix: DevOps skills? Check. Good at using data to delight customers? Check. Worth twice what I bought them for? Check. I wrote most of this analysis in early July. Since then, Netflix has had a bad earnings call. It’s still a massive winner so far.

    Nike: I loved Nike’s talk at DOES 2017. But what really struck me was DOES London. In the morning the company spoke about a one-team culture and engaging digitally—good stuff. In the evening a colleague complained his kid was spending $200 on sneakers. A week later, Nike’s stock spiked 10 percent. Yup.

    Target: Oh, Target. Target has done some great DevOps work, but word on the street is that too much of what it did at first lacked a connection back to the business. However, since the security fiasco with stolen credit cards, that has turned around. While its stock is right around where I bought it 2.5 years ago, the last year has shown strong momentum: Target is up 45 percent in the last 12 months.

    2018 Has Been Great

    Over the project’s first two years, I had a nagging worry: I was beating the market, but was I just picking riskier stocks and being rewarded in a bull market? So far the market has been flat in 2018, showing modest 1.7 percent growth through June 30. The DevOps Portfolio, however, is up 42.2 percent.

    Only the banks are trailing the S&P.

    So What Have We Learned?

    • It’s about customers and the business: There appears to be a moment of DevOps backlash when alignment to business outcomes isn’t quite strong enough. When the DevOps culture is strong but redirected back to catering to the business, things can go better. That’s one way to read Target and Etsy’s recent performance. When the transformation fizzles … see you, Nordstrom.
    • Banks may be different: This system really hasn’t worked out terribly well for me in the banking space. I suspect that is because most banks are undergoing similar transformations and may not be as able to differentiate as retailers do. At DOES London we heard similar stories from RBS and Barclays while Lloyd’s is winning DevOps awards at other conferences. I also lacked representation from the digital disruptors—PayPal would have been a good balance to CapOne or Barclays.
    • DORA should be a hedge fund: I hope they have a secret one.

    I’m thankful my that my wife was on board with this little project and I’m very happy that we can take our winnings here as we plot our second honeymoon.

    Of course, professionally I’ve been betting on DevOps a long time, working on UrbanCode continuous delivery tools the last 15 years. That worked out with an acquisition by IBM as it beefed up its DevOps solutions portfolio.

    — Eric Minick

  • 7 Signs You’re Mastering Continuous Integration

    7 Signs You’re Mastering Continuous Integration

    A majority of organizations think they are doing continuous integration (CI), yet when asked if they are following key practices of CI such as running tests to validate every build, many of them aren’t. Ask yourself the following: “Are we building our application with every change, or at least multiple times a day? Do we avoid long running feature branches? Do we prioritize fixing broken builds over committing new changes?” If your answer to any of these questions is “No,” then guess what? You are not truly doing CI—and you’re not alone.

    Continuous delivery (CD), a foundation of DevOps, is built on the practices of continuous integration. Accordingly, you have to implement CI properly before you can truly achieve success with CD and DevOps. In other words, you have to crawl before you walk.

    Steps to Mastering Continuous Integration

    To reach business goals, here are the seven practices organizations must do to master CI:

    Automate the Build—the Entire Build—on a Central Server

    This seems like an obvious one—and it is. Sure, prior to implementing continuous integration, organizations either build locally on a developer’s desktop, have a build engineer manually integrate code or have to work through a series of fragile, manual steps that are prone to error. But, surprisingly, many organizations that claim to practice CI still get this one wrong.

    Simply put, your continuous integration build should run a central shared server, be able to run completely unattended and be automated such that the same input will produce the same, same output every time.

    Build as Frequently as Possible

    Teams practicing CI build multiple times per day, ideally triggering the build per change on a pull request, merge or commit. Building per commit enables errors to be found as soon as they are introduced and are more easily fixed.

    The word “continuous” in continuous integration should be taken as literally as possible. Often times when I ask organizations how frequently they build, the answer is one of the following:

    1. We do “push-button” builds, X times per-week
    2. We build both every night, and once per week
    3. We build once per-day at X time

    As you have likely deduced, these are not “continuous” builds. They may be central builds, automated builds or scheduled builds. But those don’t provide the benefit of continuous integration. If a build breaks and you have two days of 30 commits by 10 different developers, you may have to sort through all of that work to figure out and correct the cause of the build. Productivity killed.

    Commit or Merge to Mainline Frequently

    Teams doing CI are likely committing/merging to trunk or main with every change or at least once a day.  If you are maintaining long-running feature branches, for instance, you are not getting the benefit of validating integrated changes frequently. If you branch for a long period, when it is merged, the integration has been delayed and you may be left with conflicts or bugs to fix.

    Build Quickly

    If you are practicing continuous integration, your build likely completes within 5-10 minutes.  If builds take longer (some organizations have five-hour-plus CI builds), not only are you delaying integration and, therefore, valuable feedback, but developers are less likely to commit changes because of the cost to their productivity—or, even worse, they continue to commit against broken code.

    Take time to optimize your build and validation time. This may require you to decompose your CI build process to align with components or teams and then validate the entire integrated application as a separate step in the overall development process.

    Validate the Build

    CI includes validating the changes and resulting built. This kind of testing should be a part of the overall build process. If your only validation is based solely on confirming the software compiles and links, then you are not truly practicing CI. Most teams practicing CI include code scans and unit tests in the CI build.

    Validate in a Production-like Environment

    Mature CI practitioners ensure consistency between the dev, test and pre-production environments. The most mature are using VMs or containers, service virtualization and other techniques to ensure they are performing validation in a production-like environment and reducing the risk of discovering errors downstream in pre-production or production, well after changes were integrated.

    Fix Broken Builds Immediately

    As mentioned, it’s critical that teams find and fix issues quickly so that they don’t move downstream. With CI, processes are set up where builds are validated and committed continuously, so if something is problematic, it’s easier to fix. If broken builds are ignored, the issue will be more difficult to find and fix, but worse is the culture it encourages. CI is based on a quality-first approach. If the build breaks,“Stop the line” and fix the build. Everybody will be better for it in the long run.

    Don’t Forget About Culture

    If an organization can look at these seven signs and say it does all of these things, then it is really doing CI. These may seem simple, but when these principles are combined, the outcome is remarkable.

    Organizations that can’t say they follow each of these principles likely will have problems delivering functional builds regularly. The initiative will fail and team members will become frustrated and revert back to their old ways. Not only will there be a process issue, but also a cultural issue—and this is where many organizations get stuck.

    Teams must change how they work together and they must also make sure they are aligned in their mindset. CI has many benefits for organizations, but don’t forget that it’s actually designed to embrace failure, not eliminate it. Continuous integration creates a system where developers can fail fast, so they can find and fix errors early and quickly.

    Continuous integration is one of the foundational elements to a real DevOps transformation, which everyone knows is a top priority for many businesses today. Getting it right—truly getting it right—is essential to keeping up with modern business needs.

    — Brian Dawson

  • Integrating Blockchain and DevOps

    Integrating Blockchain and DevOps

    Blockchain is one of today’s hottest technology buzzwords. And at the same time, the concept of DevOps has achieved acceptance and is gaining momentum. Blockchain and DevOps already offer a number of benefits individually. Together, they can provide significant tactical and strategic advantages. However, some challenges must be overcome simply to adopt blockchain, as well as to successfully merge blockchain and DevOps.

    What is Blockchain?

    Let’s start with an overview of blockchain. Many people mistakenly conflate cryptocurrency and blockchain, because many of the key features of cryptocurrency are a function of blockchain. But blockchain is a separate and unique concept that has applications and benefits far beyond cryptocurrency.

    Blockchain is a distributed account ledger, the use of which enables data to be processed and stored securely. Blockchain relies on three core concepts—peer-to-peer networks, public-key cryptography and distributed consensus that is based on the resolution of a random mathematical challenge. Reliance on these three concepts allows blockchain transactions to be secure and relatively anonymous. Every transaction is recorded in the ledger as a data block that is appended to the end of the chain of previous transactions. No group or individual owns or controls the ledger, and all parties can view the chain of transactions, ensuring transparency and integrity.

    A number of key features make blockchain attractive. Data is validated across all participating nodes, which eliminates the need to reconcile transactions. The use of distributed consensus provides a high degree of confidence, but transactions in the chain also can be verified easily. Blockchains are immutable—new data can be appended, but blocks of data already in the chain cannot be modified or removed. Finally, blockchain reduces costs and improves the efficiency of processing transactions and storing data due to its decentralized architecture.

    The challenge facing organizations wanting to adopt blockchain, however, is how to incorporate it seamlessly with DevOps development processes and culture.

    DevOps for Blockchain Development

    Organizations need to address challenges in three major areas to take advantage of blockchain: culture, process and tools.

    On the culture front, the success of blockchain depends on support at the executive level as well as adequate budget and resources for proper implementation. If you can’t find champions within the organization to drive the blockchain cause, your project is doomed before it starts.

    Whether you’re building a blockchain within a single company or a blockchain network that includes nodes outside your organization, obtaining widespread agreement on the technology and blockchain processes can be an issue. The absence of widespread industry adoption or any sort of standardized tools or processes adds complexity.

    Finding the right talent can also be a problem—and once you find it, you may have to pay a premium to obtain it. According to a recent article in TechCrunch, “Blockchain-related jobs are the second-fastest growing in today’s labor market; there are now 14 job openings for every one blockchain developer.”

    From a process perspective, blockchain is an emerging concept that lacks mature management principles or design standards. The process framework, and the different roles involved, are still unclear. Most organizations lack expertise concerning the blockchain application stack and environment; in addition, the metrics that should be monitored to measure efficiency and performance are not yet well-defined.

    The absence of development tools is another major hurdle for blockchain. The developer tools currently available for the blockchain ecosystem are unreliable. The blockchain ecosystem still needs an integrated development environment with good linters and plug-ins, a build tool and compiler, a deployment tool, documentation, testing frameworks, debugging tools, logging tools, security auditing and analytics. While some versions of these tools exist, they are not yet adequate to meet the needs of blockchain developers.

    It is also important to understand that, although many blockchain implementations are based on open source technology, blockchain isn’t free. Keeping track of transactions requires hardware, networking bandwidth, electricity and processing power. Because a blockchain ledger is distributed, transactions aren’t just processed once—they are processed on every node in the blockchain network. As a trusted network grows, the associated costs skyrocket. These expenses can be a barrier that prevents smaller organizations from experimenting with the technology.

    Integrating Security into DevOps

    If you are thinking about implementing blockchain, some of the core principles of DevOps—specifically DevSecOps—come in handy. DevOps is built on the concept of breaking down silos within an organization and enabling each team and individual to take responsibility for the project as a whole, rather than separating tasks by role.

    To implement blockchain successfully, you need a system that rewards innovation and supports teams of individuals who work together to address any issues. Integrating DevOps and security fosters stronger application security throughout the software development life cycle and helps with blockchain development efforts as well.

    The shift-left philosophy and the push for automation are DevOps principles that also will serve you well with blockchain. Integrating security earlier in the life cycle—shifting left—and incorporating automated security testing and security bug tracking are essential. The blockchain network needs to be tested for performance and latency, which will vary depending on the size of the network, the expected transaction size, the consensus protocol used and the associated required latencies. It is also important to determine whether the integrity of the network and the shared blockchain ledger is maintained while testing throughput.

    To maximize efficiency and productivity, put processes in place that allow you to consistently monitor and adjust, based on feedback. Track individual and overall security vulnerabilities, the amount of time it takes to detect them, the amount of time it takes to remediate them, and other factors relevant to application security. These metrics should be visible to every individual so that each can understand and take ownership of the appropriate elements.

    Blockchain and DevOps

    Blockchain technology is poised to change the way business is conducted today due to its promises such as of secure, immutable, peer-to-peer decentralized trust networks with distributed consensus, shared account ledgers and smart contracts.

    These same advantages, however, introduce a host of additional considerations to blockchain-based applications and make for greater testing challenges. Not only is the change in technology significant, significant changes are also necessary from a business process standpoint. While blockchain applications will have to go through standard testing and validation, including functional testing, integration testing, security testing and performance testing, they also will require additional specialized testing for smart contracts and peer/node testing.

    DevOps practices can provide great value to organizations under pressure to become more customer-centric and innovation-focused. The efficiency, quality and consistency that adopting DevOps provides is exactly what is required for traditional organizations looking to embrace the leading-edge technology known as blockchain.

    — Tej Aulakh

  • Serverless Computing: Moving from DevOps to NoOps

    Serverless Computing: Moving from DevOps to NoOps

    Developers rejoice as serverless computing ushers in a new era of ‘NoOps’ to replace the ill-fitted DevOps model.

    While some organizations do better than others when it comes to implementing DevOps, almost everyone agrees it’s a concept easier penned to paper than pinned to reality. The idea of integrating development and operations is smart, but the implementation proves troublesome. A replacement option is thus largely welcomed by developers everywhere.

    Enter the new concept of NoOps, which means dropping operations from any consideration during the development cycle. It’s not that operations are being ignored; that would be a foolhardy step backward. Rather, NoOps means never having to worry about where the code runs and, thus, developers are freed from giving operations another thought.

    “Serverless computing allows users to run code without provisioning or managing any underlying system or application infrastructure, and they automatically scale to support increasing or decreasing loads,” explained Gartner serverless analyst, Arun Chandrasekaran, in a blog post.

    Amazon sparked interest in serverless computing when it announced AWS Lambda at its re:Invent conference in 2014.

    “I’d argue that the precursor to serverless computing is cloud IaaS, where the complexity of underlying resources—servers, storage and network—was hidden from the users, and with IaaS providing flexibility to provision unlimited compute, storage and network resources on-demand, Chandrasekaran said.

    Serverless: To Use a Server or Not? ‘Tis Not the Question

    Serverless computing is a developer’s dream not only because there is no longer a need to worry about where the code is going to run, but also because there is no need for direct access to the operating system to manage that code. The result: Developers can focus solely on coding—the very thing they do best!

    That statement would be easier for some to understand if it were not for the utterly confounding term “serverless.” Obviously, anything requiring computing involves servers, so saying this process is serverless is simply nonsensical. While the term is unfortunate and bordering on meaningless, the concept is solidly real and more than a little familiar.

    For all practical purposes, serverless is just another word for cloud but with a bit of a twist—pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

    Deploying Code with NoOps in a Serverless Environment

    Additionally, the term “serverless code” can be used either in conjunction with code deployed in traditional styles such as microservices, e.g. loosely coupled/SOA. Or, code can be deployed in the form of full applications that can be written to require no provisioned servers.

    In serverless environments, jobs are scheduled on-demand, meaning as data comes in and is available. It can be automated so that a job runs once data is received. This means that jobs run only when data exists and otherwise sit idle, where they can’t burn resources.

    Economies of scale also completely change in serverless computing. That’s because serverless delivers the ability to put some intelligence behind when and where jobs run, so that they can be spun up and spun down as quickly and economically as possible.

    Bottom Line

    Opting for NoOps, meaning working in a serverless environment, is really a choice to be more intelligent about how resources—hardware, software and people—are being utilized. It is about cutting resource waste and associated costs, while enabling talent to focus on writing innovative code.

    No job will sit there burning resources and waiting for the data to come in. Rather, the job runs on demand, as you need it, in milliseconds and without distracting you from other tasks.

    “NoOps still requires connectivity so beef up your connectivity to your cloud providers, if you haven’t already. And you’ll eventually have to troubleshoot slow serverless functions as a ‘network problem,’” said Andrew Lerner, an analyst at Gartner in his post.

    To gain even more advantages in serverless computing, and perhaps to make up for time lost in network troubleshooting, no matter how small, look for and use reusable code everywhere you can. Drag-and-drop interfaces that enable fast use of reusable code frees developers further, so they can shorten both the development and testing cycles. Time economy is important in modern day continuous release cycles. A NoOps and reusable code strategy can dramatically improve your time and resource economies of scale.

    — Laurent Bride

  • Making the Database Key to DevOps

    Making the Database Key to DevOps

    Here are three best practices for doing DevOps with the database

    The speed of business today demands that the development and deployment of applications is fast-moving, with frequent yet error-free releases. That’s why the adoption of DevOps is trickling down from Amazon, Facebook, Google and the other usual suspects to every company that relies on technology to drive its communications or sales with users.

    The database is now entering the picture, too, because when front-end applications are changed, there often needs to be a change at the back end to accommodate it. Redgate’s 2018 “State of Database DevOps Survey” found that more than one-third (35 percent) of organizations are deploying database changes either daily or more than once a week.

    Some are working even faster, with companies such as online travel provider Skyscanner moving from releasing database changes once every six weeks to 95 times a day when it first introduced database DevOps—and increasing the frequency since.

    This accelerated speed of delivery is a key benefit of database DevOps, with 28 percent of respondents to the DevOps survey quoting it as the biggest advantage. But as releases become more frequent, so, too, does the chance of something going wrong, along with the difficulty of pinpointing the exact cause in a large, complex, fast-changing environment.

    Database DevOps Best Practices

    Even with the most comprehensive testing, issues can occur. And as more and more developers now work across both the application and database, and with larger, more disparate teams, companies need the ability for everyone to drill down quickly to identify and fix issues.

    Achieving this means bridging the database and application worlds by focusing on three key areas.

    Deployment Choice

    Different developers and database administrators will use specific tools to deploy database changes. This can depend on their experience, skills or simply that they have a preference for a particular way of working.

    You need to be able to allow this choice, but without affecting the ability to track down issues. Therefore, ensure that you have a monitoring tool in place that can pinpoint not just when and where changes were made, but which tool was used. This will help quickly find the root causes of any issues, by providing the full context around the problem.

    A Single View

    Data is the lifeblood of many businesses—companies now have more and more databases within their organization, often spread across different locations. However, no matter how complex your IT environment or the size of your estate, you need to be able to monitor database performance from a single place. That way, you can easily identify issues and pinpoint precisely which database is being affected.

    Wherever a database is, and whatever the distance it is being monitored from, the monitoring also needs to be in real time, with updates in seconds, not minutes, providing the reassurance that you always have the latest picture of what is occurring. This enables you to become more proactive, spotting developing trends and issues such as deadlocks or blocking processes, before they affect your users or overall performance. Having a single, up-to-date view is therefore essential when integrating the database into DevOps processes.

    Fast, Customizable Alerts

    The ability to make frequent, reliable, repeatable changes to the database as well as the application is integral to DevOps flows, and monitoring them means evaluating dozens of different parameters constantly.

    Clearly, it’s impossible to keep an eye on everything that is happening, even when events are condensed to a single monitoring screen. Therefore, ensure you’re able to easily create and customize alerts for specific parameters that are important to your business, so that they don’t get missed. This enables you to better understand DevOps processes and ensure that you have early warnings of potential complications, no matter where they occur.

    For the database to be an integral part of DevOps, organizations need a complete, interoperable view of their entire estate so  they can track down problems, monitor processes and spot issues before they affect users. That view should be equally available to the whole DevOps team, including developers, so they can see immediately what effect their latest change is having and take the appropriate action to fix any breaking change while it is still fresh in their mind.

    Only then can databases take their key place in DevOps flows, eliminating bottlenecks and speeding up development to meet fast-changing business needs.

    — Matt Hilbert

  • Transforming with the Cloud: If Not Now, When?

    Transforming with the Cloud: If Not Now, When?

    The question of whether to move to the cloud is no longer relevant for most organizations. Migrating workloads to the cloud has already become an inevitable requirement for a vast majority of companies regardless of their sizes, and if your organization isn’t doing that already, then it is simply the question of when and how you’ll consider doing so.

    The agility, redundancy and elasticity with regards to scaling compute resources present a compelling need to move to the cloud sooner than later, let alone other factors such as reduced overall capital expenses associated with managing a robust on-premises infrastructure. The finance sector is usually a little behind in embracing major changes in IT operations because of their strict regulatory compliance requirements and the complexity in their application portfolio as a result of several mergers and acquisitions. These restrictions are quite common, especially with insurance companies, but surprisingly there are several major insurance companies that have made significant investments to modernize their traditional applications and migrate them to the cloud for efficiency, agility and cost reasons.

    To effectively support the business that constantly strives to be highly competitive and to reduce the time-to-market, most applications development efforts are planned in an Agile fashion with short sprints that produce usable deliverables within a few weeks. When development teams go Agile, it is important that all other associated services operate in a similar manner.  Without agility in infrastructure provisioning and other support services, it is simply impossible for the development teams to be successful in producing deliverables at high velocity. A commonly heard complaint from most of the application development teams is about the delays from infrastructure teams on provisioning servers. Provisioning a virtual machine (VM) takes more than three weeks in many companies, even today. This is due to a variety of factors such as work backlog, complexity in approval processes, compliance requirements, lack of automation and several others that are organization-specific. IaaS and PaaS offerings from cloud leaders such as Microsoft Azure and AWS address these issues to a great extent. Even if companies are not ready to migrate their existing applications to the cloud, they should seriously consider IaaS and PaaS from well-established cloud providers for new applications being developed.

    There are several factors that could influence IT leaders’ decisions on their strategy regarding cloud and some of the areas that certainly cannot be overlooked are discussed here. The purpose of this article is to provide a general high-level overview, especially for companies that have been hesitating to migrate their workloads to the cloud. It should be noted that we are barely scratching the tip of the iceberg in this discussion.

    Complexities in the Application Stack and Infrastructure

    It is not uncommon for organizations to be overwhelmed by complexities and issues with their current infrastructure setup and get bogged down dealing with their day-to-day operational challenges. Due to these ongoing issues, one might develop a false notion on the actual effort involved in migrating to the cloud and may even wonder whether it is an achievable target state. It is important to map out the current infrastructure that supports the business applications and have a clear view of the complexities, dependencies and licenses that are in play. The application servers, database servers, storage arrays, enterprise messaging bus, document management systems and several other key components that work together to power your key business applications need to be taken into consideration. This will not only help decide the right applications that are suitable for the cloud, but will also help pick the right cloud provider to suit your needs. You can notice the convergence of IaaS and PaaS as it is becoming difficult to separate one from the other. Most leading providers are offering these services as a package.

    It is better to categorize your applications based on their level of complexity and shape up your cloud strategy accordingly. Standalone applications that simply require a web server, application server and database server are ideal candidates for your first phase of migration efforts. You can ensure that with the right architecture on the cloud, there will be better availability, load balancing and performance and less maintenance overhead for your standalone applications.

    Amazon Elastic Compute Cloud (EC2) provides availability of 99.99 percent and its auto-scaling feature allows automatic scaling of the fleet up or down depending on the needs to maximize performance and minimize cost. Similarly, Microsoft Azure offers VM Scale Sets that can be configured for your applications to scale automatically. If the requirement is to develop brand new applications for the cloud, the options are endless. As an example, .net based web applications to be hosted on Azure can be developed to be run as Docker containers.

    Containers and the management of a cluster of container nodes have come a long way since their inception. Docker Swarm and Kubernetes have drastically simplified the management, load balancing and scaling of containerized applications. Containers are not only for your new applications; they also come in as a great solution for modernizing your legacy/traditional applications and migrating them to the cloud.

    Storage

    Identity and access control used to be prevalent challenges in the past, but cloud providers have greatly simplified identity management services such as application authentication, user management and single sign-on by providing rich features to support the information security and compliance requirements of organizations. Microsoft Azure offers Azure Active Directory and provides a few different protocols such as WS-Federation, SAML-P and OpenID Connect to authenticate the user. It also supports multi-factor authentication. For brand new applications that are developed using Visual Studio 2017, it is extremely simple to integrate the application for authentication and authorization workflows on Azure AD using the above protocols.

    Databases play a vital role in the decision-making process when it comes to migrating to the cloud. Senior IT managers are usually highly concerned about the security of data while technical personnel are worried about ensuring storage, performance, recoverability and availability. Application developers and DBAs end up spending a great deal of time fixing code or other application configuration parameters even when databases are simply migrated from one server to another within the same data center. Cloud solutions address such concerns. Microsoft Azure, for instance lets you migrate your native on-premises SQL databases to Azure SQL Database Managed Instance by providing the native virtual network (VNET) support. You don’t have to change your applications as a result of this migration. The Managed Instance offered by Azure is quite promising and it is certainly a great solution for migrating large numbers of on-premises SQL Server databases to Azure. Similarly, managed database services are offered by AWS for both relational (RDS) and NoSQL (DynamoDB) databases. Amazon EC2 service is integrated with Amazon RDS and Amazon VPC to provide a complete, secure solution for computing, query processing and cloud storage including, but not limited to, a wide range high-performance web applications, DB servers and batch processing needs.

    Disaster Recovery

    Cloud providers offer data centers in several regions around the world. It requires a major investment for any organization, both financially and operationally, to match the redundancy and recoverability provided by major cloud providers. Even organizations that have a highly virtualized infrastructure setup have physical infrastructure for some of their mission-critical applications. The reasons for having such a setup could be argued, but the costs associated with setting up a disaster recovery environment for such infrastructure would be significant. To ensure comparable performance and capacity, the disaster recovery environment is typically a replica of the production environment that is underutilized most of the time, consuming significant investment.

    Planning for setting up a disaster recovery site involves considering several factors such as, ensuring compute capacity and scalability (servers and storage), networking (bandwidth, load balancers, switches, routers), identity management (directory services, authentication, authorization), facility to host the DR site (location, floor space, power, air conditioning) and operational aspects (personnel, monitoring, alerting, break-fixing, hot-hands support). Cloud providers give you the option to choose the location of your DR site anywhere in the world. Depending on the contract you have with your cloud provider, you could either quickly deploy compute resources on your DR site on the cloud or utilize the necessary automated processes to switch over to an already running replica of your application environment on the cloud DR site.

    There are numerous features that AWS offers to address each of the above-mentioned aspects that need to be considered for setting up a disaster recovery site. Amazon Machine Images (AMIs), for example, lets you preconfigure images with the operating system and your application stacks. It is also possible to configure your own AMIs to allow the recovery process to launch these images automatically in the event of a disaster, saving a significant amount of time.

    Microsoft also provides highly dependable DR alternatives on Azure. You can use Azure as your secondary site for DR purposes or completely eliminate the need for data centers by picking different Azure regions as primary and secondary sites. Azure offers the Active-Passive and Active-Active topologies. In case of the active-passive topology, all user traffic flows to the primary region while preparing the secondary region to take over at any point since the database runs in both regions with a synchronization mechanism implemented between the regions. Active-active topology ensures running of cloud services and databases on both the primary and secondary regions and user traffic goes to both the regions. In the event of a failure at primary, all the user traffic will be directed to the secondary by simply disabling the DNS at the primary region. Auto-scaling features of Azure will allow the scaling up of compute resources in the secondary region as needed.

    DevOps Maturity

    Any discussion on migrating to the cloud would be incomplete without highlighting the significance of a solid DevOps practice to complement the cloud strategy. From a technical standpoint, companies that settled on Linux environments used to have a slight edge over those that went the Microsoft route, especially with regards to implementing open source solutions and technologies that support DevOps and cloud initiatives. This is highly arguable now as Microsoft has not only opened its gates wide for several major open source tools but also allowed for better integration of several leading open source products such as Docker, Jenkins and Puppet with ALM tools such as Microsoft TFS 2017.

    Depending on the goals of an organization with regards to its cloud strategy, the level of maturity required from a DevOps perspective needs to be analyzed. DevOps can be looked at from infrastructure as well as applications development perspectives. If your goal is to use cloud services only for IaaS, it will be extremely valuable to develop strong, infrastructure-focused DevOps capability, practices, processes, tools and automation. Through proper scripting and integration with IT services management (ITSM) tools such as Service Now, the entire process—from requesting infrastructure through having them provisioned with all the patches, hardening, etc.—can be fully automated by leveraging tools such as Chef or scripting via PowerShell. Features such as metered billing and quotas that are already offered by cloud providers can be leveraged and integrated with organization units’ budgets, approvals and other processes to establish a well-managed, fully automated infrastructure provisioning process.

    Organizations considering leveraging the cloud for applications development are definitely at an advantage compared to those considering development on-premise. Microsoft, for example, offers IaaS at a highly competitive price and provides Visual Studio Team Services (VSTS), a cloud version of Team Foundation Services (TFS), on Azure. The PaaS services offered by Azure are also quite extensive, along with integration with a variety of open source tools. With this combination, developers have a complete, end-to-end solution to address all their requirements without losing time in waiting for environments to be set up. DevOps can play a significant role here. With a fully integrated continuous integration (CI) framework, the developers could commit code to a managed Git repository on the cloud, and automated continuous integration can be kicked off via VSTS, which handles the build, automated testing, code quality control, building container images, automated spinning up of infrastructure needed for an environment and deploying code or containers on the environment following a fully integrated change control process and quality gates. Developers can focus fully on developing code and enjoy the freedom of being able to deploy code on a transient environment on the fly to test their code before it goes through other phases of testing. In highly competitive business environments, this provides the ability to perform multiple production deployments in a single day if need be.

    Organizations with a high level of maturity in DevOps are the ones most likely to leverage cloud to its fullest potential. Similarly, those that are striving to attain this level of maturity are likely to get there sooner by moving to the cloud. Developing the expertise, building the process framework, and implementing the right DevOps tools will make it easier to solidify your cloud strategy.

    Compliance & Security

    Several organizations have refrained from migrating to the cloud mainly due to the strict compliance and security requirements that are mandated by the industry. Companies that are still hesitating to embrace the cloud are those that are skeptical about the security of their data on the cloud. Irrespective of the cloud provider or the strict SLAs and contractual terms that you may have with them, you are still accountable for the data that you own. So, it is extremely important to understand more about the security setup and the features offered by your cloud provider to secure your valuable data on the cloud.

    As the owner of your organization’s data, you have to know where your data is going to physically reside, what kind of encryption will be applied to your data at rest and in transit, who will physically have access to your data, how your data will be segregated from other tenants’ in a multi-tenanted environment, what recovery processes exist, what the regulatory compliance certifications that the provider has obtained are and answers to many more questions. Security experts highly recommend classifying your data based on risk levels and devising a strategy accordingly. You may decide to host your most critical data on-premises and use the cloud for other types of data.

    Microsoft offers a very comprehensive checklist and reports to help you assess the risk to your organization in moving to the cloud. Both AWS and Microsoft are certified by almost all major regulatory bodies with regards to data security and compliance. However, as outlined earlier, while your provider can take the responsibility to host your data in the most secure manner, you as the owner of the data will still be accountable for its integrity and security. So, this is an area that requires thorough analysis before you decide on your workloads that need to migrate to the cloud.

    To Make the Long Story Short …

    While savings on capital expenses is a given, this is not the prime motivator for most organizations to migrate to the cloud. As stated in the Gartner report, “Cloud Computing Primer for 2018,” the role played by cloud in this decade is way beyond simply setting expectations and providing a platform for better economic models. Digital initiatives such as artificial intelligence (AI), internet of things (IoT) and several other technological innovations and disruptions are fueled by digital platforms that cloud offers. Agility, scalability and flexibility, on the other hand, are certainly some of the key drivers that would encourage companies to migrate to the cloud. Furthermore, reducing your time to market can be better accomplished by moving your development workloads to the cloud. The combination of IaaS, PaaS and a solid DevOps practice to automate deployment of infrastructure and application stack makes cloud far more superior to running applications development on-premises. Companies that haven’t invested much in DevOps should seriously consider doing so before it is too late.

    Containers, the tools and practices to orchestrate, load balance and scale microservices add a completely different dimension to how cloud services could be further leveraged. They help ensure seamless, defect-free, repeatable deployments, and with the necessary automation to spin up transient environments, it is difficult to match the benefits of using containers on a fully automated IaaS in an on-premises setup.

    The auto-scaling features offered by cloud providers make cloud a far more superior alternative compared to hosting internally. The elasticity provided by cloud helps with scaling compute power, storage, load balancing and several other infrastructure services as needed, without having to make massive hardware investments.

    Cloud providers offer solid disaster recovery options and support. Implementing an active-passive or active-active primary and secondary sites is a lot more straightforward and easier to set up on AWS or Azure than doing it on-premises.

    Compliance and security are also important factors that could drive the cloud strategy. It is important for decision makers to evaluate the risk factors and then decide on the type of data that could reside on the cloud as opposed to staying internally.

    NetworkComputing provides interesting statistics on public, private, and hybrid IaaS adoption in their article, “IaaS Cloud Adoption Trends.” The article further refers to research from Interop ITX and InformationWeek on how organizations are moving and managing workloads to the cloud. Per their findings, several companies are expected to deliver over half (67 percent) of their IT and business services through the cloud in the next year. Of all the companies they surveyed, 31 percent plan to allocate over 50 percent of their budget to cloud initiatives.

    With a clear strategy, budgets, categorization of applications, prioritization and staff with the right expertise, you can be sure that your journey in moving your workloads to the cloud will be a pleasant one.

    — Sridhar Asvathanarayanan

  • Software Development: A Better Way to Measure Success

    Software Development: A Better Way to Measure Success

    Here’s a metaphor for software development you probably haven’t heard before: It’s like flying a plane. You have a starting point and a destination in mind, there’s a good chance you’ll change course midflight, and … sometimes you get a little nauseated?

    Okay, it’s not the best analogy. But there is one aspect of piloting a plane that offers valuable insight into how to measure your team’s performance more consistently. It’s called the performance-control technique, and it may be the best method you’ve never heard of for keeping your engineering teams aligned behind a common goal.

    Imagine for a second sitting in the cockpit of a plane, surrounded by clouds. Forget using the ground to orient yourself; you have nothing but your instruments and wits to guide you. It’s a situation I’m plenty familiar with, having taken flying lessons out here in rainy Seattle. In those cases, you use your altitude and power settings to set up a particular control scenario that results in your desired output, whether it’s ascending, descending, straight and level or turning. And then you monitor your performance—in this case via altitude, vertical speed and airspeed indicators—to verify that you’re achieving your desired output.

    Now unless your software development pipeline is irredeemably broken, you are probably not flying completely blind as you work to build and ship new features. But the technique still applies: Choose your control metrics (time to release, for example), and then set up a series of performance metrics to keep it on track.

    Cloudy Skies Ahead

    The greatest strength of the performance-control technique is its acknowledgement that any control can result in unintended consequences. Take reducing the time from check-in to release. It’s a fantastic goal: The quicker you get code into production, the quicker you deliver updates to your customers. The quicker you do that, the quicker you get feedback and respond to their needs. The quicker you do that, the quicker you can iterate on features. And the cycle continues.

    But it’s also a goal that can result in unintended consequences: When you single it out for attention, it’s only natural team members will want to do everything they can—at the expense of almost everything else—to achieve it. That’s not to say they want to do wrong; rather, they’re just trying to be good citizens. (And, okay, they don’t want their name to show up in a report about why the team didn’t meet its quarterly goal.)

    So people make compromises. Maybe they drop full regression passes and replace them with incremental feature and integration testing. It’s not that they don’t care about quality. But in their quest to help the organization meet its single-minded goal of reducing the time from check-in to release, they opt for the easiest change that could get them there, indirectly prioritizing speed over quality in the process. And that happens because there aren’t checks in place to keep it from happening.

    Taking Control

    How do you put this into practice at your own organization? Start by choosing your goals and then selecting the control metrics. For many, it could be as simple as increasing speed; it’s a natural goal to chase, for the reasons already discussed. But it may be something different; only you and your teams can decide by being intentional in how you evaluate your production environment.

    Then it’s time to choose your performance metrics for each of your goals. You can do that yourself, but it may be more illuminating—and, honestly, more fun—to get your software development team involved. That could range from encouraging them to brainstorm the negative consequences of implementing that goal to straight-up asking them how they’d game the system.

    The following chart offers examples of control goals, their resultant unintended consequences, and the performance metrics necessary to keep them in check.

    Desired Output Control Goal Performance Goal Unintended Consequences
    Climb to 4500’ Increase power, nose up Airspeed, Altitude Stalling
    Reduce bounce rate Reduce site latency Revenue, Conversions, Customer Engagement Smaller pages, poor experience, feature attrition
    Generate more conversions Increase availability Releases, Backlog Ticket aging. Lower frequency of releases, cherry picked work items, no risk taking.
    Reduce MTTR Speed up ticket closure Re-open rate, new ticket rates. Premature closure, delay in opening tickets for issues.

    It’s important to note that how closely you monitor each of these performance metrics will vary, and in some cases significantly. Rather than attempt to apply a one-size-fits-all approach, instead think of each in terms of how long it takes to detect that the metric is falling out of its control envelope and how long it would take to recover if it did. If it takes one day to detect that you’re outside of your envelope and three weeks to recover, then by all means, check in daily. But if it takes three months to fall out of the control envelope and just a day to recover, you may only need to check it once every couple of weeks.

    A Soft Landing

    As we’ve supported software development teams in their efforts to modernize their software delivery methods, we’ve heard time and time again, “What’s the best metric for measuring success?” And we struggle to come up with an answer because there is no golden metric that works for everyone. But more important, even the good ones can lead well-meaning engineers and team leaders to optimize for one thing while letting others suffer.

    So rather than search for a magic bullet, the secret is to find goals that work for your needs—and then build in metrics that keep you and your software development team accountable.

    — Rob Duffy

  • Puppet Report Sees Long DevOps Journey Ahead

    Puppet Report Sees Long DevOps Journey Ahead

    A recent report published by Puppet suggests the level of DevOps maturity within most organizations is still relatively slight. In fact, most of the respondents reported high levels of manual work still occurring across configuration management, deployment, testing and change approval processes.

    Alanna Brown, director of product marketing for Puppet, said the “State of DevOps: Market Segmentation Report” makes it clear that DevOps is being embraced to solve specific pain points with specific IT departments. As a result, silos of DevOps processes are springing up across the enterprise. That next challenge IT organizations will face is trying to unify all the DevOps processes, she said.

    The survey finds deployment automation, version control, continuous integration and infrastructure automation were the most common starting points for DevOps. Less-common starting points were lean practices, visualization of key quality and productivity metrics and setting limits on work in progress.

    Brown said the one surprising thing that study found is there is little correlation between the size of the companies surveyed and their relative DevOps maturity. Reliance on DevOps process may have more to do with needs arising from satisfying customer demand than anything else, noted Brown. The survey finds that media and entertainment and retail industry have the lowest percentage of low IT performers, while financial services, insurance and manufacturing companies had the highest proportion of low performers.

    Not surprisingly, given the relative amount of DevOps immaturity, the survey also finds that reliance on IT automation frameworks is not yet especially widespread.

    The Markets Segmentation report is based on the 2017 “State of DevOps” survey of 3,200 IT professionals that Puppet previously published. While it’s possible many companies may have advanced further down the DevOps journey since then, the report makes it clear that for both technical and cultural reasons fully embracing DevOps is an extended process. In fact, Brown said the report shows DevOps is still mainly being driven by the bottom of the organization up rather than by senior IT leaders. It’s only when DevOps success becomes visibly demonstrated that organizations attempt to replicate that success elsewhere in the organization. At the same time, widespread usage of DevOps processes suggests that DevOps itself is now much more than a grassroots movement, she said.

    Change obviously comes hard to enterprise IT organizations. Many DevOps concepts were initially pioneered by web-scale companies that have the luxury of not having to support legacy applications and processes. Traditional enterprise IT organizations now typically are trying to support DevOps processes alongside process based on Waterfall and ITIL methodologies. Not every application being supported requires that number of release updates that many modern applications require.

    Nevertheless, it’s also clear that as the number of applications being built, tested, deployed and supported continues to grow, the average IT organization is increasingly short-handed. Finding IT professionals with DevOps skill sets is a major challenge. But as more companies come to realize they are really a software company that happens to be selling a specific thing, the higher priority DevOps becomes.

    — Mike Vizard