Category: DevOps Culture

  • New Relic Taps Generative AI to Simplify Observability

    New Relic Taps Generative AI to Simplify Observability

    New Relic has added a tool that takes advantage of generative artificial intelligence (AI) to make it simpler to query the telemetry data collected by its observability platform via a natural language interface (NLI).

    Jemiah Sius, director of developer relations for New Relic, said New Relic Grok will make the New Relic One platform more accessible to a wider range of IT professionals, especially those that haven’t mastered New Relic’s proprietary programming language that enables DevOps teams to identify the root cause of an issue.

    New Relic Grok automatically pinpoints code-level errors in integrated development environments (IDEs) in addition to analyzing code, stack traces and production telemetry to suggest fixes. New Relic is providing this capability via integration with the large language models (LLMs) created by OpenAI, which is providing the foundation for a broad range of generative AI capabilities through Microsoft. New Relic has a long-standing alliance with Microsoft, added Sius.

    Using plain language, anyone can generate a system or app health report complete with anomalies, issues and recent deployments in a way anyone can understand without having to create and filter dashboards, he noted.

    New Relic Grok also makes it simpler to identify instrumentation gaps that can then be addressed using the instructions it provides. It can also set up missing alerts and automate alerts using the open source Terraform infrastructure-as-code (IaC) tool.

    Finally, IT teams can also use New Relic Grok to manage accounts, users and user access, data retention rules, usage, billing and other administrative tasks.

    New Relic previously invested in machine learning algorithms to automate observability tasks. These AI extensions to the New Relic platform are part of a larger effort to extend the reach of the New Relic One observability platform further left toward developers and IT administrators rather than just site reliability engineers (SREs), said Sius.

    However, New Relic doesn’t anticipate that generative AI will eliminate the need for SREs to use its programming tool to solve more complex problems, he added.

    The overall goal is to provide development teams with frictionless access to observability data at every stage of the software development life cycle to reduce mean-time-to-detection (MTTD) and mean-time-to-resolution (MTTR) of issues.

    In general, most organizations are still in the early stages of achieving full-stack observability. A recent New Relic survey found only 27% of respondents have achieved full-stack observability and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found. On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability, and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    AI, of course, promises to improve reliability. At the very least, it could make it easier to identify issues long before a major disruption occurs.

  • Economy Forces Shifts in Tech Talent Hiring

    Economy Forces Shifts in Tech Talent Hiring

    A survey of 418 hiring managers published this week by the Linux Foundation found 59% of respondents changed or revised their technical hiring plans for 2023 because of economic uncertainty. Among those organizations, the primary strategy for addressing these concerns was to freeze hiring (34%), followed by a focus on hiring to address specific skills requirements (32%) and staff reductions (13%).

    Conducted by Linux Foundation Training & Certification and Linux Foundation Research to coincide with the Open Source Summit North America conference, the survey found 30% of respondents worked for organizations that froze hiring, while another 8% reduced headcount. Another 6% opted to do both, the survey found.

    In contrast, a total of 44% said they planned to increase their hiring of technical talent, with another 12% reporting that they would still be hiring even if they had frozen some hiring or reduced headcount.

    The survey revealed that organizations are looking to add technical staff with experience in cloud/container technologies (50%), cybersecurity (50%), artificial intelligence/machine learning (46%), database and data management (37%) and advanced analytics and data science (37%). The most acute need for technical expertise is in the areas of augmented reality/virtual reality, AI/ML, blockchain, continuous integration/continuous delivery (CI/CD) and DevOps and Kubernetes, the report found.

    Anna Hermansen, ecosystem manager for Linux Foundation Research, said in addition to looking to recruit talent, it’s also apparent more organizations are investing in training to fill gaps, with 70% of respondents reporting they invest in training whenever a new technology is introduced. Investments in upskilling often enable organizations to add critical capabilities faster than finding and then vetting potential candidates, she noted. Well over half of respondents (58%) worked for organizations that sought training for their existing employees when they were unable to find suitable technical candidates, the survey found. Only 38% of respondents said they would rely on consultants to fill those gaps.

    Upskilling, however, is not a panacea. While 55% of organizations agreed that upskilling could help, there is often a need to backfill positions and 47% of respondents said upskilling takes too long or is ineffective at training for complex roles.

    In comparison, 48% or respondents said it would take more than three months to fill a technical position, with nearly two-thirds (64%) also noting recruitment is costly and time-consuming and often does not lead to the right candidate. A full 84% agreed there is a need for a streamlined way to recruit new technical staff with proven skills and 64% said that onboarding takes valuable internal resources away from other critical projects for too long.

    The survey also found that 38% of organizations lost up to 10% of their new hires within four to six months, with nearly one out of three new hires, on average, departing within six months of being onboarded.

    There’s no doubt that an uncertain economic outlook is adding more stress to already-flawed recruitment processes. The challenge and the opportunity is determining whether to focus on recruiting top talent versus growing a farm team that will be able to step up to handle more complex tasks. It’s not a question of choosing between those approaches as much as it is striking the right balance between them.

  • Spotify Adds More Plugins for Backstage Developer Portal

    Spotify Adds More Plugins for Backstage Developer Portal

    Spotify this week added additional plugins for its open source Backstage platform that is used to build developer portals. The new plugins make it simpler to address role-based access and access Insights, a tool from Spotify that tracks Backstage usage trends.

    In addition, Spotify is also enhancing a Soundcheck plugin for Backstage that is used to visualize and track development of software components. Forthcoming capabilities include a no-code interface that makes it possible to programmatically create checks of code without writing any code.

    DevOps teams will also be able to view, export and understand how teams and components are doing compared to established best practices and monitor trends, graphs and historical views, and receive notifications when levels change.

    Finally, Spotify is committing to adding additional integrations with third-party tools and platforms such as Snyk, Sonarqube and the open source Argo continuous delivery (CD) platform.

    There are now five plugins available via a Spotify Plugins for Backstage subscription service, and Spotify said more are planned.

    Meg Watson, a group product manager at Spotify, said Backstage has been gaining traction in cloud-native application environments that are especially challenging to develop using multiple tools. Because of Backstage, developers are not only more productive but turnover has also been reduced because developers are provided with a better experience, she noted.

    There’s a lot more focus than ever on developer productivity, which Backstage addresses by creating a catalog of blueprints that developers can readily consume rather than requiring them to build these capabilities themselves multiple times over. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Backstage was donated to the Cloud Native Computing Foundation (CNCF) and is now being advanced by contributions from multiple vendors. Much of that focus is on lowering the barrier of adoption for the platform, said Watson. Specifically, Spotify is working on a QuickStart for Backstage edition of the platform that is simpler to install, she said.

    In general, Spotify is trying to strike a balance between centralizing the management of DevOps workflows and the need to enable developers to define workflows that are natural to them versus ones that have been imposed on them, added Watson.

    It’s not clear to what degree Backstage will help fuel the adoption of a shift toward platform engineering to centralize the management of DevOps tools and platforms. The concept of a portal through which developers can self-service their own needs may not be new, but as an open source project, Backstage has made it simpler for many organizations to achieve that goal.

    Just about every DevOps team is now being asked to find ways to help improve developer productivity at a time when many organizations are trying to do more with fewer resources. Regardless of the motivation, however, it’s apparent that DevOps workflows are continuing to evolve and mature.

    In the meantime, DevOps teams would be well-advised to eliminate as many bottlenecks as possible before they negatively impact developer productivity.

  • GitHub Revamps Search Engine for Code Repository

    GitHub Revamps Search Engine for Code Repository

    GitHub today unveiled a new search engine it has developed to make it simpler and faster to browse and navigate the world’s largest code repository.

    A completely redesigned search interface now provides suggestions, completions and the ability to slice and dice results, while a redesigned code view tool has integrated search, browsing and code navigation.

    Mario Rodriguez, vice president of product for GitHub, said the popular code repository provider decided to create a new search engine to improve developer productivity. There are more than 200 million GitHub repositories that can now be more easily explored, he noted. The updated search engine also makes it much easier to search for specific vulnerabilities that might exist in a codebase, added Rodriguez.

    This latest addition to the GitHub portfolio is part of an ongoing effort to inject more intelligence into software development using tools such as GitHub Copilot that employ generative artificial intelligence (AI) to make developers more productive, he said.

    During uncertain economic times, there’s always going to be more focus on productivity. Organizations of all sizes are reluctant to hire additional full-time developers, so any effort to make existing developers more productive is welcome. The challenge is the DevOps teams that support those developers are now under increased pressure to reduce or eliminate as many bottlenecks as possible. In most instances, that will require increased investments in automation and AI to enable greater amounts of code moving through multiple pipelines to be managed at an unprecedented scale.

    In the meantime, instead of focusing on metrics such as recovery times, DevOps teams might want to focus more on how much they are improving developer productivity. After all, developers are an expensive asset, so in the age of digital business transformation, most business executives are squarely focused on increasing the rate at which applications are being built and deployed. In many cases, the amount of profit and revenue being generated by any business is now a direct reflection of the pace at which quality software is developed and deployed.

    One way or another, a new age of software development is dawning. Most of the innovations being brought forward are focused on issues that impact developers, but it’s only a matter of time before AI is also increasingly applied to DevOps workflows. As more organizations begin to realize how much of a bottleneck manual steps in DevOps processes have become, the willingness to invest in more advanced platforms should increase.

    The challenge, as always, is there are a lot more developers than software engineers, so the immediate focus is on developer productivity. That’s not necessarily a bad thing, but in the absence of any advances on the back end of the software development process, it is likely to aggravate an imbalance that most DevOps teams strive daily to correct.

  • A Supportive Engineering Culture is Key for Recruiting and Productivity

    A Supportive Engineering Culture is Key for Recruiting and Productivity

    Skilled engineers are in high demand, as their ability to build new products quickly is extremely valuable for businesses competing in a tight market. Strong engineering talent allows businesses to increase productivity and meet customer demand faster, which is essential for long-term success. However, in the current economic context, companies are being forced to reduce spending while trying to achieve the same results. This means engineers have fewer resources available to achieve their goals–increasing the pressure on their role. At the same time, engineering talent remains a valuable asset; in the UK, for example, just under half (49%) of engineering businesses struggle to find workers with a sufficient skillset for the job.

    So, businesses must find a way to attract and retain talented developers while ensuring they feel supported through challenging times. A vital step to achieving this is creating a workplace culture that promotes developer satisfaction. Below, I explore how businesses can create a positive working environment for engineers, make transparent decisions and ensure their teams feel supported – to create a culture where developers want to stay and supercharge business performance.

    The Key Pillars to Creating a Positive Culture

    Leaders of all stripes are tasked with ensuring that their employees are supported, engaged and motivated to do their best work. However, the route to achieving these outcomes can sometimes seem vague and elusive.

    Research shows that there are several key pillars for creating a strong organizational culture. The first is psychological safety. Developers must have the freedom to take risks without the fear of being criticized. Software engineering is an industry in which professionals must be creative enough to be able to create something out of nothing, so it’s important that companies ensure developers have the space they need to experiment and try new approaches.

    Secondly, dependability is essential. Developers are more likely to produce high-quality work in a timely manner if their employer believes in them and their abilities. Developers often face immense pressure to ship functional code on a daily basis; feeling trusted can give them the confidence they need to take on more responsibility and drive projects forward. Alongside this, it’s the leader’s role to ensure developers have a very clear and structured mission. They must know exactly the goals they’re aiming to achieve, the part they’re playing in reaching these goals and the plan for execution.

    Finally, ensuring developers understand the meaning of their work and are fully aware of the impact it has is an important pillar for cultural success. Sometimes, software engineers spend a huge amount of time on small fixes and updates that may seem insignificant. Business leaders must make efforts to communicate the importance of developers’ work and the value they bring to the business. If developers feel valued and rewarded for their difficult work, they will be more motivated to commit themselves to their mission and stay at the organization.

    When engineering teams are happy and supported, they are also more likely to speak highly of their organization and encourage other developers to join the team, helping the company build a strong pipeline of engineering talent.

    Making Transparent Decisions Using Concrete Data

    Transparency is another crucial element to ensure engineering teams are happy and motivated to do their best work. Developers can’t do their jobs effectively if they don’t have insight into the workflows on their teams or don’t have context into decisions that impact their ability to perform effectively.

    With tools such as software delivery intelligence platforms, developers can see the positive impact of their contributions and how they’re helping the business succeed. These tools also enable engineering managers to rely on concrete data to celebrate developer progress on previously invisible work and show how their work contributes to wider business success. This helps developers gain more autonomy to achieve the company’s goals, and eventually create better business outcomes.

    For example, Manulife adopted an engineering analytics tool to create an engineering culture that is based on trust and transparency. The concrete data generated is used to analyze engineering processes and highlight talent that may have remained hidden without a data-driven approach. Data also helps managers decide who within the team deserves to be promoted based on precise insights into everyone’s contribution.

    Use Data to Help Overcome Complex Challenges

    The mission of developers is constantly evolving, with new technologies, programming languages and methodologies changing very quickly and making the job more complex over time. It is up to engineering leaders to help their teams remove potential barriers that are blocking them from being successful in their roles.

    With data-driven insights, engineering leaders can better support and uplift their teams. Data about engineering workflows allows leaders to understand exactly where bottlenecks exist and remove them quickly before slowing their projects down. This means that employees can learn what worked–or didn’t work–from one project to the next, as well as develop the necessary skills to remove roadblocks to future success.

    Timelines and targets for projects set by business leaders can also then be tailored to each person’s abilities and based on concrete data that show where they can boost efficiency to ensure everyone produces their best quality work and remains engaged and motivated.

    In the current technology industry, employee culture is one big factor determining where developers wish to work. In a context where engineering talent is in high demand, it’s the job of every organization to create a stellar work culture to attract and retain talent.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Northwestern Mutual
    Milwaukee, Wisconsin
    Assistant Director for Product Management for Cloud and DevOps Platforms
    $139,300 to $186,200

    CareerBuilder.com

    Brown Brothers Harriman
    New York, New York
    DevOps Operations Manager
    $130,000 to $190,000

    SimplyHired.com

    Spiff
    Salt Lake City, Utah
    DevOps Engineer
    $120,000 to $170,000

    Indeed.com

    Rose International
    Jefferson City, Missouri
    Azure DevOps Architect
    $114,000 to $145,000

    Dice.com

    ComTec Information Systems
    Remote
    DevOps Engineer
    $100,000 to $150,000

  • How LinkedIn is Investing in Developer Productivity and Satisfaction

    How LinkedIn is Investing in Developer Productivity and Satisfaction

    More and more companies are beginning to examine the role developer experience has in improving engineering productivity and morale. And one company often referenced as a model for developer productivity engineering is LinkedIn—its engineering leadership has invested heavily into reducing time-consuming developer tasks and constructing an internal platform to gauge developer satisfaction on the tools they use.

    Engineers at LinkedIn recently shared how the company has invested in measuring developer productivity and happiness as well as their strategies for automatically cherry-picking commits. I also met with LinkedIn engineering leadership for a closer look at how the organization is working to improve the developer experience across its internal platform.

    Below, we’ll take an inside look at LinkedIn Engineering’s efforts to enhance developer happiness. We’ll explore their approach to improving their internal software development trends and consider the benefits LinkedIn has gained throughout the process.

    A Look at LinkedIn Internal Developer Solutions

    Productivity is challenging to measure, said Jared Green, VP of engineering, head of developer productivity and happiness at LinkedIn. So, the company opted to take a different approach by including happiness as a variable in the equation. Thus, they measure not only how fast a workflow is but continually monitor how enjoyable the process is to ensure developers have a delightful experience.

    “We don’t just strive for productivity, but for productivity and happiness,” said Green. And to his point, on-the-job satisfaction can have real-world results—on average, happy workers are 13% more productive, according to a University of Oxford study.

    LinkedIn now oversees a custom-built internal platform for evaluating the sentiment of developer tools. The platform, known as iHub, is a holistic listening channel to gauge developer satisfaction across various tools. It collects real-time qualitative feedback from users and correlates it with objective quantitative telemetry. It then surfaces this data in a UI dashboard for team leads and individual contributors to view.

    But there’s an art to engendering the trust required to collect accurate feedback, says Max Kanat-Alexander, principal staff software engineer at LinkedIn. For example, individual contributors need to be sure the data won’t be used for performance reviews. Once that trust is established, folks are more willing to give genuine feedback, he said.

    Benefits of Investing in Developer Enablement

    The benefit of centralizing developer experience metrics with a shared platform means that tech leads can make data-backed decisions on how to improve their DevOps processes. “It’s really about thinking about giving people insights versus giving them data,” said Green. The idea is that frontline engineers can rapidly investigate any metric to expose problems and see trends. “The optics have given leaders ways to improve various parts of developer experience,” he said.

    Through their investment into developer experience, LinkedIn Engineering has discovered and streamlined hangups in the Git flow, exposed inefficiencies in their code review processes, and fixed specific developer build times. LinkedIn Engineering reported it has reduced time spent on certain time-consuming developer tasks by 99.6%.

    To construct iHub, LinkedIn Engineering wrote its own front end. The hub pre-computes data dimensions and stores them in an offline data store, increasing speed, said Kanat-Alexander. The system uses a sophisticated survey technology to collect the data and hides the complexity of manual collection in a sleek dashboard.

    LinkedIn managers have already leveraged iHub data to identify macro trends and resolve specific points of friction. For example, Kanat-Alexander describes how one director noticed that developer build time was worsening in their organization. They were able to isolate it to a single developer who wasn’t using remote development, which was spiking the metric. Leaders then assisted in unblocking them.

    Takeaways For Your Organization

    Most companies could benefit from a UI like iHub, explained Kanat-Alexander. But, you really must have a large engineering organization to see the benefits of the work. Plus, up to 80% of the legwork is simply data integrations—this involves hooking into systems, cleaning up data and deciding how to measure certain metrics. “Whatever you can measure, you can improve,” said Green.

    LinkedIn Engineering has flirted with the idea of open sourcing iHub, but it’s a bit too custom to LinkedIn to be valuable to other enterprises. “There’s a lot of variance in build technologies nowadays, and large-scale engineering systems are bespoke,” said Green. Implementing such a dashboard also requires a deep understanding of developer personas and how people work, which can be entirely unique for each organization.

    Although other organizations can’t fork LinkedIn’s efforts, there are some takeaways that could help others invest in their internal DX. First, Green recommended starting with the fundamentals. “Having a core of understanding about what you’re trying to move the needle on is important, as is coming up with ways to talk about it consistently.” This forethought should help establish what you want to measure.

    Turning DX Metrics Into Action

    Studies indicate that more companies are seeking to implement platform engineering or similar developer productivity engineering initiatives. The end result of these efforts should be to empower people and ensure they are satisfied with their work and not just a cog in the system.

    On that note, it’s critical that there are mechanisms for action to happen on the data that is collected, said Kanat-Alexander. Someone needs to monitor the insights and make changes to improve the metrics over time. “Then you can win hearts and minds.”

  • FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The Passkeys authentication standard gets a huge boost, and IBM’s Arvind Krishna wants workers back in the office. (more…)

  • How DevSecOps Addresses Supply Chain Security

    How DevSecOps Addresses Supply Chain Security

    “The absence of security in the initial stages of system engineering is the single most significant cybersecurity gap and risk in modern system development.” This quote from tech entrepreneur Linda Rawson is a good reminder for the current cybersecurity threat situation. With software supply chain attacks increasing in aggressiveness and sophistication, organizations need to understand that cybersecurity should no longer be an additional process, let alone an afterthought.

    Integrating security in the software development process provides a few other benefits, including better efficiency and customer satisfaction. However, its most notable benefit is addressing cybersecurity threats more effectively compared to the conventional ways of enabling software security.

    The Rise of DevSecOps

    DevSecOps is a fast-rising star in today’s search for effective cybersecurity solutions. The DevSecOps market is expected to be worth $23.63 billion in 2030, growing at a CAGR of 23.84% in the forecast period 2023-2030. Its value in 2022 was estimated at around $4.27 billion.

    This double-digit growth is actually a bit conservative. Other forecasts showed higher CAGRs in the 30% range. This growth hints at the strong demand for DevSecOps solutions. Many organizations have started to acknowledge the benefits of implementing security validation methods early in the software development life cycle (SDLC) instead of doing them in bulk as a separate phase at the end of the development process.

    Many organizations are now convinced that they can benefit from shifting left or bringing security into the SDLC earlier. Tools and solutions like static code analysis (SCA), automated dynamic analysis, interactive application security testing (IAST) and source composition analysis address security weaknesses before an application is released to the market. This allows organizations to release apps faster and, because of the elimination of most bugs and vulnerabilities, provide considerably better user experiences.

    Vulnerabilities will never be completely eliminated, but they can be significantly reduced and more properly resolved while software is being developed if security validation is integrated in the development process. Some software defects and weaknesses tend to be more difficult to address through a separate security testing process, since it would entail a broader code tracing or review as opposed to quickly spotting the affected code when security validation is done alongside the development process.

    Addressing Software Supply Chain Attacks

    So, how does DevSecOps help prevent supply chain attacks? The key is in the visibility and control DevSecOps affords.

    DevSecOps requires vigilance of security issues throughout the software development process. Security is not relegated to a different team that doesn’t understand the specifics of a development project. As such, the team has broad visibility over security concerns. Because the DevSecOps team also has mastery of the code being developed, it is easy to trace the origin of vulnerabilities and implement the necessary corrections.

    DevSecOps is aided by automated tools that scan code for security issues and detect threats even before they manifest themselves as problems. These tools are used across all phases of the development process, from the time code bears basic features and functions to deployment and post-production.

    Static testing: Even before an application’s code is ready to run, it can be subjected to static testing to find vulnerabilities. Tools such as static application security testing (SAST) can analyze code and detect possible security problems.

    How does this address software supply chain attacks? Static testing can be overlaid on automated CI/CD pipelines to stop code that has security weaknesses from getting committed to the codebase.

    Dynamic testing: An automated dynamic analysis can be used for code that is already executable. This is done through dynamic application security testing (DAST) tools, which are capable of detecting vulnerabilities usually invisible to SAST but which are detectable once the code is running.

    How does this address software supply chain attacks? Organizations can implement automated black-box testing for apps in the CI/CD pipeline(s) to detect security flaws for apps that are already executable. This addresses the vulnerabilities that have not been detected by static testing while reducing the costs associated with the corresponding remediation.

    Interactive app testing: This is a combination of static and dynamic testing. It employs IAST tools which run static testing on available code and come up with bespoke dynamic tests for a specific app to identify issues more thoroughly.

    How does this address software supply chain attacks? Pure static and dynamic testing usually apply to earlier stages of the development process, whereas interactive testing addresses vulnerabilities that emerge in the later parts. By bringing IAST to the CI/CD pipeline, organizations achieve better security issue detection outcomes, which means the prevention of malicious code deployment.

    Supply chain analysis: This entails the use of tools that specifically examine the security of third-party libraries and dependencies. To be clear, this is not the only method for addressing software supply chain vulnerabilities. In this case, supply chain merely refers to the external libraries, dependencies and other components that do not originate from the development team.

    How does this address software supply chain attacks? Integrating software chain analysis tools in the CI/CD pipeline significantly reduces the adverse effects of vulnerabilities in dependencies and other components on a project’s codebase as well as on the development process itself.

    Security-as-Code

    One of the best practices developed in line with the integration of security in the software development process is the idea of implementing security-as-code. This means that security policies and measures such as testing and validation are turned into code whenever possible. In other words, the code itself already bears security mechanisms. Security testing runs automatically whenever code is committed. This ensures robust, consistent, highly scalable security that does not rely on external rules and mechanisms to prevent the introduction of anomalous code or malicious inputs.

    Security-as-code also means that the DevSecOps team can see how modifications to code and the underlying infrastructure are created. The team can map out the impact of code changes and identify the areas where security tests and regulations can be implemented to optimize processes and avoid unnecessary delays.

    Security-as-code is essentially the automation of security practices. It is not applicable in all instances, though, so it is still important to be knowledgeable about security testing methods that can be used in different stages of the development process.

    Securing the Software Supply Chain

    The SUNBURST incident and other similar high-profile attacks should serve as a warning for all organizations to ascertain the security of their software supply chain. DevSecOps is one of the best solutions right now. It does not guarantee the complete elimination of all threats, but it ensures that if threat actors succeed in getting around security controls, a breach won’t go unnoticed.

     

  • Breaking Down Silos: Applying Open Source Practices in the Workplace

    Breaking Down Silos: Applying Open Source Practices in the Workplace

    DevOps plays a prominent role in mainstream technology and companies’ ability to deliver results. While the definition of DevOps encompasses the complete range of characteristics it covers, in practice, current tech culture tends to focus solely on the tooling aspect, neglecting the equally essential focus on the people and process critical in delivering value to end users. While cultures are difficult to change and redefine, a transformation is needed to fully capitalize on the potential DevOps has to accelerate software development.

    Conway’s law–the concept that organizations ship software based on their organizational structure–outlines the need for visibility. This law revolves around the idea that in order for a software product to successfully operate, its developers must have established open pathways of communication to ensure each component works as a whole rather than as individual pieces. Unfortunately, today, many organizations still run into problems with how their teams operate when individuals own limited pieces of development.

    Take a retail platform, for example. In the development of the platform, there will likely be several sub-teams that focus on individual components of the design. Perhaps there’s a team for the shopping cart service, another for the catalog service, a team for the underlying data platform and one for user account services. The list goes on. Typically, those teams do not have visibility into each other’s work and operate in their own silo. As soon as teams start thinking about ‘their’ component or ‘their’ microservice, a dangerous tunnel-vision takes hold. In some cases, there may be standup meetings across teams for coordination efforts, but this takes time, energy and steals focus from the important task: Delivering value to end users.

    Alternatively, think about your favorite open source project. The inner workings were likely  designed asynchronously, openly, remotely and at a global scale. Given the remote nature of open source innovation, developer teams don’t need to be co-located in the same workspace. While physically operating separately, open source developers have mastered alternative methods to operate with transparency in such a way that external contributions aren’t just welcome, but encouraged.

    This same idea applies to proprietary software development, or InnerSource, a modern engineering approach that applies open source practices inside your organization to proprietary code. While a technological shift in practice, InnerSourcing is also a cultural revolution toward collaboration.

    Companies of all types can benefit from implementing InnerSource practices. Some enterprise organizations that operate using InnerSource methodologies today include 3M, Ford, KPMG, Mercedes-Benz, Nubank, Spotify and more.    

    A critical component in making this change is prioritizing team visibility. If other teams in your organization are unable to see what you’re working on, you’re inherently (intentionally or not) creating silos and limiting efficient collaboration. In practice, there will be scenarios where company-wide visibility may not be feasible due to external regulations, highly secure environments or sensitive projects; however, these moments of limited project visibility should be the exception rather than the default.

    When approaching InnerSource through an open source mindset, you will find that many DevOps principles still hold true. Here are a few strategies for implementing a collaborative open source culture when developing proprietary code:

    1. Use existing resources: When problem solving, using the existing materials available within your organization is a great place to start—it is possible someone has already tackled the issue you are addressing. If you find the right fit, you can reuse prior work and, if it has not been started, this is an opportunity to add value to your organization by creating a project that could help others in the future. When building upon someone’s work or starting a project, prioritizing visibility by providing an explanation of any technical requirements of the change will allow future project maintainers to determine whether it’s in the project scope, already a proposed change, on the backlog, or not a prioritized piece of work. This use of existing resources will help develop a collaborative culture over time.
    2. Documentation of work: Documentation is critical. Keeping track of the expected standards of the project and which tools or dependencies are required to build the project for local testing will help others in your organization know what to contribute. When in the early stages of contributing code to a project, documenting proposed changes without directly impacting the production version will allow you to receive feedback early on from the project maintainer about the direction you should take as they will be able to see your steps clearly outlined. To contribute code to a project, you can propose changes as a pull request, which doesn’t impact the production version but means you can get valuable feedback on the direction the project should take. Handling contributions by a pull request also ensures that branch protection rules apply and continuous integration practices are required.

    While implementing these practices may not result in immediate changes, over time they will result in a significant cultural shift. And while cultural transformations require continued conscious efforts, embracing modern software engineering practices–learned from the open source community–will enable teams to break barriers for organizational collaboration.