Category: Features

  • 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

  • ReversingLabs: Increased Focus on Software Supply Chain Security

    ReversingLabs: Increased Focus on Software Supply Chain Security

    A global survey of 300 global executives, technology and security professionals found software containing vulnerabilities (82%) followed by secrets leaked through source code (55%), malicious code (52%) and suspicious code (46%) posed a serious risk to the business.

    Conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for securing software supply chains, the survey found 87% of respondents detected significant risks in their software supply chain in the last year. Nearly three-quarters (74%) said legacy application security tools, including static application security testing (SAST) (54%), dynamic application security testing (DAST) (42%) and software composition analysis (SCA) (40%), are ineffective against threats to modern software supply chains.

    A full 88% said software supply chain security is an enterprise-wide risk, but only 60% said their software supply chain defenses were up to the task. Nearly two-thirds (65%), however, acknowledged their organization’s software supply chain security program wasn’t as mature as it should be. As a result, 80% are currently focused on improving security for the software supply chain, with 96% noting a more comprehensive approach to software supply chain security that detects more than vulnerabilities is needed.

    Overall, the survey found nearly all respondents (98%) recognized that software supply chain issues pose a significant business risk. Nearly 90% reported detecting security or other issues in their software supply chain in the last 12 months. Those issues stemmed from internally developed software (47%) as much as open source software (49%), followed by commercial software (30%), the survey finds.

    Tyson Whitten, vice president of global marketing for ReversingLabs, said the survey results make it clear that software supply chain issues extend well beyond open source software dependencies. Use of open source software has expanded greatly over the last decade, but security flaws in software are pervasive, he noted.

    In addition, many of these issues stemmed from software created by contractors and third-party companies, added Whitten. More than half of respondents worked for organizations that use contractors (67%) and third-party development companies (59%) and many organizations don’t have the tools required to review applications before they are deployed in a production environment.

    Software supply chain security has become a major issue in the wake of a series of high-profile breaches. The challenge is shortage of cybersecurity expertise available to secure those supply chains. Usually, someone on the DevOps team needs to emerge as a security champion for the good of the larger application development team. Unfortunately, most developers have had limited exposure to cybersecurity training, so it can take a significant amount of time for those champions to emerge.

    In the meantime, it’s less clear whether organizations will upgrade their DevOps environments to make them more secure, but it’s clear they will soon be held more accountable for application security. Governments around the world are currently drafting legislation that would impose penalties should it be determined an organization recklessly built and deployed software. Once that legislation is passed, it may only be a matter of time before the pressure on organizations to adopt DevSecOps workflows increases. The issue is determining how quickly to get in front of that issue before a potential legal quagmire ensues.

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

  • Survey: Much Greater Focus on Reining in IT Costs

    Survey: Much Greater Focus on Reining in IT Costs

    A survey from Vega Cloud found 62% of respondents are more closely monitoring all IT costs, with more than half (52%) more closely evaluating their cloud service provider options.

    The survey polled 100 vice presidents from organizations with more than 1,000 employees and was published today by Vega Cloud, a provider of a platform for managing multiple clouds.

    Overall, nearly half of respondents (48%) said they expected to reduce their IT spending a little or a lot in 2023, with 65% identifying the reduction of cloud spending as a specific goal. Three quarters (75%) are looking to cut cloud costs by 10-50% in 2023, the survey found.

    A full 93% reported they have invested at least a fair amount of money on tools to optimize cloud costs, with 82% having invested in FinOps staff or people with FinOps experience. The challenge is that 70% of respondents said it was difficult to find people with these skill sets, the survey found.

    The best way for organizations to reduce cloud costs is to become more informed about what they’re spending (40%), and 33% said that the best approach is to consistently optimize use of cloud resources. A total of 61% identified reserved instances/savings plans as the best way to optimize cloud use, while 55% said optimization was best achieved through waste elimination followed closely by right-sizing (54%).

    Vega Cloud CEO Kris Bliesner said it’s clear the days when organizations allowed developers to consume cloud resources at will are coming to an end as cloud services consume a much larger percentage of the IT budget. In fact, the survey noted that 91% of respondents are spending at least one million dollars annually on cloud infrastructure alone.

    The issue is that finance departments not only want to reduce cloud spend but also want cloud spending to become more predictable from a budget perspective. Nearly half of survey respondents (45%) said they’d received a surprise in their cloud bills “a number of times” over the past 12 months, with 70% of respondents noting surprises have happened at least a half dozen times in the past year.

    A total of 40% admitted they had exceeded budgets multiple times in the past year, and 38% said they had to modify their forecast cloud spending budget numerous times over the past 12 months. More than half of respondents (55%) said database costs are the metric that matters most when looking at cloud usage followed by bandwidth costs (51%), storage costs (49%) and compute costs (47%). Nearly two-thirds (64%) said they track metrics at least somewhat often, while 46% said they have somewhat optimized their cloud use. A total of 11% said they’re not optimized at all.

    A full 88% said they’re using artificial intelligence (AI) at least somewhat to optimize cloud use and costs, with nearly three-quarters (74%) noting they think ChatGPT or a similar generative AI tool could be used to optimize cloud use/costs further. Specifically, 42% said they thought it could improve decision making and 30% said it could automate decision making.

    Among the cloud service providers, Google is cited as doing the most to help customers manage and reduce cloud costs (38%), followed by Amazon Web Services (34%) and Microsoft (28%)—but a full 85% said they could all be doing more.

    Of course, changing economic conditions are naturally driving organizations to look harder at cloud spending. Well over half of respondents (56%) said they are concerned about the economy, and 95% of those respondents said those concerns have, at least somewhat, impacted their IT strategy.

    It’s not clear whether organizations will continue to exercise greater control over cloud spending should the economy recover. For now, at least, there’s clearly more desire for control than ever.

  • 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…)

  • mabl Adds Load Testing Tool to Test Automation Suite

    mabl Adds Load Testing Tool to Test Automation Suite

    mabl today added a load testing capability to its portfolio of application testing tools that it makes available via a software-as-a-service (SaaS) platform.

    That capability promises to make it simpler to streamline testing within a DevOps workflow by making available load testing tools that measure application peformance alongside existing mabl tools accessible via a test automation platform.

    Dan Belcher, mabl CEO, said the goal is to make it simpler for developers to run functional and non-functional tests as early as possible within the software development life cycle.

    It’s not clear how much responsibility for testing is shifting left toward developers, but as it becomes simpler to run these tests it is more likely they will be run, noted Belcher. One of the core issues that plagues application development today is the inadequate level of testing. That issue is largely because it takes too much time to create and run relevant tests, he added.

    mabl streamlines that process using a test automation platform based on a low-code tool that makes it simpler to create and manage the testing process. Those tests can be configured to run independently or be integrated with a DevOps pipeline, noted Belcher.

    Shifting testing further left toward developers doesn’t eliminate the need for a dedicated team of testers, but it should reduce the number of routine errors being made. That reduction should free those development teams to focus more of their time and effort on more complex quality assurance (QA) issues, said Belcher.

    Of course, more testing processes will become automated as artificial intelligence (AI) continues to evolve, so most organizations will soon find themselves revamping those processes. In theory, SaaS platforms that aggregate testing data should be in a better position to apply AI models to testing. That’s critical because the pace at which even more complex applications are being built and deployed shows no sign of slowing down.

    In the meantime, DevOps teams should assume they will soon be held more accountable for security issues that arise after an application is deployed. It may be a while, but the number of legislative initiatives focused specifically on application security has increased; it’s only a matter of time before laws that hold organizations liable for security are going to be passed. At the same time, the level of tolerance application software consumers have for issues that arise because some trivial mistake led to, for example, a SQL injection attack, is dropping. The expectation is that application testing is soon going to be a lot more thorough than it has historically been.

    The issue, of course, is that too many development teams tend to view security requirements as obstacles to be overcome rather than as intrinsic elements of the QA process that is supposed to ensure expectations are consistently met and exceeded.

    At this juncture it’s clear that application testing is going to improve. The only thing left to determine now is how much friction will be experienced on the way to achieving that goal.

  • Honeycomb Taps ChatGPT to Simplify Observability

    Honeycomb Taps ChatGPT to Simplify Observability

    Honeycomb today added a Query Assistant to its observability platform that uses OpenAI’s ChatGPT generative artificial intelligence (AI) platform to launch queries via a natural language interface rather than having to master a query language.

    That capability complements an existing tool based on machine learning algorithms, dubbed BubbleUP, that DevOps teams already use to debug code.

    Honeycomb CTO Charity Majors said both tools make the Honeycomb observability platform more accessible to IT teams that are tasked with managing complex application environments. Those teams are not going to be able to accomplish that goal without relying more heavily on AI to determine the root causes of an issue.

    Generative AI augments DevOps teams by making it possible to build a relevant, modifiable query that they can continuously iterate as IT staff investigate an issue. This approach means teams don’t necessarily need a deep understanding of code behavior and the underlying infrastructure it depends on, noted Majors.

    That’s critical, because not every IT professional immediately knows what query to launch. One of the challenges with adopting any observability platform is they require a a DevOps team member to frame a query to generate a result. If multiple queries are required, coding them in a query language becomes a cumbersome task.

    As AI continues to improve, algorithms should be able to automatically surface more issues. But given all the dependencies that exist in modern application environments, there will still be a need for a DevOps specialist to ensure application availability and optimize performance, at least for the foreseeable future.

    In general, generative AI represents a significant leap forward compared to AI for IT operations (AIOps) platforms that, in comparison, are not nearly as useful, noted Majors.

    It’s still early days as far as measuring the impact AI will have on DevOps workflows. But the AI genie is already out of the proverbial bottle. Many of the low-level tasks that tend to make DevOps jobs tedious will soon be automated. As a result, job roles within DevOps teams will need to evolve.

    Less clear is what impact the rise of generative AI might have on the adoption of observability platforms. While there is no shortage of observability platforms, adoption has been limited by the number of DevOps professionals that could master a specific query language created for that observability platform. The ability to rely on a natural language interface instead reduces the need to use a proprietary query tool.

    In the longer term, the simpler it becomes to use DevOps best practices, the more widely they will be adopted. AI platforms should enable more organizations to embrace DevOps in a way that reduces the level of cognitive load currently required.

    In the meantime, there’s no doubt that current DevOps professionals are cautiously watching the rise of generative AI, much like everyone else. The difference is that most DevOps professionals are not going to want to work for organizations that don’t provide access to AI-infused tools and platforms that make their jobs easier.

  • DevOps Onramp: Security on the Rise

    DevOps Onramp: Security on the Rise

    I don’t normally advertise stuff in my blog, because that’s not what it is here for. It is here to offer you the thoughts and ponderings of someone like you, and advice you didn’t ask for. But today we’ll make an exception since I also blathered for Techstrong Group recently, and soon you’ll be able to hear it.

    If you are not familiar with it, DevOps Onramp is this week, and you can go and register to hear my session and the sessions of other great voices that are involved in DevOps. My session is about DevOps and Security, but there are a wide variety of sessions for you to choose from.

    I am trying to make the time to be involved in the conversation when my session airs, and it looks like my schedule will allow it, so if you are interested in DevOps security, I’ll likely be around to discuss it with you.

    I can’t speak for all of the sessions, but mine starts with the basics for newcomers and then covers more advanced topics as it goes on. The truth is that I was supposed to do two sessions–intro and advanced, but I started talking too fast, and the next thing you know, I crammed it all into one session, saving you time for some of the other great content that is available at the show.

    So (virtually) drop by, watch my session, see what else you’re interested in, and feel free to drop any of us presenters a line telling us what you think, good and bad. I’m sure the show organizers would be happy to receive feedback too, but I’m all about presenters.

    And keep rocking it. We’ll be back next week with our regular content (and no ads).

  • GitLab Allies With Google to Bring AI to DevOps

    GitLab Allies With Google to Bring AI to DevOps

    GitLab extended its alliance with Google as part of an effort to bring more generative artificial intelligence (AI) capabilities to DevOps workflows.

    The GitLab suite of software-as-a-service (SaaS) applications already reside on the Google cloud platform to provide GitLab with the foundation of data required to train those AI models. Over the course of the last two months, GitLab has already added numerous capabilities that rely on multiple types of AI technologies.

    For example, there is now an experimental Explain This Vulnerability capability that provides a natural language summary of an issue in a way developers and cybersecurity teams can easily comprehend.

    Taylor McCaslin, a product group manager for data science and AI/machine learning for GitLab, said going forward, most of the AI focus is going to be on leveraging generative AI capabilities. Those capability will be enabled by Google using a large language model (LLM) that GitLab developed for DevOps workflows. That approach enables GitLab to surface more accurate recommendations based on validated data compared to the general purpose LLM that was used to create the ChatGPT service.

    In addition, GitLab can continuously update the AI models it is running on the Google Vertex AI cloud service using the data from its SaaS application environment which is continuously monitored and updated, McCaslin noted.

    It’s not clear what impact AI may have DevOps workflows, but GitLab is forecasting a 10x improvement. That will be accomplished by, for example, surfacing code that can be used to remediate a vulnerability. Today, many vulnerabilities are not addressed simply because developers don’t have enough time to write a patch.

    A recent GitLab survey, however, suggested developers are already embracing AI to improve productivity, with 62% of developers using AI and machine learning algorithms to check code. More than a third (36%) also rely on AI and machine learning algorithms to review code.

    At this juncture, the one thing that is certain is AI and other associated technologies are going to make developers more productive. It’s not nearly as apparent what impact increased amounts of code moving simultaneously through DevOps pipelines is going to have on the software engineers that manage those processes. The expectation is that similar types of AI advances will also enable more code to flow through those pipelines without, hopefully, further exacerbating any existing bottlenecks that might exist.

    In the meantime, it’s clear the AI genie is out of the bottle. There will soon be more LLMs for all kinds of tasks. DevOps teams should start planning today based on the assumption that many manual tasks that conspire to make software engineering tedious are going to fade away. As such, the roles with a DevOps team are going to change and evolve. The assumption those DevOps teams should make is that these changes will be for the better. After all, the reason organizations embraced DevOps in the first place was to ruthlessly automate IT processes—AI is simply the latest iteration of that commitment.

  • Survey: Most Open Source Software Maintainers Want to Get Paid

    Survey: Most Open Source Software Maintainers Want to Get Paid

    A survey of 339 maintainers of open source software projects found 60% of them classified themselves as unpaid hobbyists versus only 13% who said they earn most or all of their income from maintaining projects. Slightly less than a quarter (23%) described themselves as semi-professionals, earning some of their income from maintaining projects. Overall, more than three-quarters of unpaid maintainers (77%) would prefer to be paid for their efforts.

    The survey was conducted by Tidelift, a provider of a platform for managing open source software use, and found there is a clear correlation between getting paid and the amount of time spent actually maintaining a project. A full 81% of professional maintainers spend more than 20 hours per week maintaining their projects, compared to 27% of semi-professional maintainers and only 7% of unpaid hobbyist maintainers, the survey finds.

    In fact, paid maintainers are much more likely to have reproducible and verifiable build processes (77%), formal backward compatibility policy (71%), a security disclosure plan (69%), provide fixes and recommendations for vulnerabilities (69%) and have a defined dependency management process (57%).

    Unfortunately, the survey also made it clear that more than half of maintainers of open source software projects (52%) are not even aware of emerging frameworks to better secure software.

    On the plus side, however, the survey also found that among maintainers that are aware of those frameworks 43% have already begun work to align with them or plan to start within the next year. Alas, 39% said they have no plans to align to these industry standards, while another 19% are still on the fence. Well over one-third of maintainers (38%) who do not plan to align their projects with industry standards said they just don’t have the time, while 37% won’t do it because they are not being paid for the work.

    Nearly half of maintainers (47%) want to be paid for undertaking the work needed to align their projects with the security frameworks, with 54% of maintainers noting they would appreciate help that would enable them to better understand these frameworks and how they apply to their project.

    Tidelift CEO Donald Fischer said as more organizations are concerned about the security of the open source software used across software supply chains, the survey makes it clear that maintainers need some sort of financial compensation to make it worth their time and effort to address vulnerabilities in a timely manner. That’s especially critical, especially as legislation is pending that would hold software developers more liable for vulnerabilities in software. In the absence of being paid to more proactively address vulnerabilities, many open source software maintainers may abandon projects altogether because of liability concerns.

    It’s not clear to how enterprise IT organizations are evaluating which open source projects developers can use based on the level of support made available. What is clear is that not all open source software is created and supported equally well. Of course, many of the organizations benefitting from open source software could be doing a lot more—not just in terms of financial support, but also helping with everything from identifying vulnerabilities and testing patches to simply writing better documentation.