devopsy.kinsta.cloud

Category: News

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

    Dice.com

    ERP International
    Fort Meade, Maryland
    Senior DevOps Infrastructure Engineer
    $150,000 to $180,000

    LinkedIn

    Lark Health
    Remote
    Lead DevOps Engineer
    $127,700 to $183,900

    Simply Hired

    Shake Shack
    Remote
    Senior DevOps Engineer
    $123,000 to $155,000

    Indeed.com

    Peraton
    Arlington, Virginia
    DevSecOps Data Automation Engineer
    $112,000 to $179,000

    CareerBuilder.com

    Booz Allen Hamilton
    Fort Meade, Maryland
    DevOps Engineer and Release Manager
    $73,100 to $166,000

  • Google Previews Generative AI Service to Improve Code

    Google Previews Generative AI Service to Improve Code

    Google is previewing an instance of a generative artificial intelligence (AI) service that surfaces code recommendations to make it possible to build high-quality applications faster.

    Specifically, Duet AI for Google Cloud surfaces code recommendations in real-time, generates full functions and code blocks and suggests fixes for vulnerabilities and errors in the code that it discovers. It also promises to enable DevOps teams to create custom large language models (LLM) based on their own code. In fact, GitLab and Tabnine are, respectively, already integrating LLMs running on Google Cloud with their continuous integration/continuous delivery (CI/CD) platform and testing tools.

    Chen Goldberg, vice president of engineering for Google, told attendees at the Google I/O 2023 conference that Duet AI for Google Cloud will fundamentally change how developers will be able to build applications, regardless of their skill level.

    Duet AI for Google Cloud was trained using data collected from Google Cloud using sample code and documentation to fine-tune behaviors and patterns.

    Duet AI for Google Cloud is available under an AI Trusted Tester Program and provides developers with many of the same capabilities that can be found in the GitHub Copilot tool that is based on the LLMs created by OpenAI.

    In addition to making Duet AI for Google Cloud accessible via both its tools and managed services, Google said it also plans to integrate the service with multiple integrated development environments (IDEs).

    It’s still early days as far as the use of generative AI within DevOps workflows is concerned, but it’s clear that the amount of code being created by developers is about to increase exponentially. Hopefully, AI technologies will also one day help software engineers find ways to manage the massive volume of code moving across their DevOps pipelines.

    Generative AI platforms will fundamentally change the way humans interact with machines. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. Using a natural language interface, developers will soon be asking generative AI platforms to not only make suggestions but also debug applications and, eventually, write the code used to create an application.

    At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery and toil as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated.

    In the meantime, DevOps teams should spend some time identifying which tasks will become automated by generative AI and other technologies that employ machine and deep learning algorithms. It doesn’t make much sense to onboard new members to a DevOps team only to discover that the tasks assigned to that individual are about to be automated. Hopefully, when all these AI technologies are finally implemented, the entire DevOps experience will be better than ever.

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

  • AWS Converts Cedar Policy-as-Code Tool to Open Source Project

    AWS Converts Cedar Policy-as-Code Tool to Open Source Project

    At the Open Source Summit North America conference today, Amazon Web Services (AWS) announced it is making Cedar, a language for defining permissions as policies that includes automated reasoning to mathematically prove an IT environment is secure, available as an open source project.

    In addition, AWS launched SnapChange, an open source fuzz testing tool that cybersecurity researchers can employ to discover vulnerabilities by replaying physical memory snapshots in a KVM virtual machine. Fuzz testing uncovers software security issues by monitoring how the system behaves while processing random data.

    David Nalley, director of open source marketing for AWS, said both projects are part of an ongoing AWS effort to contribute intellectual property to the open source community that plays a pivotal role in the applications that organizations deploy on the AWS cloud.

    AWS has been employing Cedar to provide IT organizations with the ability to write authorization policies as code that can be deployed anywhere. It is most widely used within the managed AWS Verified Permissions service that manages those processes on behalf of organizations that deploy workloads on its cloud.

    Cedar differs from other policy-as-code approaches because it employs automated reasoning, a computer science discipline that is considered a subset of artificial intelligence (AI), to enable machines to prove theorems and checks. That latter capability is especially critical to enable organizations to mathematically prove that compliance mandates have been continuously met, noted Nalley.

    Otherwise, IT organizations become wholly dependent on an assessment of intermittent audits conducted by humans that are likely to arrive at varying subjective conclusions, he noted.

    The latest open source contributions from AWS come at a time when there is more scrutiny being applied to how open source software is developed and employed. The scrutiny increased in the wake of a series of vulnerability disclosures involving open source software, such as the Log4j monitoring software project.

    The maintainers of many open source software projects often don’t have the resources or capabilities required to immediately patch a vulnerability every time it is discovered. That’s become especially problematic, because more research into open source software vulnerabilities is being conducted; it’s only a matter of time before a vulnerability is detected in software that was largely created by developers that have limited cybersecurity expertise. Enterprises that consume open source software need to pay careful attention to what dependencies they are creating when that software gets incorporated into an application environment. A patch for a zero-day vulnerability that is discovered might not be readily available.

    Hopefully, consumers of open source software will become more involved in its development by contributing code or making available the financial resources that maintainers need to devote time and effort to creating a timely patch to a vulnerability. In the meantime, however, they should also be reviewing what open source software is included in applications running in production environments. Cybercriminals are increasingly looking to discover and exploit vulnerabilities in not just existing applications but not also in components they know are likely to be employed across a wide range of downstream applications.

    As such, finding ways to apply more cybersecurity expertise to application development by embracing DevSecOps practices has become an imperative rather than a recommendation.

  • GitGuardian Survey Surfaces Secrets Management Challenges

    GitGuardian Survey Surfaces Secrets Management Challenges

    A survey of 507 IT decision-makers in the U.S. and the United Kingdom published today found 75% of respondents said a secret leaked from at least one application, with 60% noting that the leak caused issues for either the company, employees or both.

    Conducted by Sapio Research on behalf of GitGuardian, a provider of a platform for securing application secrets, the survey found less than half of respondents (48%) are confident in their ability to protect application secrets to a great extent.

    The top source of risks when it comes to secrets management are source code and repositories (58%), followed by hard-coded secrets (47%). Just under a third (30%) of respondents to the GitGuardian survey admitted they share passwords and secrets when building applications as clear text within a messaging application.

    Just over a quarter (27%) still relied on manual code reviews to prevent secrets leaks, the GitGuardian survey found.

    On the plus side, 94% of the respondents said they were considering improving their secrets management practices in the coming 12-18 months, even though 93% said either “all” or “some” of their repositories were continuously scanned for hard-coded secrets.

    Thomas Segura, a cybersecurity expert for GitGuardian, said as the number of applications developed continues to increase, secrets sprawl has become a bigger challenge for application security. The way secrets are managed during application development has become a bigger issue in the wake of a series of software supply chain breaches that led to malware being injected into applications.

    The concern is cybercriminals that compromise software development environments will be able to retrieve secrets that they can later use to compromise an application after it has been deployed in a production environment. Cybercriminals are also now routinely scanning for secrets that may have been stored in text after an application has been deployed.

    The challenge is that secrets have not been historically managed effectively, so many organizations are now looking to implement more rigorous processes. Another challenge is that, in many cases, it’s not apparent whether those processes will be implemented by a DevOps team familiar with how an application is constructed or an application security team with more cybersecurity expertise, noted Segura.

    Regardless of the approach to remediating these issues, there is always going to be an issue because the humans who build applications are always going to make mistakes. The goal is to minimize the number of secrets that might be leaked by implementing DevSecOps practices that automate the review process, said Segura.

    In theory, at least, advances in artificial intelligence (AI) should make it easier to automate more of the secrets review process. In the meantime, however, organizations need to review their existing processes in advance of pending legislation that looks to hold organizations more accountable for application security if it is determined that the organization did not take reasonable precautions.

    It may be a while before such legislation becomes law, but one way or another, it’s clear that DevOps teams are soon going to be asked tougher questions about how secrets were managed every time an application security breach occurs.

  • Grafana Labs Reins in Cost of Storing Observability Data

    Grafana Labs Reins in Cost of Storing Observability Data

    Grafana Labs today made available an ability to customize what observability data is collected via its managed cloud service. This capability can help reduce storage costs in addition to enhancing the dashboard Grafana provides to make it simpler to track metrics usage.

    Wayne Jin, vice president of product marketing for Grafana Labs, said both capabilities would make it easier for DevOps teams to track and ultimately reduce the cost of storing the time-series data collected via its cloud platform.

    As more DevOps teams use an observability platform to continuously collect metrics like traces and log data, they are discovering that the cost of storing all that high-cardinality data can easily spin out of control.

    Grafana Labs is now making available an Adaptive Metrics capability that enables DevOps teams to fine-tune what data is collected and stored. However, in the event of an issue, DevOps teams can also turn back on all data the platform can collect to aid an investigation of the root cause of disruption, noted Jin.

    The Cardinality Management dashboards Grafana Labs made available last year for paid tiers of its cloud service are now being made available to users of the free tier of service as well, Jin said. This will further help reduce storage costs by making it easier to identify metrics that are being collected but not used by anyone on the DevOps team, he added.

    The Adaptive Metrics aggregation engine can then be applied to transform these metrics at ingestion into lower cardinality versions. Unused or partially used labels are stripped from incoming metrics, reducing the total count of time-series data collected. Adaptive Metrics also recommends aggregations based on an organization’s historic usage patterns, and DevOps teams can choose which aggregation rules to apply. Dashboards, alerts and historic queries are guaranteed to continue to work as they did before aggregation, with no rewrites needed.

    Based on results reported by early users, Grafana Labs reported that Grafana Cloud Adaptive Metrics could eliminate an estimated 20-50% of the time-series data collected with no perceived impact on observability.

    The Grafana Cloud service relies on an instance of open source Grafana Mimir to store data collected in a format originally defined for the open source Prometheus monitoring tool. While Prometheus is widely employed in Kubernetes environments, it’s also starting to gain traction as a monitoring platform in legacy monolithic environments. The amount of data being collected via that platform over time is steadily increasing. The Grafana Labs approach makes it possible for DevOps teams to reduce that data whenever there is no usage that needs to be investigated, for example.

    It’s still early days as far as adoption of observability is concerned, but in uncertain economic times, there’s generally a lot more sensitivity to the total cost of IT. Many organizations are especially focused on reducing the cost of storing data in the cloud to rein in monthly spending on cloud services. Regardless of the motivation, collecting and storing data that isn’t needed is never the best use of cloud storage resources that, from a cost perspective, are just as finite in the cloud.

  • CDF Report Reveals Lack of DevOps Maturity

    CDF Report Reveals Lack of DevOps Maturity

    A global survey of nearly 26,000 DevOps professionals published today by the Continuous Delivery Foundation (CDF) at the cdCon + GitOpsCon event found 84% of respondents are involved in some type of DevOps activity. However, the report also found just under half 49% are using a continuous integration (CI) or continuous delivery (CD) platform and only 22% are using CI and CD approaches to automate all building, testing and deployment of code in a production environment.

    The report, conducted in collaboration with SlashData, found the number of developers using CI or CD platforms only increased two percentage points year-over-year, with the use of self-hosted CI/CD tools dropping from 32% in the first quarter of 2022 to 23% in the same period this year.

    The survey also noted that only 7% of respondents this year described themselves as a DevOps engineer or specialist.

    Overall, medium-sized businesses have the highest involvement in DevOps practices (94%), followed by small businesses and large enterprises at just over 90%. More than three-quarters of developers (79%) are now using DevOps practices.

    The most common DevOps activity is monitoring software or infrastructure performance (47%), followed by application security testing and using CI to build and test code, tied at 37% each, and approving code deployments into production environments at 36%, the survey found.

    The average number of DevOps-related technologies used by developers (4.5) has, meanwhile, remained stable over the last year. The most widely used tools address issue tracking (39%), source code management (38%), test automation management (34%), collaboration and knowledge-sharing tools (32%) and application performance management/observability and agile project management tools tied at 31%.

    The survey also noted that the percentage of top performers—defined as those with lead times of less than one day—now stands at 15%. Survey results for top performers over the years continue to fluctuate between 13% and 17% of the survey total. On the plus side, 40% of developers have lead time changes of less than one week, the second-highest ranking for this survey.

    More than a third of all DevOps practitioners (34%), however, take longer than a week to restore service. Only 12% of DevOps practitioners take less than an hour to restore service.

    In general, the survey finds that organizations that use 10 or more DevOps tools are twice as likely to be high performers.

    Fatih Degirmenci, executive director for the CDF, told conference attendees the consortium, which now oversees nine projects, including the open source Jenkins CI/CD platform, continues to make progress as additional projects are added.

    However, while it’s clear that many organizations have adopted multiple DevOps tools and platforms, far too many of them still have a long DevOps journey ahead. Each organization will need to decide whether DevOps workflows need to be adopted to fit their needs, even as the pressure to build and deliver software faster continues to mount. In fact, at a time when more organizations than ever are dependent on software to drive mission-critical digital business transformation initiatives, time may be running out to adopt DevOps workflows at a deeper level if organizations hope to stay competitive.

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