devopsy.kinsta.cloud

Tag: devops adoption

  • Survey Sees Need for More Consistent Approaches to DevOps

    Survey Sees Need for More Consistent Approaches to DevOps

    DevOps is arguably one of the most disruptive forces driving transformation of IT processes in recent memory. But a new survey finds that while IT organizations are making progress, adoption of DevOps processes remains uneven at best.

    A survey of 2,419 IT professionals conducted by OverOps, a provider of code analysis tools, finds that 82 percent of organizations have partially adopted DevOps practices, while only 17 percent of respondents claim to have fully adopted DevOps. Obviously, not every workload requires an organization to embrace DevOps processes to manage it.

    But OverOps CTO Tal Weiss said the survey shows that as organizations increase the rate at which application workloads are being deployed, a fair amount of chaos is starting to reign. According to the results, more than 90 percent of companies deploy code at least once a month, and more than 60 percent release code at least once every two weeks. Nearly 40 percent, however, indicate that moving too quickly is a primary reason errors make it into production.

    Worse yet, more than 50 percent say they rely on customers to tell them about errors in production, even though 60 percent of respondents say they use automated tooling for error notification and to ensure application quality.

    Not surprisingly, IT teams are still spending an inordinate amount of time troubleshooting their environments. More than a quarter of respondents say they still spend at least roughly one full workday per week troubleshooting errors. Another 42 percent of respondents spend 10 percent to 20 percent of their time troubleshooting.

    The good news is that IT is increasingly being viewed as a team sport. A full 67 percent of respondents believe their entire team is to blame when an application breaks or has an error, and 73 percent said both developers and operations are equally accountable for ensuring the overall quality of an application.

    Weiss said more organizations need to implement a more structured approach to DevOps based around the same continuous integration/continuous deployment (CI/CD) platform. Too many organizations today are adopting DevOps processes from the bottom up when it’s become clear that top-down initiatives for driving consistent adoption of best DevOps practices are now required. One of the biggest challenges facing IT leaders, however, is identifying and implementing the metrics that will be employed to identify those best practices, he said.

    Change, of course, comes hard to any IT organization. It may take IT organizations years after acquiring new tools to define their processes. Inertia surrounding existing waterfall and ITIL-based processes can be incredibly high. But as the amount of software that needs to be deployed and updated continues to increase, risk levels associated with deploying applications also are starting to increase. Many organizations are now essentially experimenting on their end customers. How much tolerance customers have for trial-and-error approaches to applications development and deployment remains to be seen. In the meantime, IT organizations would be well-advised to resolve to do DevOps better in 2019.

    — Mike Vizard

  • CloudBees: 2019 to Be Year of DevOps Metrics

    CloudBees: 2019 to Be Year of DevOps Metrics

    While DevOps has come a long way in terms of understanding and adoption, 2019 is going to be marked by a concerted effort to applying metrics to DevOps processes. Applying those metrics will not only substantiate the value of adopting DevOps, they also will provide the impetus many organizations need to close a variety of DevOps gaps that have emerged in recent years.

    For example, a recent survey of 1,076 IT professionals conducted by CloudBees, provider of the open source Jenkins continuous integration/continuous development platform, suggests that while a lot of advances have been made in terms of developers embracing continuous integration, there remains a lot of work to be done before organizations fully embrace continuous development. The survey finds 67 percent of respondents say they are practicing DevOps, but only 50 percent have implemented continuous deployment.

    Brian Dawson, DevOps evangelist for CloudBees, said one of the major reasons that gap exists is that getting developers to embrace continuous integration is an easier challenge than getting disparate developer and IT operations teams to jointly embrace continuous development.

    Closing that gap will require more organizations to measure precisely the benefits they are achieving by making the transition to DevOps, sometimes referred to as value stream management, said Dawson. Once those metrics are collected, he said, it should become easier to drive DevOps processes deeper into most organizations.

    The challenge, however, is that most organizations are not especially disciplined when it comes to monitoring metrics. In fact, according to the CloudBees survey, 34 percent of respondents admit they don’t gather any metrics from their DevOps pipelines.

    In the meantime, Dawson noted the rise of containers and Kubernetes soon may force more widespread adoption of DevOps, as microservices based on containers are frequently updated. Kubernetes may soon provide a common set of definitions from which developers and IT operations teams can create a unified set of processes. A full 79 percent of respondents report they are using Docker and 47 percent employ Kubernetes. Additionally, 38 percent of survey respondents are using containers in both development and test activities, compared to 33 percent using containers from development all the way through to production. CloudBees is trying to drive adoption of Jenkins X, a CI/CD platform that is based on a microservices architecture enabled by containers and Kubernetes.

    Of course, the DevOps gap is hardly limited to definitions. The CloudBees survey also exposes communications gaps that need to be bridged in 2019. For instance, according to the survey, C-level executives and developers have a generally lower opinion than IT operations teams and senior managers concerning the degrees to which DevOps practices are being adopted.

    Dawson said greater focus on DevOps metrics will go a long way to closing DevOps gaps that are becoming more apparent with each passing day. DevOps is relatively easy to subscribe to as a philosophy. It’s only when organizations begin to implement CI/CD systems in a way that can be measured objectively does the commitment to that philosophy get tested.

    — Mike Vizard

  • DevOps Transition: The Cultural Commitments and Challenges

    DevOps Transition: The Cultural Commitments and Challenges

    Enterprises can achieve certain levels of success by filling a need in the market, hiring skilled teams and utilizing cutting-edge tools and technologies. However, to set themselves apart and chart a course for long-term success, they need to address the values, beliefs and behaviors that make up organizational culture as carefully as they address business decisions. It’s culture that ultimately informs the decisions made about how a company evolves its concepts from idea to value, so when you want to make a change and grow, that’s where you need to start.

    One area where culture is particularly important is the introduction of new practices and processes applied to software engineering and the role that a DevOps strategy plays within organizations. DevOps encourages a mindset of communication, collaboration, integration and automation among software developers and IT operations, so it’s more than just a new set of tools; it’s a cultural shift. This change doesn’t happen immediately or automatically, it requires deliberate steps and actions to be taken, and calculated decisions to be made.

    The shift also requires commitment. A recent Gartner report, “New Insights into Success with Agile in Digital Transformation,” found that organizations must be prepared for a commitment of three or more years to ensure success when moving to a more agile development process. Teams with less than a year of experience with a new development process show a success rate of 34 percent, while that rate jumps to 64 percent with between one and three years of experience. After three years of agile experience, the success rate skyrockets to 81 percent.

    New Technologies Accelerate Momentum, not Create It

    Implicit in the decision to move to DevOps is the desire to develop faster. To do that, organizations often begin the process by saying to themselves, “We need to automate things.” They buy a variety of testing automation tools, production delivery tools and anything they think will make them more agile. However, if they don’t take steps to prepare the people in the organization, things can get worse, not better, because the new elements can create isolated teams centered around “campfires” where separate teams use the various new automation tools individually.

    When teams are undergoing transformation, we often see them go through a roller coaster of up-and-down results. This was illustrated in the DORA report, “Accelerate: State of DevOps 2018: Strategies for a New Economy.” When the transformation begins, teams quickly identify wins and automation helps lower performers improve, creating an uptick in overall performance. However, as the process moves along, automation increases test requirements, which are still dealt with manually, and a pile of technical debt blocks progress. At the same time, the mounting technical debt and increased complexities cause additional manual controls and layers of process around changes that, more often than not, slows work. Teams generally don’t see an upswing in results until putting in relentless efforts toward improvement, leveraging expertise and learning from their environments, which finally results in a jump in productivity.

    This is a moment when organizations need to lead with their brains, not their pocketbooks, and stay committed to the process. To minimize the risk of failure, they must address the people and the process with the same rigor and commitment they address the technology. In fact, evolving the culture and process associated with how people work is the biggest challenge in adopting DevOps. People resist change and no amount of technology makes change easier.

    Any initiative that begins with just buying software or technology to make the organization agile is a mistake. The best way for a business of any size to launch a DevOps initiative is to get people comfortable with the vernacular and the process before changing anything. I’ve seen organizations go so far as to change the name of existing processes just to get teams thinking differently before the real change is made.

    Putting in Tools Before a Plan is Like the Cart Before the Horse

    After seeding the terminology and idea of change, the next step has to be tactically thinking through how the organization will evolve. It’s often thought that tools will make an immediate impact, but not enough planning is done to integrate the tools before being taken out of the box. Basically, they end up like a bunch of kindergartners at recess: Everyone has their own toy to play with but they do it alone and no one works together.

    Before putting in new tools and changing processes, there needs to be understanding around where the gaps and inefficiencies are so KPIs and metrics can be mapped back to tell where progress is being made. You can’t manage what you can’t see, so you have to develop visibility into the process to understand where those inefficiencies currently are. When that is achieved, remaining constantly vigilant to understand the constraints that exist while establishing new processes and using the new DevOps tools will allow you to continuously improve.

    It needs to be known that the reward is worth the risk. Making the move to DevOps can’t be thought of as a decision or a choice, it’s an imperative for organizations that want to remain competitive. Every organization needs to become a software company and to do that they need to move to DevOps and make continuous improvement part of their DNA. Organizations can’t fear the move, they just need to be diligent with the transition, monitoring and follow up when adopting DevOps.

    — Bob Davis

  • Steps on the Journey to DevOps

    Steps on the Journey to DevOps

    There was a time when people thought DevOps was a simple movement that didn’t need to be defined. I have always been told that big leaps won’t get you to your destination immediately, but little steps will get you there one day. For DevOps, the day has come, gaining mindshare among organizations and given importance like never before. However, certain companies are unable to understand what’s going on in their respective industries or how one they make their digital operations more productive.

    The Evolution of DevOps

    In 2007, Patrick Debois, a Belgian engineer, saw a growing friction between developer and operation teams. As a developer, he understood really well that development and operations can never go hand in hand, but he saw a golden opportunity to make the most of agile methodologies to manage infrastructure management processes in the similar way developers do. Initially being described as agile infrastructure, the concept was later coined as DevOps—a portmanteau of development and operations.

    A year later, in 2008, O’Reilly Media ran the very first Velocity conference, founded on the same insight: software developers and web operators never being on the same page even after sharing the same goals and language. The effort was meant to gather the tribe into one room, to talk with each other and share insights. It is said that much of the DevOps movement grew out of the Velocity conference.

    With the internet growing rapidly and sites such as Amazon, Google, Flickr, Facebook and YouTube becoming monstrous entities, those in IT witnessed seeing websites grow from one server to a dozen and even thousands. As a result, the business consequences of downtime, or of poor performance, skyrocketed.

    The need for DevOps grew with the growth of websites. And to blur the boundaries between development and operations, DevOps came into existence. Today DevOps became more than an idea. But unfortunately, the shift hasn’t been easy for everyone. DevOps has been focused too heavily on development and operations hasn’t enjoyed an equal share of improvements.

    5 Stages of DevOps Evolution

    Normalize the technology stack: The process starts from here. Several teams have started adopting true agile methods and are implementing proper version control as they seek to provide continuous integration and delivery. In fact, this is when redundant technologies are eliminated and the stack is normalized, which means practitioners must build on a standard set of technologies and place application configurations in version control.

    Standardize and reduce variability: As noted, development and operations teams are working toward one goal. This means teams must work to make sure their technology is further consolidated to a single OS or OS family, process complexity is reduced and early collaboration opportunities are explored. This is also when system configurations should be placed in version control and applications should be rearchitected to fit business needs.

    Expand DevOps practices: At this point, all the foundational pieces should be in place. This phase is a cleanup phase for discrepancies created by previous changes. For instance, the output of the application development team must match that of the delivery for true effectiveness. At this point, individual contributors can do work without approval from outside the team and changes can be made without as much wait time.

    Automate infrastructure delivery: At this stage, a company can help lessen the discrepancies between development output and operations delivery times. As a result, everyone gets closer to being one on the same page. And things such as security configurations, system configurations and provisioning are automated, which means the DevOps team can deliver faster and is better set up for future self-service.

    Provide self-service capabilities: DevOps deployments are created here. Developers can deploy testing environments on their own, and success metrics are clearly visible to the entire team.

    Helpful Resources:

    — Jaymin Vyas

  • There is No Magic Recipe to Adopting DevOps

    There is No Magic Recipe to Adopting DevOps

    Over the past five years, we have seen more and more organizations of every size trying to adopt DevOps practices. However, we’re still expecting adoption rates to continue to rise—we have not yet reached “peak DevOps.” The motivations behind this comes from the need to reduce time to market, deliver better quality software, reduce operational costs and, ultimately, improve productivity and stay competitive.

    More enterprises are changing their business models by digitizing their business processes. We’re also seeing increased adoption of cloud technologies, agile frameworks and disruptive technologies. But these factors will not lead to an accelerated software development life cycle if organizations don’t prioritize better collaboration between people (no matter what area they belong to).

    Successfully implementing DevOps practices is not easy. Depending on the company’s size, it can take several months or even years. Most of these enterprises are learning what it takes to transform their organization. From our experience it takes several elements, but most importantly, engaged leadership is one of the most essential aspects for successful DevOps transformations. This leadership support will help organizations create dynamic and flexible business processes that eliminate traditional silos. This means that multiple teams can work together in a collaborative way, making seamless workflows that accelerate the software development life cycle and improve ongoing product maintenance. Such workflows bring tangible benefits, such as being able to rapidly respond to changing customer demands and developing better quality software, faster.

    Implementing DevOps is Unique to Every Company

    However, when talking about what it takes to adopt DevOps, we have to understand that there is no magic recipe that works for all. Every company has its own unique history, culture, and way of working, and thus will implement it differently. This is particularly the case because DevOps is really an amalgamation of different factors, from technology and automation to creating lean work processes and creating a culture of sharing between teams and individuals that traditionally were siloed.

    In 2019, Organizations Will Look to Scaling Initial Initiatives

    Very similar to what we have seen with the adoption of Agile development, most organizations have experimented with DevOps or have launched a small-scale pilot. They are aware of DevOps and the benefits it can bring. The challenge going into 2019, for the vast majority of businesses, is how to scale these pilots enterprise-wide. For example, in its 2017 survey, Forrester Research found that while just 13 percent of organizations had fully implemented DevOps, 50 percent had started their implementation and were expanding their use.

    We’re very much still on the journey to implementing DevOps practices. For example, many of the organizations that we work with are now using automation tools to get closer to continuous integration and continuous delivery capabilities, but there is still potential to use automation to a greater extent.

    There also exists a split in the types of applications that organizations are currently using DevOps for. Again, an interesting study by Forrester Research showed that in 2017, while 68 percent of organizations stated they were already using such practices for building and deploying mobile applications, this percentage dropped to 56 percent for ecommerce websites. I also believe that organizations need to improve how they measure DevOps success: Can they create metrics, such as level of level of innovation, or tie success directly to product revenue or process efficiency?

    As we look forward to 2019, more than ever business leaders will find value in looking at the best practices that companies have already developed on their DevOps journey. But we can’t forget that while two organizations may use the same automation tool, they will have very different cultures and way of working, with different goals and objectives. That’s why DevOps takes so long to implement, and represents a fundamental shift in how most organizations create, deliver and maintain software.

    — Gabriel Vasquez

  • Embracing DevOps into Your Company

    Embracing DevOps into Your Company

    Some companies are embarking on a new adventure in DevOps. As organizations start to consider the possibilities of implementing DevOps, they need to think about what problems it solves and what role it will play in their organization.

    Company Culture and DevOps

    DevOps is both a cultural and technological shift in the enterprise, offering a seamless path from idea to production. Because it involves development, operations, IT and the rest of the business, many organizations have seen the collapsing of their organizational silos.

    Company culture and values are central to DevOps adoption, with leadership encouraging more collaboration. As roles and responsibilities shift, worries over how these changes may impact jobs could result in some internal friction from employees. Throughout this process, communicating ongoing and upcoming changes is critical to keeping employees motivated. Thus, DevOps adoption will be easier if an organization with an open communication style and a philosophy of experimentation with new technologies.

    Security in DevOps

    Security benefits DevOps by reducing the possibility of risks early on, bringing greater agility to the development process. Given the average cost of a security breach—ranging between $2.2 to 6.9 million so far in 2018—and its impact on customers and brand reputation, having a DevSecOps strategy is critical.

    DevOps approaches emphasize the importance of security with speed. While traditional models made time for manual testing, there is no such time available in DevOps, where continuous deployment is the norm. Teams must integrate testing and resolution of security issues earlier (shifting left) in the development process to prevent bigger issues down the road.

    Tips for Best Cloud Platforms and Orchestration Tools

    Organizations will achieve the best results when they use the cloud and orchestration platforms that best serve their technology requirements. All of the major cloud platforms offer the basics, including compute and storage, as well as more niche and cloud-native solutions. Once you’ve chosen a platform, you’ll want to test and evaluate tooling and workflows.

    Here are some DevOps tools that you might consider:

    Version Control Continuous Integration Infrastructure as Code Continuous Testing Continuous Delivery Configuration Management
    GitHub

    GitLab

    Bitbucket

    		 Jenkins

    Bamboo

    TeamCity

    CircleCI

    Shippable

    Concourse CI

    		 Terraform

    AWS CloudFormation

    		 Selenium

    Cucumber

    Jasmine

    Karma

    Gauntlt

    Serverspec

    		 Spinnaker

    Octopus Deploy

    		 Chef

    Puppet

    Ansible

    SaltStack

     

    You’ll want to cherry pick the right set of tools and then create a cohesive and productive DevOps automation workflow that ultimately increases both the robustness and velocity of your releases. For example, in the following DevOps automation workflow we have chosen GitHub for version control, Bamboo for continuous integration and continuous deployment (CI/CD), Terraform for infrastructure as code, and Chef for configuration management:

    Recommendations for Getting Started

    We have five recommendations for getting started with DevOps in your organization:

    1. Start with a Process: The only way to understand whether a DevOps process is successful is by getting started. Make good use of the opportunity by engaging teams to work together to build innovation. Be prepared to experiment and fail. Eventually the right process will evolve.
    2. Define the Metrics. For transformation to work, you need to understand the key metrics that matter. Use these metrics as a starting point:
      1. Mean Time to Production: The length of time it takes for newly committed source code to get into production.
      2. Deployment Frequency: How often releases are deployed into production.
      3. Average Lead Time: How long it takes for a new feature to be developed, tested and deployed into production.
      4. Deployment Speed: How long it takes to deploy a new release into production.
      5. Production Failure Rate: The frequency of production failures.
      6. Mean Time to Recover (MTTR): The time required to recover from a failure.
    3. Visualize the Workflow: You won’t really know how effective DevOps will be until you put it into action. By creating a visual model, team members will have a better understanding of how their work impacts the entire DevOps process.
    4. Create Continuous Process: DevOps requires automation, and lots of it. High-velocity robust releasing can only be achieved through the implementation of CI and CD. In CI, members of a team integrate their work frequently to build software faster, while CD offers the opportunity to integrate automated testing into the release process.
    5. Improve Communication: With teams now integrated, the next step is to make sure they can communicate with one another. Start by establishing a unified language between business and engineering teams to express the desired acceptance criteria for both teams.

    As organizations embrace DevOps, culture will be as important as technology in making a successful transition. Make sure that your DevOps playbook addresses how your chosen DevOps tools and technologies will work together with people and processes.

    — Jeremy Cook

  • Manual Processes and Silos Complicating DevOps Deployments

    Manual Processes and Silos Complicating DevOps Deployments

    The DevOps concept largely originated in 2009, as software and IT organizations were beginning to adopt Agile methodologies. It came on the heels of a movement to integrate lean manufacturing concepts and infrastructure as a service into IT organizations. Rapid development was the goal, but application and infrastructure teams were still working independently, creating barriers to progress. Flickr employees John Allspaw and Paul Hammond delivered a presentation at the O’Reilly Velocity Conference that outlined ideas for streamlining deployment through better collaboration between development and operations. They hoped to temper conflicts between team members and minimize waste. DevOps took off soon after, when Patrick Debois founded the DevOpsDays conference in Belgium.

    When DevOps is a mature practice in IT and software organizations, there are some powerful benefits:

    • Every change to the application stack triggers a new deployment.
    • Deployments become easy and not a fire drill.
    • Fixing errors in production become a simple redeployment without the need to perform a huge root cause analysis up front.

    The Long Road to DevOps

    While many organizations are adopting DevOps practices and tools today, we’re still a long way from reaching DevOps maturity. Our company recently conducted a survey on DevOps adoption, and the findings indicate that there are still too many manual processes and silos standing in the way. I will break them down here:

    Manual Infrastructure Management is Still Common 

    Nearly 40 percent of IT professionals surveyed say that they manage infrastructure manually. Yet nearly 60 percent report the use of infrastructure-as-code tools such as Terraform, configuration management and Kubernetes. This speaks to a disconnect between having the technology available to operate in an automated way and being able to execute change with those tools. Heavy manual processes lead to higher costs, since so much effort goes toward tinkering with configurations and fixing problems. Manual work also detracts from the ability to members to focus on the application and business needs.

    Managing Environments in Silos

    Another tenet of DevOps infrastructure management is environmental parity. This means that through infrastructure-as-a-code tools and processes, IT manages all development environments similarly through a common code base. According to the survey, only 25 percent of companies are managing development, test and production environments identically. This results in application stability issues. Without environmental parity, every change will eventually lead to an outage.

    Managing Teams in Silos

    From the start, DevOps has emphasized breaking down the walls between development, QA and IT operations. The goal is to enable continuous feedback, fewer errors and faster development cycles. Of survey respondents, 78 percent report that separate teams are still managing infrastructure/operations and application development. As well, just because you create a DevOps team consisting of various job roles doesn’t mean that people are working together and are committed to the team’s success.

    There must be incentives to encourage a developer to understand testing needs and for infrastructure engineers to get clear on a project’s requirements and objectives. There should be minimal tolerance for functional experts isolating themselves without making an effort to understand the bigger picture.

    When organizations are able to minimize manual processes and break down these technology and silos, they benefit from a totally different, more productive way of working:

    • Adoption of continuous integration/continuous deployment, whereby every code check-in triggers a testing cycle and a build.
    • Transparency between infrastructure people and developers, avoiding surprises resulting in issues or rework later.
    • Incorporation of success metrics, such as deployment frequency, mean time to detection (MTTD), mean time to recovery (MTTR) and change lead time.
    • Cost reduction, from fewer errors and labor-intensive manual processes.
    • Increased productivity, as developers get the infrastructure they need quickly to run new projects and QA and IT Ops people can focus on high quality, stability and user experience rather than repetitive tasks and troubleshooting.

    So, What’s Going On? 

    Despite the many benefits of DevOps, there seems to be a lack of urgency in some organizations to take the necessary steps for change. Progressive IT departments that applaud agility and business value should be ahead of the curve, but that’s not always the case.

    DevOps maturity comes down to setting the right culture for change, which must emanate from the top. The shift to DevOps takes time and investment, no doubt. There’s also need for patience. The transition temporarily slows down production as people adjust to new workflows and learn new skills. Replacing toolsets is just part of the strategy. Organizations must make a conscious effort to embrace DevOps with a well-thought out plan.

    — Lars Cromley

  • DevOps Adoption: The Driving Force of the Industry

    DevOps Adoption: The Driving Force of the Industry

    DevOps has transformed from a mere idea on paper to the way processes function in the face of an immediate requirement. Development and Operations together make for one of the most successful collaborations today.

    As per a research report, people have now begun to understand what DevOps is. When asked how familiar they were with DevOps, 84 percent of respondents said that they well-versed with the concept, in comparison with 60 percent who agreed to the same the previous year.

    DevOps is writing the success stories of the world’s business giants. Facebook, Google, Twitter and Amazon are all working the “DevOps way.” All falls in place when these companies develop, test and successfully deploy code in a matter of one to 23,000 minutes per day. We agree that’s insane!

    How Have We Benefited from DevOps Adoption?

    To sum up the benefits of DevOps adoption in a nutshell, users see:

    • Drastic reduction in lead times—With the pressure to deliver software faster and meet the challenges of the growing market, there is always a need to look at progressive ways of getting the job done, DevOps became the solution. As per statistics, practitioners believe this to be the top benefit of DevOps in 2018. Sixty-nine percent of respondents agreed to this benefit, as compared to 39 percent in 2017.
    • Increased ability to release new features with improved reliability stability and security—The need to improve the user experience and keep the customer equipped with the necessary tools to meet the challenges of a growing business made IT personnel realize that it is always essential to introduce new features into the deployment process. DevOps made it easy. Figures tell us that the implementation of DevOps led to 73 percent of people believing in its benefit of enhanced user experience, this year.
    • Enhanced IT and Organizational Productivity, Higher Profitability, Revenue and Market Shares—Now with the best process having so much to offer, all businesses have gained a lot in terms of savings and earnings. DevOps drives revenue: 26 percent of people reported an increase in revenue in the year 2018 as compared with 20 percent in 2017.

    Why No DevOps?

    Although we’ve seen a major shift in trend from being skeptical about DevOps and its implementation to becoming “pro-DevOps,” over the years, not all of us are up for this big business move. The reasons being many.

    Listed below are the most commonly given reasons by industrialists around the world:

    • Other technology and business priorities—With newer technologies being developed every few weeks, companies are confused over which technology will give their business the required leverage. This leaves them to either becoming very choosy or just ignoring the prospects of adopting a technology at all. Some business owners think about fund allocations. They want to invest their hard-earned money into something they see as more viable or something that convinces them about profits. When it comes to innovative ideas such as DevOps, they think these things may not bring them immediate results or they’re not as important as the “conceived” business priorities. As per a study conducted in February 2018, as much as 38 percent of the sample population opted out of DevOps for the above reason.
    • Lack of resources—Most organizations lack the required resources in terms of personnel, tools and persons with expertise. This discourages organizations from taking up such practices. While it is great to have a workforce with work experience for the dev and ops teams individually, it is crucial to have employees with DevOps experience on board. Similarly, lacking the right tools can have your organizations whimpering in the wake of a growing market despite having an able workforce. Statistics show that 34 percent of people hesitate to adopt DevOps for the given reason.
    • Lack of cooperation between development and operations—Whenever there is a mention of DevOps, there is also a mention of the cultural indifference of Dev and Ops teams. Each team has their unique work culture and when they come together on common ground, they cannot help but fall apart. Most organizations do not encourage the DevOps practice on account of this cultural disparity.A significant 22 percent of the industries under this research shun the idea of DevOps owing to this disparity.
    • ‘We don’t see the value’—It is likely for some business to say this. It is difficult to assess the value of the process from an outsider point of view. If someone has heard about DevOps but don’t how it will profit their businesses, then it is difficult for them to adopt it. As per statistics as small as 6 percent of the sample population did not adopt DevOps for this reason.

    On an End Note

    Organizations have been opting for DevOps after seeing its contributions to the industry. This year has most businesses functioning with major dependence on the skill and agility of the DevOps processes, and this has been proven through the success of their business. We hope the remaining number of entrepreneurs come to realize the importance of DevOps for their business and implement its benefits to build their success and keep up with the challenges of the fast-growing market.

    — Veritis

  • 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

  • For DevOps, (Organizational) Size Matters

    For DevOps, (Organizational) Size Matters

    When it comes to DevOps, size matters. The number of people in your organization, as well as the size of its infrastructure, play a huge role in shaping how and why you adopt DevOps.

    The importance of company size may come as a surprise. Few conversations about DevOps mention the role of organizational size in building a strategy.

    That may be in due, in part, to the fact that DevOps engineers tend to be obsessed with the idea of scalability. A healthy DevOps process is one that can support an application with a million users just as effectively as it supports an application with a hundred users.

    In theory, your strategy should be similarly scalable. But in reality, this is unlikely to be the case. The way that a company with a dozen employees does DevOps is going to look quite different from the way a Fortune 500 company does.

    Small Companies

    In a sense, DevOps is easiest to achieve at very small organizations. In fact, it is almost inevitable in companies of this size.

    That’s because, when you have a very small IT staff, your engineers will end up playing multiple roles because that is the only way that all IT tasks can be completed successfully. People you hire as developers will have to help support and test the apps they write because otherwise, those processes might not happen.

    What this means is that at small companies, it tends to be something that happens organically, not deliberately. IT teams at such organizations don’t need to plan a DevOps strategy; they just need to let it come into being of its own accord.

    Large Organizations

    You might expect the opposite to be true within large organizations. But in many cases, it’s not. Large companies may also find themselves building their strategies organically.

    The reason is that, at large enterprises, the IT organization tends to be broken down into many small teams, each working on different apps and processes. Because these individual teams are small, their members also tend to embrace DevOps practices by performing multiple IT roles, whether deliberately or not.

    True, large companies often benefit from planning and implementing a companywide strategy. Encouraging DevOps best practices companywide can help to improve collaboration between different teams within the organization. It can also improve the ability of security or QA teams, which may otherwise operate in silos, to interact with other groups.

    But by and large, if you are an enterprise whose IT staff are broken into a number of small teams, you will likely find that DevOps happens more or less on its own.

    Medium-Sized Organizations

    It’s medium-sized organizations that tend to have the hardest time doing DevOps effectively. That’s because these organizations are large enough to have a sizeable IT organization, but too small to break that organization down into multiple project teams.

    As a result, medium-sized organizations erect the most rigid silos around their IT teams. They might have a single team of developers who focus on building a few applications, and a single IT Ops team whose job is to support those applications. But these two teams may not interact much.

    For this reason, a deliberate DevOps strategy is most important for organizations that are of a medium size. Their silos need to be broken down actively.

    Conclusion

    The bottom line: When it comes to adopting and improving DevOps, take some time to evaluate how the size of your organization impacts it. Is your company sized and organized in such a way that it will more or less happen on its own, or do you need to take deliberate steps to implement it? Answering this question is crucial for achieving DevOps in the most seamless way possible.

    — Chris Tozzi