staging-devopsy.kinsta.cloud

Tag: devops

  • Same Old Same Old

    Same Old Same Old

  • Languages and DevOps: Network

    Languages and DevOps: Network

    It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

    *Finally – so far, at least

    And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

    One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

    Python and Shell

    Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

    Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

    But Wait, There’s More

    The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

    We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

    Carry On

    Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

  • GitLab Survey Surfaces Advances in DevOps Education

    GitLab Survey Surfaces Advances in DevOps Education

    As more organizations clamor for employees with some type of DevOps education, higher education is responding in kind, according to survey findings.

    A survey of 843 students and teachers at various academic institutions who have had some exposure to the GitLab continuous integration/continuous delivery (CI/CD) platform suggests the number of individuals with DevOps skills graduating from these programs soon might increase significantly.

    The survey, which was conducted by GitLab, identifies the top four use cases for the platform as learning (28%), teaching (22%), research (20%) and information technology/professional use (19%). Nearly a quarter (22%) also indicated they had a secondary use case on campus.

    Certification (57%) was ranked highest in terms of interest, followed by e-learning (49%) and virtual instructor led-training (35%). Students and graduate students are more interested in certification at 58% and 67%, respectively, while administration, faculty and staff were more interested in e-learning.

    The primary benefit of teaching and learning GitLab was identified as the ability to teach operations competencies (57%) and the ability to teach with an end-to-end tool for learning DevOps competencies (51%). For students specifically, the top benefit cited was the ability to teach operational competencies (49%), followed by the ability to build a portfolio and record of contributions (45%). Workforce readiness was cited at 40% and 46% of students and faculty, respectively.

    Dr. Christina Hupy, senior education program manager at GitLab, said the teaching of best DevOps practices within an academic environment is critical because it takes on average six years for IT professionals to master DevOps in the workplace. To help increase the overall pool for DevOps talent, GitLab has been making its software available for free via individual licenses to students and teachers. That program is now being extended to include a GitLab for Campuses offer, which makes the GitLab platform available to multiple users at a reduced price.

    In general, higher education programs have not been meeting the needs of organizations that are looking to hire IT professionals with proven DevOps skills, noted Hupy. Since launching the GitLab for Education Program in 2018, GitLab is trying to help fill that void, issuing more than $2 billion worth of GitLab software licenses in more than 75 countries. In 2020, the organization added 340,000 seats across 250 institutions to the program.

    More than a third of survey respondents (37%) reported they had access to a GitLab subscription at their institution and used it. The most common use case for GitLab cited was source control management (55%); followed by verification, also known as continuous integration, at 36%; planning, at 30%; and management and release, also known as continuous delivery, at 27% each.

    There is also significant use of GitHub among survey respondents, with 85% reporting using it. A distant second was Jenkins (21%), followed by BitBucket (17%), Travis CI (11%) and GitHub Actions (15%).

    IT organizations, of course, have a vested interest in helping educational institutions develop DevOps programs as the number of application development projects being launched simultaneously continues to increase. Otherwise, they will find themselves paying top dollar for DevOps talent that is difficult to find and retain. The challenge, of course, is identifying the institutions that have access to the DevOps tools and platforms that are going to be a pre-requisite for a successful DevOps career those students might eventually enjoy.

  • Why a Unified Enterprise DevOps Platform is Necessary

    Why a Unified Enterprise DevOps Platform is Necessary

    As a senior DevOps consultant working with large organizations over many years, I have been involved in more than 70 digital transformation projects, with hundreds of applications. While many things have changed over time, one thing has been a consistent source of problems that presents a formidable impedance to these transformations. The diverse number of DevOps platforms and tool variants used in those platforms results in a chaotic software delivery environment. From the point of view of any one application, almost any choice of DevOps platform and toolchain is fine, to an extent. But when you stand back and look at the larger picture, an enterprise with many variations of DevOps platforms and tools is at best chaotic; at worst, it is a gross impediment to overall organizational agility – which undermines the very purpose that DevOps is meant to serve.

    I relate to the quote “You don’t need another CI/CD automation tool. You have too many already.” The aggregate set of platforms and tools is like a Frankenstein’s monster with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.

    DevOps Platform Blockages

    Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. All three of these factors are impacted when an organization has too many variants of DevOps platforms.

    People factors – It starts with leadership. Business leaders want to leverage the values of continuous flow of software improvement made possible by DevOps. However, the flow is bottlenecked when the services of the organization must be delivered through a disparate combination of unconnected pipelines, each with separate processes to monitor, manage, troubleshoot and maintain.

    Process factors – Continuous delivery works because the DevOps platforms enable automation of processes to remove bottlenecks in flow. Process management and improvements are seriously slowed down when the details of automating the orchestration, execution and monitoring for software version management, integration, testing, security assurance and deployment processes are not standard between different DevOps platform variants.

    Technology factors – Often application development teams have their own favorite DevOps platform and a chosen set of tools. However, when application development teams in the same organization choose different DevOps platforms and tools, sharing knowledge, process data and practices becomes difficult. These incompatibilities slow down the overall evolution of continuous delivery for the organization.

    Requirements for a Unified DevOps Enterprise Platform

    Culture barriers, process problems, and DevOps platform “wars” are factors impacting the progress of digital transformations. A new unified enterprise DevOps platform would accelerate time-to-value and realize efficient, safe operation for digitally transforming enterprises and organizations. The following are general requirements for a unified enterprise DevOps platform.

    ● A new unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines is needed.
    ● Unified capabilities should include visibility, orchestration, integration, security, compliance, governance, traceability and management of flow for application value streams across multiple pipelines.
    ● Businesses need unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
    ● A new unified approach is necessary to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open-source software.

    What This Means

    Digital transformations are an imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A new unified enterprise DevOps platform is needed to resolve the technical problems of broken, leaky, “Frankenstein” toolchains and processes.

  • App Testing Must Evolve Within the DevOps Pipeline

    App Testing Must Evolve Within the DevOps Pipeline

    As the practice of DevOps evolves, so do the supporting tasks; hopefully in such a way that they introduce increased efficiency and automation to accelerate development and deployment pipelines. However, one specific process still remains a speed bump on the road to DevOps acceleration: the process—or, more specifically, the chore—of testing.

    Naturally, testing is an undeniably important component of quality assurance. However, introducing efficiency into a process that dictates quality assurance can accelerate development and improve outcomes, especially when it comes to application testing. 

    “Application testing should never be done in a vacuum, or, worse, a silo,” said Sara Faatz director, developer relations at Progress Software. “The DevOps process can benefit from accelerating the testing process, introducing automation and embracing teamwork.” 

    Faatz makes some valid points; historically, application testing was treated as either a standalone or separate process, and often was performed by non-programmers following some type of script. “We discovered early on that creating synergy between testers and developers was an important concept for accelerating development, while fostering teamwork,” said Ramiro Millan, director, product development, Test Studio. “Addressing the trifecta of acceleration, automation and teamwork challenges actually requires adopting a different mindset when it comes to testing, especially when it comes to automation and communication.”

    However, solving those problems requires adopting different procedures, as well as deploying tools to streamline processes and introduce automation. That said, there are ancillary challenges that also have to be addressed. For example, there is often a disconnect between the cultures of QA teams and development teams. Here, QA teams need to overhaul their processes and introduce more agile practices. In other words, the time is now to identify new practices and methods that allow QA teams to be creative and innovative while helping to test the software created by DevOps.

    “Automation is becoming hyper-critical for testing. However, it is not just automation alone, but also the ability to run tests in the background and not hijack control of the console or the machine,” Millan said. “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.”  

    That makes a great deal of sense. In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.

    “Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times,” Faatz said. “The ultimate goal here is to bring forth faster delivery, less maintenance and more stability. I think stability is a big part of the equation. If we can automate those day-to-day, repetitive tasks, we garner that additional stability.”

    Although testing is a broad subject, many of the lessons offered can have a beneficial impact on the overall process. Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on. This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process.

    “The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation,” Millan said. “Automation brings about consistency, and consistency brings forth improved results.”

    The lessons learned indicate that testing must evolve to keep up with the DevOps model, and also suggest that DevOps is pushing QA teams to adopt new methods of testing and interaction. The only remaining question is how quickly QA can better integrate into DevOps, and eliminate the deployment speed bumps.  

  • Measuring the Value of DevOps-as-a-Service (DaaS)

    Measuring the Value of DevOps-as-a-Service (DaaS)

    The late great W. Edwards Deming, statistician, professor, author, lecturer, and consultant said, “In God we trust. All others must bring data.” The point is, if you want people to trust your information, then you need to present measured data. This is true for countless circumstances. As a DevOps consultant, I am often asked by my clients what data should be used to show the value of their DevOps capabilities, in a way that is acceptable to the stakeholders of those DevOps capabilities. A lot of excellent research results, published by DORA and others, describes metrics that demonstrate the value that DevOps provides to application development. More and more enterprises are embracing the idea of providing DevOps capabilities, such as pipelines, tools, hardened containers and tech stacks, as a centralized service to support their many application teams. The question then becomes, “What metrics should be used to show the value of DevOps-as-a-Service (DaaS)?”

    Before measuring the value of anything, you need to know two things: “What is it?” and “Why is it important?”

    What is DevOps-as-a-Service?

    In high-level terms, DaaS is DevOps capabilities made available to the users of those capabilities through portals and APIs. There is no standard set of services; DevOps capabilities offered vary from organization to organization. In my SlideShare, DevOps-as-a-Service (DaaS) Values, I illustrate a generic blueprint for DaaS.

    The DaaS blueprint has four layers, as follows:

    • Stakeholders – There are three types of stakeholders: business, app-dev users and DaaS teams.
    • Service access layer – This layer consists of user portals, APIs, and access security.
    • Service layer – The service layer consists of user services and management services. User services include things such as repositories, CI/CD pipelines, sandboxes, test data, configuration data, guides and training. Management services include service catalogs, issues and change requests, SLOs, SLIs, governance policies, experience monitoring and automated tasks.
    • Resources layer – This layer includes application stacks, infrastructure resources, tools, infrastructure code and topology data.

    Why is DaaS Important?

    The value of DaaS, as perceived by different stakeholders, can be summarized as follows:

    • Business – DaaS makes the business competitive.
    • App-dev Users – DaaS improves application development.
    • DaaS team(s) – DaaS improves management of DevOps capabilities.

    What Service Level Objectives (SLOs) Demonstrate the Value of DaaS?

    The SLOs need to be chosen to best fit the requirements of each application. The following are examples.

    Business value can be demonstrated by:
    ROI based on tracking cost savings relative to a benchmark comparing prior non-DaaS, trend cost per developer and per release.
    SLO agility of services – Lead time for changes, and frequency of releases.
    SLO reliability of services – change failure rate, time to restore services.
    SLO governance, compliance and security scores.

    App-dev user value can be demonstrated by:
    SLO availability of DaaS, service level indicators (SLIs) depend on service components and architecture.
    SLO service response time.
    SLO experience scores.
    SLO change request response time.

    DaaS team value can be demonstrated by:
    SLO scope of applications – number of apps supported, number of users per month.
    SLO number of requests served per month.
    SLO critical events per month.

    How Does an Organization Develop DaaS Metrics?

    Start by picking an application that is supported by DaaS. Do not try to boil the ocean and measure all applications at once. Then, appoint a DaaS SLO/SLI team to work on metrics development for the application. The team should include stakeholders from business, app-dev and DaaS support teams associated with the application.

    DaaS SLO/SLI team members determine the SLOs of DaaS that each class of stakeholder values the most, and then decomposes the services to identify sources of data that will form the most important service level indicators (SLIs).

    With the SLIs in hand, instrumentation, telemetry and analysis requirements can be determined and used to design monitoring agents, communication, analyzers, alerts and dashboards.

    Then, roles, policies, playbooks and responsibilities will complete the solution. Test the solution for the chosen application. As you gain confidence in the solution, adapt and expand the solution for use with other applications.

    Continue to monitor the progress and performance of the SLO metrics, and continuously improve them with experience and as newer technologies become available.

    What This Means

    DevOps-as-a-Service provides many valuable capabilities to business, app-dev users and DaaS teams. Metrics that demonstrate value to each class of stakeholder should be determined for each application that consumes the capabilities offered by each unique DaaS. A DaaS SLO/SLI team can determine the best metrics and system design for the implementation for an example application. The SLOs can be adapted and evolved for other applications in the organization, and used as a basis for continuous improvement.

  • The Importance of Incorporating DesignOps Into DevOps

    The Importance of Incorporating DesignOps Into DevOps

    Design is a critical software project element that often goes unnoticed by those writing code. After all, coders and implementers tend to take the design process for granted and leave the look and feel of applications to the designers. In the days of waterfall based development, design was one of the first steps in the development sequence of creating a new application. However, with Agile and DevOps development practices, design became disconnected from the overall process.

    “If you look at the full spectrum of AppDev, it becomes obvious that there are many elements that should be part of DevOps. Take, for example, cyber – today, there is a movement to integrate cyber into the DevOps pipeline, which the industry has started to call DevSecOps,” said Mark Troester, VP of strategy at Progress, a software company offering tools for developers and IT. “To make design a part of the iterative process of DevOps, teams need to think about including designers during the complete development process, something along the lines of how cyber has become part of the iterative process. In other words, teams should be embracing the concept of DesignOps,” Troester said.

    To understand the challenges this creates for those looking to include design as part of the DevOps process, one only needs to look at how design, specifically user experience/customer experience (UX/CX) design, was done in the past. Designers would use tools such as InVision Studio, Axure, Proto.IO, Adobe XD, or one of the many other tools available, to prototype the look and feel of an application, or, more specifically, the end-user experience. The term DesignOps was coined to encapsulate the processes around design. However, DesignOps solely focused on the process of design, such as design workflows, design tools, design governance, team management, budgets and so on. 

    The ultimate goal of DesignOps was design creation; that design was then passed on to those who would write the code and develop the logic to bring that design to fruition in the form of an application. DesignOps worked rather well when an organization was adhering to waterfall development methodologies, where each step was clearly defined and the goal was to deliver a complete, finalized application to those requesting it.

    “Larger organizations were able to field large design teams and could afford to implement a complete design system. When you have 50 or more designers, a complete design system becomes critical to manage design,” said Troester. “However, as AppDev has evolved into a more agile process, especially under DevOps, the disconnect between design and development became a significant problem.”

    What Troester is alluding to is the reiterative development cycle used by DevOps teams, where applications are delivered in pieces and then further modified based on user feedback or business operational changes. Businesses today are embracing agile concepts, so they can react much faster to changing market conditions. This, in turn, means modifying applications as quickly as possible to maintain a competitive advantage. Currently, design remains somewhat siloed, and can become a bottleneck for implementing changes if the UX/CX must be modified to address those needed changes. 

    “With the rise of DevOps, teams need to start thinking of reiterative processes, where DesignOps integrates with the DevOps team, so there is collaboration between the designers and the developers, allowing design changes to happen quickly,” Troester said. “Yet, there are still remaining challenges – some created by the COVID-19 crisis – where designers and developers may not even be in the same building, much less the same time zone,” he said.

    To Troester’s point, the COVID-19 crisis has forced businesses to evolve in ways that were once thought impossible. Developers, designers and even operations teams and individuals may no longer be sharing office space, and might be distributed across multiple locations. That complication will drive the need for better collaboration tools that bring design into the DevOps cycle.

    “DevOps teams, as well as DesignOps teams, should be looking into technologies that can bridge the designer/developer divide. It will be critical in the near future to facilitate collaboration between design and development,” Troester said. “Perhaps, the answer lies with building some type of bi-directional API into design systems, which can play a key role in the implementation and support of design-first experiences,” he added.

    Existing solutions to the current divide seem to be few and far between. But, that does not mean DesignOps and DevOps teams should not be currently looking for a solution to what will become a major problem as DevOps accelerates in the enterprise.                  

  • 5 Steps to Successful DevOps Culture

    5 Steps to Successful DevOps Culture

    The late business management guru Peter Drucker coined the phrase, “Culture eats strategy for breakfast,” and the phrase has endured through the years. Your people must be passionate and enthusiastic about executing business strategy, or it – and your business – is doomed to fail. But remember that company culture itself needs a strategy to complement the business.

    DevOps, too, will not succeed without the right culture. As I said in my book “Engineering DevOps,” “Culture is a door to Engineering DevOps,” because if leaders and people do not work in accordance with DevOps principles, then no tool or engineering process will be sufficient to succeed with DevOps. In my (and others’) experience, culture challenges are the No. 1 obstacle that many organizations need to overcome to succeed with DevOps. But changing culture is not easy. Values, beliefs, behaviors and work habits are deeply ingrained in organizations. Organizational inertia and deep-rooted habits are much harder to change than tools or process changes. Transforming organizational culture for success with DevOps requires a strategy, goals and sustained commitment.

    In her article, “5 Steps to Change Your Company Culture,” Kate Heinz prescribes five practical steps for cultural change which also are highly applicable to DevOps culture transformation.

    Step 1: Determine Core Values

    Start by clarifying the values that are most important to accomplishing the long-term strategic goals of the organization. With DevOps, typical strategic core values could be responsiveness to customer needs, speed of innovation, technology leadership and software products and services resiliency, for example. Collaborate with all the key stakeholders including executives, long-term employees, sales teams, key suppliers and HR to obtain alignment on core values before executing the next steps.

    Step 2: Set Your Culture Goals

    In his article, “7 Key Principles for a Successful DevOps Culture,” Kaya Ismail identified seven principles that can form a framework for determining your DevOps culture goals.

    1. Foster a Collaborative Environment – Break down silos to bring people, processes and tools towards a unified focus on the customer.
    2. End-to-End Responsibility – All people in the value stream need to be fully accountable for the application and outcomes from beginning to end.
    3. Encourage Continuous Improvement – Optimize value streams using integration toolchains and automated processes to realize quick lead times and fast customer feedback to continuously improve performance.
    4. Automate Almost Everything – Automated CI/CD processes, infrastructure provisioning, testing, deployment and security compliance require a skilled workforce.
    5. Focus on Customer Needs – DevOps teams must continuously pay close attention to ever-changing consumer demands and be ready to respond quickly.
    6. Embrace Failure and Learn – A “climate for learning” in which failures are viewed as opportunities to learn makes people feel safe and empowered to transform their work.
    7. Unite Teams and Expertise – The scope and complexity of DevOps requires team members to share knowledge and cross-train so they are well-rounded and have a balanced set of skills.

    Step 3: Assess Your Existing Culture

    Conduct interviews and surveys with employees and key stakeholders to determine where there are deviances from the culture goals set in Step 2. Communicate an analysis of the assessment findings to all stakeholders, pointing out important gaps, areas for improvement and the general plan to close the gaps.

    Step 4: Map Out the Plan

    Develop a roadmap to address the gaps identified in Step 3. Include specific tasks, timelines, benchmarks and responsibilities. Tasks and items may include targeted workshops, training, selective new hires, organizational changes and, most importantly, rewards and consequences – the real drivers of behavior and culture. One caution about training: as Thane Bellomo explained in his article, “Training Doesn’t Change Culture,” training alone does not have the power to fundamentally change culture.

    Step 5: Evaluate Your Progress

    Communication, surveys and interviews are important so individuals can provide feedback and track progress. Use the feedback you receive to verify that culture goals are being improved upon, and to reinforce to everyone that the culture changes are important. Use DevOps metrics such as lead time, release frequency and time-to-restore service to demonstrate that the culture changes are helping the organization achieve the strategic values set in Step 1. As you monitor progress, be mindful of pitfalls. As Larry Senn explained, “The Top 4 Reasons Culture Change Initiatives Fail” are: lack of consistent leadership from top management, inadequate personal involvement, disconnected initiatives and lack of top-to-bottom momentum. Be prepared to make corrections based on the evaluations to ensure your culture transformation stays true to your DevOps strategic values and culture goals.

    What This All Means

    Success with DevOps requires the right kind of culture. Changing culture is no small feat, but it can be done if approached strategically. The five steps described in this article provide a framework for organizational culture change that supports DevOps.

  • DevOps Myths Debunked

    DevOps Myths Debunked

    Leaders need not be DevOps experts, but they need to distinguish DevOps myths and realities to lead their digital transformation projects.

    As I indicated in a recent article, Engineering Practices Can Overcome DevOps Challenges, leaders need to set an inspiring DevOps directional vision for the organization, and proactively stimulate and sponsor team activities toward goals. To be credible, communication from leaders need to distinguish between myth and reality. It is easy for leaders to get confused, because there are many popular myths surrounding DevOps. It’s important to remember that, in DevOps, definitions and engineering best practices for DevOps have not entirely been nailed down.

    As Doug Miller, senior director strategic partnerships, Perforce Software, said “Working in an industry that has yet to settle on an accepted ‘definition’ for DevOps makes each day a challenge. The ever-morphing landscape makes it difficult for technology vendors and consumers alike to ensure we’re all talking about the same thing in the same way.”

    Here are some of the most important myths that leaders need to be aware of.

    Debunking DevOps Myths

    Myth: “DevOps is a cultural movement.”

    The truth is that implementing DevOps requires a careful and balanced engineering approach that considers a wide array of people, process and technology aspects. In my article, The Time Has Come for an Engineering Approach to DevOps, I explained that while culture is a critical success factor, DevOps is much more than just culture. Furthermore, DevOps is not just a movement. In the larger context of software engineering history, the word “DevOps” is new, and perhaps it will be replaced by another word someday, but the underlying engineering principles and practices that constitute DevOps could apply to almost any engineering project throughout the ages.

    Myth: “DevOps requires continuous deployments.”

    The truth is that DevOps enables continuous delivery of release artifacts to a staging environment to be ready to deploy safely, but frequent deployments to production is not always a goal. There are valid customer use cases that do not desire frequent deployments to production. For example, customers may not want to receive a new version of a software platform product frequently, because each new version may be disruptive and risky for reasons beyond the scope of the product itself. The engineering benefits of delivering complete releases to staging without deployment to production are still considerable. Each release is produced and validated in a pre-production environment, and made ready for deployment on demand without disrupting customers that do not want to take a new release.

    Myth: “DevOps applies to any software product, service or application.”

    The truth is that DevOps engineering yields high ROI in many circumstances, but some cases do not warrant investment in the people, process, and technology changes needed for DevOps. For example, applications that rarely change do not warrant the cost of DevOps changes. Organizations that are heavily siloed will find it too frustrating and counterproductive to implement DevOps. The application of DevOps to some commercial off-the-shelf (COTS) products may not yield sufficient ROI, because business-to-business barriers may behave as impenetrable organizational silos. Applications that have few tools in their toolchains suitable for DevOps may find the transition to DevOps too expensive.

    Myth: “DevOps requires Agile.”

    The truth is that DevOps and Agile can be either complementary or competitive. The notions of working with small, incremental changes is common to both Agile and DevOps. However, organizations that embrace Agile are focused on optimization of the development end of the pipeline, and may struggle with DevOps, which emphasizes engineering of end-to-end process optimizations.

    Myth: “The scope of DevOps is the same as CI/CD.”

    The truth is that a well-engineered DevOps implementation encompasses continuous integration/continuous delivery (CI/CD), but also extend beyond integration and delivery into other practice areas such as planning, operations, governance, disaster recovery and other practices that must work together with CI/CD to accomplish business goals.

    Myth: “DevOps does not apply to platform products such as software code embedded in manufactured products.”

    The truth is that DevOps does apply to embedded code products, as well as web services, business applications and other types of products. It even applies to development of software and services for DevOps itself! In the case of platform products, typically, deployments are planned. They are not continuous, but, instead, continuous deliveries of candidate releases are delivered to a staging environment to make sure the changes implemented for the platform are fully developed and verified as the platform is built, instead of waiting for a big-bang release.

    Myth: “DevOps is an elimination of IT operations.”

    Jeremy Bosch, in his article, Top 9 Debunked DevOps Myths, “As per the NoOps concept, the IT sector will become so automated that it will not require any in-house team to manage the software. However, no matter how automated the services may become, there will always be a need for operations. Although there may be changes in operations, they will still hold significance in DevOps.”

    There are many persistent myths about DevOps, such as the examples in this article, that can confuse and misdirect uninformed leaders. Leaders that learn to distinguish between DevOps myths and realities are better able to communicate realistic goals to lead their digital transformation projects.

  • Value Stream Management Consortium Makes Debut

    Value Stream Management Consortium Makes Debut

    A consortium dedicated to advancing the adoption of value stream management best practices is being launched today with backing from Digital.ai, HCL Software, Plutora, ServiceNow and Tasktop.

    The Value Stream Management Consortium (VSMC) will create an open community around which organizations that are seeking to expand DevOps workflows and processes across functions and organizations can more easily collaborate.

    VSMC chair Helen Beal said that while value stream management has been around as a concept for years, the number of organizations that have fully embraced the concept remains relatively small. The VSMC is dedicated to enabling organizations to orchestrate software development processes more flexibly, she said.

    VSMC Chair Helen Beal

    That goal has proven elusive, because it requires a level of collaboration between release managers, DevOps managers and product managers as well as IT and business leaders. Value stream management provides a framework for enabling organizations to embrace value stream management concepts as they become more adept at employing DevOps workflows to manage multiple application development initiatives simultaneously.

    Initially, Beal said, the VSMC will function as a central hub of information and education pertaining to value stream management. Ongoing research will track how organizations measure value. Eventually, the VSMC will provide certified training, Beal added.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business is growing steadily as organizations realize how dependent on software they have become.

    As organizations come to terms with this new reality, many also realize there is a much greater need to align software development with their core business processes. Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    Business leaders are especially anxious to understand how any software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of DevOps sophistication, but as software continues to eat the world it’s only a matter of time before value stream management becomes the table stakes organizations will need to survive and, hopefully, thrive.