devopsy.kinsta.cloud

Tag: DevOps practices

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

  • Engineering Practices Can Overcome DevOps Challenges

    Engineering Practices Can Overcome DevOps Challenges

    When I think about the challenges of DevOps transformations, I love the viewpoint expressed by Ryan Harmon, strategic accounts manager at Trace3: “DevOps is a complex maze that has many leaders frustrated. In many large enterprises, ‘DevOps’ is simply a buzzword they are striving to achieve but struggle with what the end state looks like or even where to start. There are many layers across the organization that are instrumental to truly executing on DevOps. DevOps is not something you go get a quote for and simply buy. It’s an evolving journey.”

    In my previous article, The Time Has Come for an Engineering Approach to DevOps, I agree with Ryan.

    Too many organizations launch into a DevOps transformation initiative without considering the full scope of what it takes to engineer a successful DevOps solution. DevOps is more than “just” a CI/CD pipeline or toolchain, as complex and challenging as this alone may be to accomplish, for even one application. DevOps is more than simply a culture change, as difficult as that always is.

    There are 24 DevOps practice categories that need to be mastered to realize and evolve well-engineered, high-performance enterprise DevOps solutions. Not all 24 need to be mastered to begin the DevOps transformation, but, ultimately, all of them do need to be mastered before the solution will achieve the high performance levels to which many enterprises aspire. The good news is, successful enterprises have demonstrated that the investment in people and technologies required for the journey is worthwhile, and a strategic approach will get you there systematically if you follow a disciplined engineering implementation roadmap.

    As explained in my book, Engineering DevOps, the core of every successful DevOps practice includes nine core pillars. These are the pillars to focus on as you start on your DevOps journey. The following paragraphs illustrate requirements for each of the nine pillars.

    Leadership – Leaders set an inspiring DevOps directional vision for the organization, and proactively stimulate and sponsor team activities that help progress toward goals.
    Collaborative culture – The organization encourages cross-functional collaboration, shared responsibilities and works to reduce restrictive boundaries between organizational functions.
    Design for DevOps – Products are architected to support service-oriented, modular, independent packaging, testing and releases, in accordance with the principles of twelve-factor apps.
    Continuous integration – Changes to software code and artifacts needed for releases are frequently merged, built, tested and packaged into executable artifacts for application releases.
    Continuous testing – Software tests that are most important to verify the results of pipeline stages including pre-flight, integration, regression, performance and release acceptance tests are automated as much as possible.
    Elastic infrastructure – Infrastructure-as-a-service (IaaS) resources (i.e., software, computing machines, storage and networks) are integrated into a toolchain for automating builds and testing environments to efficiently support variable workload demands.
    Continuous monitoring – Applications, pipeline tools and infrastructure components are instrumented with metrics, and the collected data is analyzed to manage health and performance.
    Continuous security (DevSecOps) – Security practices, processes and technologies for applications, databases, pipelines and infrastructures are integrated into the culture and pipelines to assure security.
    Continuous delivery – Release artifacts are validated, prepared for deployment to production and may be automatically deployed to production once acceptable deployment measures are achieved.

    A Comprehensive Engineering Blueprint

    While the above nine practice categories are the core of every successful DevOps solution, 14 additional practice categories are essential parts of a comprehensive engineering blueprint for accomplishing high-performance DevOps.

    DevOps infrastructure practices are used continuously by the nine core practice categories as follows:

    Version management systems – Every stage in the end-to-end DevOps value stream depends on keeping track of versions of software source code, configuration data and executable images using source code management systems, artifact repositories and configuration management systems.

    Infrastructure-as-a-Service – Virtualized cloud and dedicated resources must be served up ephemerally to meet variable workload and storage demands, which requires mastering engineering practices for orchestrating dedicated and cloud, hybrid cloud and multicloud services, and deployment of applications to the infrastructure.

    DevOps pipeline practices, which constitute a layer just above the nine core practices, include two additional categories that make use of the nine core DevOps practices.

    Application release automation – Directing and monitoring software changes through the CI/CD pipeline requires process orchestration and data analysis working at a level above the CI/CD pipeline itself.

    Value stream management – A deployed service, composed of multiple application microservices and data services, requires orchestration and analysis of a federated set of services, end-to-end, across the value stream from planning through to operations.

    Management Practices

    DevOps management practices include four categories that make use of the DevOps Pipeline practices, as follows:

    Service catalogs – Organized collections of software stacks, tools and pre-configured pipelines, made available through portals, enable DevOps-as-a-Service operations and simplify access, configuration, control and evolution of DevOps resources needed by enterprise application teams.

    Disaster prevention and recovery – Proactive disaster monitoring coupled with high-availability configurations and disaster mitigation practices, such as automated processes, work together to minimize the blast radius of disastrous events, and orchestrate rapid restoration of essential DevOps services, when needed.

    Site reliability engineering (SRE) – A combination of practices which include service level objectives (SLOs), error budgets, monitoring, work-sharing policies, toil reduction, proactive anti-fragility practices and blameless post-mortems help to “shift left” production wisdom from operations into development, thus improving the efficiency, readiness, security and resiliency of applications and infrastructures in production.

    Governance – The scale and scope of enterprise DevOps solutions are controlled using governance policies-as-code implemented through service catalogs, management dashboards and error budget policies.

    Project Practices

    DevOps project practices include four categories that guide enterprise adoption and evolution of DevOps, as follows:

    Adoption – Enterprise-wide DevOps adoption strategies that engineer and build DevOps capabilities in logical phases. This begins with a small set of representative applications that serve as a model for other applications; this method has been shown to be more successful than “boil the ocean” strategies that attempt to transform all applications at the same time.

    Model applications – Applications – that can serve as a model for greater enterprise adoption – are selected and monitored according to criterion that spotlight the value of DevOps for other applications.

    Return on investment (ROI) – DevOps investments must compete with other IT projects for resources. An ROI model that demonstrates measurable cost savings is an approach that has proved to achieve greater numbers of DevOps project approvals compared to other methods.
    Continuous improvement – Competitive forces and industry trends require that DevOps solutions continue to evolve to keep up with enterprise requirements.

    The Human Element

    Human development practices include two categories, as follows:

    DevOps engineering – The development of DevOps engineer roles, skills and the structure of DevOps engineering within an organization is critical to the success of designing, building, maintaining and evolving DevOps solutions.

    Continuous learning – A DevOps continuous learning strategy is critical for the development and transfer of DevOps knowledge needed to develop and continuously improve DevOps for the enterprise.

    In summary, the importance of practice categories – and specific practices within each of the categories – will evolve as each application does, alongside the changing needs of the enterprise. DevOps is complex, but a comprehensive engineering strategy that considers the 24 DevOps practice categories described in this article can help enterprises achieve the high-performance DevOps solutions they need to justify the investment and to meet business goals.

  • The Secret to Winning at DevOps: Are You Up for the Challenge?

    The Secret to Winning at DevOps: Are You Up for the Challenge?

    The main idea behind DevOps is to enable companies to keep up with the increased software velocity and advancements in agile culture for a smoother end-to-end software delivery cycle.

    The main goal of DevOps is to accomplish integration and automation, which is why implementing this philosophy can be challenging. Not only do you need to replace older methods and practices, but you’ll also have to change the mindset of the developers and the operations team to ensure they work in sync.

    Several IT operations teams and software teams have adopted DevOps practices into their work culture for faster evolvement and improved innovations. The pipeline comprises continuous integration, testing, deployment, as well as monitoring application and system performance.

    Introducing new DevOps tools and changing the mindset to prepare teams for the fast-paced world remains crucial for a successful implementation.

    Despite the revolution that this philosophy brings to software development, several enterprises find themselves taking DevOps to an unproductive extreme. To remain productive, one of the aspects that teams need to work on is reducing rework, and the best way to ensure this is automation.

    Understand How DevOps Works

    Under a DevOps model, the development and operations teams are integrated into one to prevent them from getting siloed. This also improves collaboration and productivity.

    You see, it brings alive the possibility of both the teams thinking more alike, working together and sharing responsibilities. This is done by automating code testing and workflows, automating infrastructure and continuously measuring application performance.

    In some models, even the QA and security teams merge with the dev and ops. In cases where security becomes the primary focus, the name gets modified to DevSecOps.

    In essence, the focus of DevOps is on automating processes that were otherwise manual and slow. Teams use a technology stack and tooling that can operate and evolve applications more reliably and swiftly. As engineers will be able to accomplish tasks such as deploying code and provisioning infrastructure faster with reduced issues, teams can reach testing and maintenance stages quicker.

    Balance Between Standardization and Adaptability

    Software products are mostly developed from the customers’ perspective, and if not, from end-user experience. Often, developers work backward to identify customer needs and wants for ascertaining successful innovation.

    One of the biggest challenges when developing a software development life cycle (SDLC) strategy for organizations is to consider dynamic customer needs, strict compliance policies, unpredictable market trends and company goals. To ensure a consistent workflow, DevOps teams need to adopt standardization. In fact, workflows, technologies, processes, protocols and metrics need to be standardized before they can be automated.

    This is also the main reason why organizations adopting DevOps need to strike a balance between standardization and adaptability. One industry that has excelled at this has been the financial industry, which has been leading the charge when it comes to adopting the latest software delivery practices and technologies, including DevOps. Financial executives view DevOps as being a way to improve security and risk and governance strategies. 

    The result is that cloud-based financial services are now automating virtually all of their processes through their software delivering pipelines, which makes tasks such as scanning receipts, sending invoices, tracking expenses or making payments seamless as they sync to your account. This simpler process is beneficial for boosting developer productivity and resource utilization, and for enabling enterprise scale management. If anything automating processes is becoming necessary for achieving higher product quality, compliance and scalability. 

    As mentioned above, new DevOps tools need to be introduced to team members to keep up with the constantly evolving strategies and implementation. But to prevent the creation of silos between teams, mechanisms need to be developed to make the adoption of new technologies easier. 

    Achieving the delicate balance between standardization and automation will help eliminate communication gaps, performance bottlenecks and silos between the different teams.

    Benefits of Automation in the DevOps Landscape

    The following are the advantages of adopting a DevOps philosophy:

    • Code Development. Source control will keep everyone in the loop by managing, tracking and documenting any changes in code. This can be time-saving, and reduce the complexity of software projects.
    • Smoother Testing. Testing is a continuous process in DevOps frameworks that includes system communication, several test integrations, predicting and tracking issues, and integrating approved automated builds. In the absence of automation, executing and managing continuous testing could be a rather tedious job that might cause problems between developers and the operations team.
    • Better Visibility. The main job of the ops teams is to be aware of the code changes, ongoing problems and the impact of a specific code on the end goals. Plus, when they operate in a DevOps environment, they need to keep the developers in the loop as well.
      For example, if a system administrator from the ops team identifies code issues weeks after submission, it puts more pressure on developers. Now, the developers have two jobs: solve the problem in the previous code, and simultaneously work on making progress with the new code. This is what gets time-consuming, which can harm the company’s market standing. To remain ahead in the competition, innovation needs to be frequent and accurate.
      When there is a constant feedback loop between the dev, ops and QA, bottlenecks, and silos are eliminated, productivity is improved and customers are happier due to quicker innovation.
    • Continuous Integration and Delivery. Automation can help deliver appropriate software built, data, code changes and tests to target environments. An example is how web hosts for e-commerce businesses need to be updated frequently for robust deployments. Automated testing will help ensure that code is delivered properly and doesn’t introduce new bugs, thus creating a platform with a superior user experience.
      This, in turn, helps DevOps teams to introduce frequent software changes by deploying error-free codes and continuous testing.
    • Data Processing and Monitoring. The teams also need to measure and monitor the performance of their environment, which can be done by reading and analyzing system logs. But the existence of hundreds or thousands of servers in the environment can make it complicated.
      Automation will allow the teams to make sense of all the data and let them know how an application is performing and whether there are any bottlenecks.

    Getting the Balance Right

    Organizations need to realize that automation involves placing technologies around once-manual processes. The catch here is as the processes will become inherently repeatable, they need to be correct. Otherwise, organizations will only have flawed processes running faster, which will ultimately defeat the purpose of adopting DevOps in the first place.

    Companies need to understand adaptability as well. This can be done by mixing both the old as well as new systems. For this purpose, an inventory of all applications, data stores and development processes for promoting meta development processes that include design, development, testing, deployment, configuration management and so on can be made.

    In the end, the secret to winning DevOps is aligning DevOps tools with your organization’s goals – not following the footsteps of other organizations.

  • How DevOps Tools Are Contributing to Automation Initiatives Across the IT Landscape

    How DevOps Tools Are Contributing to Automation Initiatives Across the IT Landscape

    Prolific advancements in IT, specifically in agile methods and culture over the years, has led to burgeoning needs for a more holistic end-to-end software delivery approach. Agile development is an umbrella term that encompasses numerous incremental and iterative software development practices — including Kanban, SAFe (Scaled Agile Framework), Scrum, Extreme Programming (XP), Lean Development, among others.

    Each methodology works on its own unique approach. However, the core commonalities they share lie mainly in their values and vision. The methodologies integrate continuous feedback from iteration to refine and deliver a successful software system. They include various forms of continuous evolution, such as continuous integration, planning and testing, of both software and project. Furthermore, one of the most significant aspects of agile methodologies is their keen focus on empowering workforces to work together and collaborate more efficiently, thus simplifying and speeding up decision-making processes.

    Advancement in agile development is what has birthed the DevOps culture. The technology is born from the rising need to adapt to increasing software velocity and throughputs generated through agile methods.

    Understanding DevOps

    The DevOps market consists of a set of practices, designed to integrate and automate processes between IT and software development teams, enabling them to create, test and deploy software in a quicker and more efficient manner.

    The term DevOps, which was coined in 2009 by Andrew Clay Shafer and Patrick Debois, is a combination of the words “development” and “operations.” It is also indicative of a cultural shift in the IT sphere, which bridges the gap between historically siloed teams, such as operations and development.

    The DevOps framework essentially adopts a culture where the critical focus is on facilitating collaboration between the business, operations and development teams. Although tools are considered as pillars of the technology, DevOps is designed to deliver continuous value for customers, empower organizations to provide solutions of the highest quality at swift rates, and bring about the automation of the entire business process spectrum, from building to deployment of a product or application.

    Shifting Trends Toward Automation in Software Development Processes and the Subsequent Impact on DevOps Adoption in the IT Space

    The software development process consists of several integral parts, among which testing is a crucial task. It allows developers to monitor the functionality of the software, monitor and register performance, and detect any aspects that require remediation. However, with software projects becoming increasingly more complex as the years progress, and with project development life cycles accelerating, conventional methods of manual QA (quality assurance) testing fall short in meeting testing objectives within the desired time frames.

    Consequently, software developers are shifting their focus toward automated workflows and testing tools, in order to expedite testing routines without compromising on consistency and completeness in QA processes.

    DevOps practices are significantly dependent on automation to ensure frequent and timely deliveries across platforms. Studies have shown that nearly 85% of IT leaders claim that automation is a critical aspect of their DevOps strategies. This is attributed largely to the fact that automation empowers infrastructures to successfully field constant changes in codes that are associated with DevOps tools. 

    Furthermore, automation allows the effortless scaling of environments and unburdens skilled workforces from mundane and repetitive tasks, enabling them to focus on more integral aspects.

    Considering a process perspective, automation in testing involves the addition of test automation actions and tools to regular software development regimens. For instance, new builds delivered to a repository can be automatically subjected to automated testing procedures using a number of prescribed tools, with little to no need of developer intervention. The results are recorded with care, then compared to previous test runs and eventually submitted for review to developers. 

    Depending on the outcome, the software can then be cycled back to the developers for further remediation or approved for deployment. This is especially relevant in terms of the DevOps framework, which relies on continuous integration/continuous delivery (CI/CD) pipelines.

    CI/CD pipelines are a prominent outcome of developer operations, allowing developers to validate the quality of the software with minimal intervention, and deploy apps and software to customers in a quicker manner.

    CI/CD platform CircleCI, for example, has recently raised over $100 million in Series E funding, in an effort to boost the development of their DevOps product suite. This move is indicative of CircleCI’s proficiency in delivering an automated approach to DevOps practices, including tools for companies to create, test and deliver software.

    How Is the Current Pandemic Impacting Digital Development?

    The COVID-19 pandemic has asserted a massive influence on the industrial landscape, driving workforces across the globe into remote-only work set-ups. With millions of people working from home for a seemingly indefinite period, enterprises across the globe are rallying to accelerate automation efforts in order to more efficiently deliver digital business applications to engage their employees from remote workspaces.

    According to various studies, nearly 73% of IT operations and DevOps teams are working toward maintaining and expediting initiatives for digital transformation throughout the current crisis, holding the belief that the value of digital offerings is set to witness a positive growth trajectory in the social distancing era.

    DevOps industry players such as JFrog are working toward providing enterprises and teams with access to cloud-based DevOps technologies, free of cost, particularly those which are undertaking active research and response efforts to combat the COVID-19 pandemic. These DevOps technologies include Pipelines, Xray and Artifactory, among others.

    While the exact impact of the global crisis on the DevOps environment in particular and the IT space in general is yet unclear, it is becoming more prominent that the strong focus on the prevention of such crises in the future — both in and out of the IT realm — is likely to set a great precedent for the growth of the DevOps industry in the years ahead.

  • The Secure Software Development Life Cycle: Syncing Development and Security

    The Secure Software Development Life Cycle: Syncing Development and Security

    Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

    As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

    Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

    The Changing Nature of Software Development

    The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

    For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

    So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:

    • The code is still fresh in the developers’ minds.
    • Coding problems can be caught earlier and more easily while developers are still thinking about the code.
    • It mitigates the risk of developers not remembering the code context at a later date.

    Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

    Automated Security Assurance and Out-of-Band Activities

    When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

    There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

    Life in the Fast Lane

    For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

    In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.

  • DevOps Practices: How to Make Valuable Changes to Your Teams

    DevOps Practices: How to Make Valuable Changes to Your Teams

    DevOps has become a buzzword within the software development industry, promising rapid turnaround times for requested changes. As for developers, DevOps promises to increase productivity while reducing the risk of production failures. The book “The Unicorn Project” by Gene Kim describes this process for developers as The Five Ideals.

    In this article, we’ll focus on only two of them:

    • The Third Ideal — Improvement of daily work
    • The Fourth Ideal — Psychological safety

    Psychological safety and improvement of daily work make it easier for developers to create changes for their teams, and the work to implement these ideals is not difficult. From automated testing to production monitoring, there are many great things that even junior developers can help bring to their teams that will help their entire team make safer changes to their code.

    So, what are these easy changes that can be made? Below is a list of tasks that can be done to improve the projects you are assigned to, with most taking less than four hours to complete.

    1. Set up a continuous integration server for your project, such as Jenkins or Team City. This will allow for automated jobs to be run for your code.
    2. Create jobs to run testing for pull requests as well as testing jobs to run overnight. This will show the current state of your project’s tests on a nightly basis and will allow for the number of failing tests to be monitored over time.
    3. Add a code coverage tool to your automated tests. This will show what is being tested in your code and what is not being tested, creating opportunities to help shore up your teams testing suite as well as confirm that your changes will be covered by existing tests.
    4. Create an automated deployment job on your CI server. This will convert the manual deployment process in a one click job, allowing the code to be deployed on command.
    5. Modify your project to extract metrics of the project, allowing your code to easily be monitored for faults in production.

    The tasks highlighted above will quickly add value to your team while helping protect you for making dangerous changes to your team’s code base. I recently changed teams and have moved to a new web project. The project runs fine on my local, but it is hard to track what is affected by my changes. The team already has a CI server to build their code, but there is no point in setting up any testing jobs as the project has fewer tests than I have fingers.

    Instead, I created a monitoring tool that captures all requests to the website and records their results. With the tooling in place, my team can now see how long it takes for each part of the website to load, as well as how many errors are being produced. Now, when I make any changes, I can check these metrics to see if my change is causing issues to the site, increasing my confidence in my code.

    If you are interested in learning more about DevOps and how to take advantage of it, here are a few good reading resources to look into:

    • “The Unicorn Project,” by Gene Kim.
    • “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford.
    • “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations,” by Gene Kim, Patrick Debois, Jez Humble and John Willis.
  • 2020 DevSecOps Community Survey: Of 5,045 Developers, Guess How Many Are Happy?

    2020 DevSecOps Community Survey: Of 5,045 Developers, Guess How Many Are Happy?

    We just released the seventh annual DevSecOps Community Survey. We captured the pulse of over 5,000 developers in 102 countries. What we learned about trends in DevSecOps will surprise you—especially the parts about how happiness influences company culture, software security and business competitiveness.

    When we tallied up the results we quickly saw some interesting correlations. Organizations with mature DevSecOps practices innovate faster and produce more secure software. Why? It boils down to having happier developers. Developers in mature practices were 1.5x more likely to say they enjoyed their work. Mature DevSecOps practices are also 1.8x more likely to use automated security tools, which certainly makes developer’s lives easier.

    Here are just a few interesting tidbits we discovered.

    Happiness Influences Culture

    “We’ve always known that DevSecOps is about culture. The 2020 DevSecOps Community Survey, for the first time, reveals clear and convincing empirical evidence that developers are happier and more productive when security is part of the digital transformation and DevOps journey,” said James Wickett, head of research at Verica.io.

    Just like you can’t buy happiness, you can’t buy good culture. You have to cultivate it. Here’s what the survey showed:

    • Developers who received secure coding and programming opportunities are five times more likely to enjoy their work.
    • By contrast, only 19% of unhappy developers get similar training. Unhappy developers say they aren’t satisfied at work and are actively seeking other opportunities. You can see why they are grumpy cats.
    • Happy developers don’t feed off rumors—at least, not for security incidents. Instead, they focus on empirical evidence from better integrated tooling and security teams. Developers working in mature practices are 3.8x less likely to rely on a rumor.

    Happiness Influences Security

    “Mature DevOps practices are constantly testing, deploying and validating that software meets every requirement and allows for fast recovery in the event of a problem. As a result we can easily say, ‘DevSecOps is DevOps done right,’” said Hasan Yasar, technical director and adjunct faculty member at the Software Engineering Institute, Carnegie Mellon University.

    Happy developers build more secure code. Here’s how they do it:

    • Mature DevOps practices are 1.7x more likely to have a complete SBOM (Software Bill of Materials), including dependencies. This makes finding and fixing open source components faster and easier. 
    • Code quality? Check. Happy developers are 3.6x less likely to neglect security. This is because, with proper tools, they can focus their efforts on what is important.
    • Grumpy developers are 2.6x more likely to ignore a security warning compared to happier developers working in more mature DevSecOps practices.

    Happiness Influences Business Outcomes

    “We cannot achieve higher levels of DevOps maturity until we understand how tightly woven people are into the transformation process. More than anything, DevSecOps success is tied to human effort,” said Jayne Groll, CEO of DevOps Institute.

    Businesses depend on secure code built by happy people. Look at these findings:

    • Happy developers are 1.4x more likely to follow their company’s open source governance policy. This is an important part of risk management. Ignoring policy and lessening software supply chain security can have catastrophic business implications.
    • Happy developers are 1.8x more likely to recommend their employer to peers and friends, a real boon for attracting and retaining talent in a competitive environment.
    • Happy developers are 1.7x more likely to get the job done. If productivity is the name of the game (and it often is) then businesses with mature DevSecOps teams outcompete the rest.

    Download the full report here. Also, be sure to register for All Day DevOps | Spring Break on April 17th. I’ll be doing a session that goes over the report in depth and you won’t want to miss it.

    — DJ Schleen

  • Predictions 2020: The Year of DevOps Empowerment

    Predictions 2020: The Year of DevOps Empowerment

    Every year since mid-decade, it seems, one publication or another has declared it to be “the year of DevOps.” Allow me to make the case that it really will happen in 2020.

    The reason? IT leaders are finally empowering their engineers with full-service ownership.

    In a world in which speed, quality and precision will continue to determine the difference between continued success and unmerciful failure–particularly with regard to delivering best-in-class, end-to-end experiences for all stakeholders–full-service ownership is a matter of reality and necessity. Not to mention common sense.

    Developing and delivering products and services that maintain pace and meet the needs of businesses is dependent on achieving faster release cycles without sacrificing quality. But running reliable systems at ever-increasing speeds presents huge challenges that software teams can meet by changing their service ownership policies. The good news is DevOps practices have been gaining considerable traction because they help teams deliver with increased velocity coupled with reduced risk. This enablement, similar to any change introduced, takes time and practice to make work for your needs.

    Code It, Ship It, Own It

    Full-service ownership grants engineers greater responsibility for the code they write and the services they develop during production. The importance of owning and operating your own code and taking responsibility for all deliverables should not be underestimated, because it is the engineers, after all, who should be–and have earned the right to be–accountable. They are the ones designing architectures and systems, coding software and writing runbooks. They are the ones on whose shoulders the overall quality of service sits. They are the ones who are on call when issues arise (invariably, as Murphy’s Law implies, in the middle of the night).

    If they are the ones who code it, then they are the ones who should ship it and own it. The days of engineers “throwing code over the wall” to operations or depending on site reliability engineering (SRE) teams to guarantee the performance of services in the wild are no longer relevant, much less workable.

    That’s particularly important going forward, considering the DevOps market is predicted to grow 18% to nearly $13 billion by 2025. As DevOps tools and solutions become more ingrained in IT operations, the most logical and proactive way to manage this growth, and the inevitable chaos it will bring, is to empower IT with full-service ownership.

    The Forces Behind Full-Service Ownership

    This is happening for three reasons:

    Accountability

    It’s a simple truth; consumers implicitly expect the services they use to work seamlessly and with minimal latency. Considering that consumers will simply move to another site when a page is slow to load or returns a 404 error, the payoff in terms of increasing business’ competitive advantage is immense.

    Full-service ownership promotes higher-quality work because it gives engineers clear visibility into how the code and services they’ve created are performing and impacting their customers’ daily activities. 

    Reliability

    It’s not rocket science to ask the scientist who built the rocket to fix it when it breaks. Likewise, businesses can reduce the amount of downtime and customer impact when a serious incident occurs by immediately bringing in the engineers who wrote the code or created the service. 

    Full-service ownership offers another important advantage: overall institutional knowledge among IT teams. Individual engineers benefit greatly from code reviews, on-call hand-offs, daily standups, casual information sharing and other exercises that build redundancy in knowledge and expertise.

    Continuous Improvement

    A common misconception in the engineering world is that “on-call” is synonymous with “always-on.” That in itself is counter-productive because it can lead directly to alert fatigue. In an ideal world, teams will build time in their development work to go “off-call,” a practice that alleviates alert fatigue and that full-service ownership encourages.

    It also fits perfectly with an integral element of the culture of engineers: a commitment to continually refine and improve their code, product, services and alerting. The most effective process goes beyond just fixing problems, it also includes getting ahead of them, by automating the work needed to prevent them, freeing engineers up to focus on the work that matters most. 

    Five Benefits of Full-Service Ownership

    1. The quality of the code will increase.
    2. Engineers will know when they are off-call, and alerts will be covered by another developer with equal expertise.
    3. Team knowledge and skills will increase through a deeper understanding of the codebase.
    4. Services will become more reliable.
    5. Operations will become more agile.

    When engineers are empowered to code it, ship it and own it, businesses put themselves in a better position to enhance the customer experience and reduce the impact of disruptions, which enables them to focus more on innovation. By defining and refining roles and responsibilities, full-service ownership also reduces the chaos associated with incidents, eliminates silos and unnecessary layers and, ultimately, promotes a culture of empowerment and accountability.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Tim Armandpour

  • DevOps at a Distance

    DevOps at a Distance

    How do you successfully follow DevOps practices when the two parts of your team are 5,000 miles (8,000km) and two time zones apart?

    Airwallex is a global fintech founded in Melbourne, Australia just four years ago. It is Australia’s fastest-growth tech unicorn with a valuation of over $1 billion thanks in part to investments from companies such as Tencent Holdings, Sequoia Capital, Square Peg, Horizon Ventures, DST Global and MasterCard.

    The business came into being when co-founders Jack Zhang and Max Li–who both worked in the banking sector–started a cafe in Melbourne’s Docklands area and realized that expensive foreign exchange rates hurt their profit margins when they imported products such as coffee cups.

    Zhang was a software developer working in investment banking and foreign trading, and he knew technology could be applied to the problem.

    Four years later, the company operates a network that allows SMEs to make easy and affordable payments to more than 130 countries and in 50 currencies.

    Airwallex has 400 employees spread across offices in Hong Kong, London, Melbourne, Shanghai, Shenzhen, San Francisco, Singapore and Tokyo. That headcount includes 50 engineers in Melbourne and 84 in Shanghai.

    “Communications between the two teams is incredibly important,” said Peter O’Donovan, Airwallex engineering lead.

    So the approach has been to treat all of his people as if they were remote workers.

    Tools

    Extensive use of Slack–even when both people are in the same office–keeps everyone in the loop, he explained.

    Similarly, Zoom videoconferencing is used for standups, and physical agile walls are replaced with digital equivalents.

    These tools also allow for the growth of skills across regions, and help ensure everyone is “working to a common pattern.”

    Such shared channels for collaboration and communication help accommodate overlapping working hours (Melbourne and Shanghai are three hours apart when daylight saving is in effect in Australia), as well as the need for engineers to be on call to deal with emergencies.

    This approach puts everyone on a similar footing, whether they work in one of the offices or remotely.

    DevOps leaders need to “focus on building relationships first,” he advised. Frequent video conferences are one way to build bonds with people in different locations. Understanding each others’ mindsets, establishing common ways of working and setting clear expectations are essential, and “doing it from day one is important.”

    Scaling up

    Airwallex plans to double the size of its engineering staff in both cities during 2020. O’Donovan points out that these established standards and practices help with the onboarding process and allow new hires to become productive more quickly.

    That is especially true as the company has selected tools that most people will find familiar: in addition to Slack and Zoom, Airwallex also uses GitHub and G Suite. “These tools are easy to adopt and easy to consume.”

    “Melbourne is a challenging market,” said O’Donovan, because DevOps skills are in demand and Airwallex wants to hire and retain quality talent. But there’s a virtuous circle–helping staff build a strong skill set and surrounding them with other talented people makes it a better place to work, so attraction and retention becomes less of a problem.

    O’Donovan sees DevOps as a key to scaling the company. Having all the teams using the same tools and patterns yields economies of scale by avoiding unnecessary repetition of work, and it allows developers to focus on functionality rather than plumbing.

    Furthermore, regulation and compliance is particularly important in the finance sector, and those considerations need to be built into the processes. “If you can do that seamlessly, you’re doing a good job,” said O’Donovan.

    For example, making vulnerability scanning and the segregation of duties the defaults in the CI/CD pipeline addresses such issues in an automated and auditable manner.

    You need “the right mindset for finance,” he warned. Building in compliance from the start works; trying to add it as an afterthought does not.

    Don’t segregate people, advised O’Donovan, because everyone needs to be working collaboratively toward the same goal. With the right tools and automation, a cross-functional team can deliver better code, faster.

    — Stephen Withers

  • Low-Code Meets DevOps: A Smart Way to Manage Modern App Delivery Demands

    Low-Code Meets DevOps: A Smart Way to Manage Modern App Delivery Demands

    In a fast-moving and often fiercely competitive marketplace, companies need to embrace technology to stay relevant and drive growth. To this end, the business community is increasingly placing a high priority on digital transformation. In fact, more than 80% of organizations believe that digital transformation is crucial to business success.

    Digitally driven processes can power increased business speed and agility, as well as enhance competitive differentiation. Many organizations are now focusing on tools and methodologies that allow them to optimize more processes through accelerated internal application development efforts. Their goal is to be able to create, test and deploy the volume (and variety) of applications required to elevate performance and unlock more opportunities.

    In response to these growing needs for rapid app delivery, DevOps practices are evolving and becoming more critical to the success and agility of a business. According to a study conducted by Verified Market Research, the global DevOps market was valued at $3.62 billion in 2018 and is projected to reach USD 20.01 billion by 2026. Today, many businesses are combining DevOps approaches with low-code or no-code app development platforms, because these solutions provide them with the tools to build applications faster and more efficiently. This strategy helps to alleviate the immense pressures placed on developers today, by streamlining their workloads and responsibilities, while simultaneously enabling them to reduce their development cycle times.

    The Business Benefits of Fast, Agile Application Development

    Due to combining the roles, practices and culture of software developers and ITOps teams, DevOps allows a business to deploy apps more rapidly and with a higher degree of consistency. This is essential in organizations where there’s more pressure than ever before to deliver applications at the speed of internal and external demand.

    Often, the goal of adopting DevOps within a company is to reduce the tedious manual tasks that monopolize developers’ time and lead to app delivery backlogs. Solutions that help lighten and streamline the workload of DevOps–through automation and low-code development environments–are becoming more critical as a growing number of demands are being put on this still somewhat evolving, yet increasingly prioritized, team role and culture.

    Outlined below are a few examples of how low-code app development platforms can enhance the growing role of DevOps and improve the bottom line. This approach helps to:

    • Broaden the app development space to non-technical professionals: As mentioned before, low-code platforms enable a wider pool of less-technical users to work on and improve the speed at which applications can be built. Instead of the traditional app development team being solely responsible for a growing number of application requests, business users are now able to support digital transformation efforts by building and modifying their own processes, without writing complex lines of code.

    This approach makes the process of development more accessible to non-technical professionals. As a result, businesses can liberate their developers from routine coding work and redeploy these highly skilled individuals to more strategic projects that are critical to core business processes.

    • Facilitate faster application building: In addition to making application builds more accessible and less complex, the low-code environment also speeds up the entire development and deployment process. With this approach, companies can reduce development timelines from weeks or months to hours or days. Accelerating this cycle is crucial in any business that aims to outpace competitors.
    • Streamline consistent application deployment: Low-code platforms can integrate into toolchains (or a set of programming tools) that can automate the deployment of applications across various business environments. This ensures that apps created by non-developers can be deployed in the same manner as traditional, developer-based applications. This consistency provides a lower cost of ownership because it allows a low-code platform to more easily integrate into the business processes and workflows the organization already has in place. This minimizes the risk of disruption and irregularities.

    As businesses embrace innovation and elevate performance across the enterprise through agile, accelerated app delivery, the role and function of DevOps will continue to grow in influence and priority. Businesses that strategically leverage low-code solutions in combination with modern DevOps practices are likely to position themselves for growth, competitive differentiation and sustainable business success.

    — Holly Anderson