Author: Mike Vizard

  • 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

    CVS Health
    Remote
    Lead Director – Enterprise Digital Security
    $140,000 to $280,000

    Indeed.com

    Splunk
    Remote
    DevOps and Observability Assigned Expert
    $143,200 to $196,900

    SimplyHired

    Book of the Month
    New York, New York
    Senior DevOps Engineer
    $140,000 to $180,000

    Monster.com

    Innova Solutions
    Plano, Texas
    DevOps Engineer
    $110,000 to $130,000

    Dice.com

    Solaris Finserv
    Kennesaw, Georgia
    DevOps Engineer
    $100,000 to $120,000

  • Grafana Labs Acquires Pyroscope to Add Code Profiling Capability

    Grafana Labs Acquires Pyroscope to Add Code Profiling Capability

    Grafana Labs this week announced it acquired Pyroscope and plans to merge Pyroscope’s open source continuous profiling project with the open source continuous profiling database that Grafana Labs launched last year.

    Richard Hartmann, director of community at Grafana Labs, said after logs, metrics and traces, continuous profiling is now the fourth pillar of observability that enables DevOps teams to identify how much infrastructure resources any given piece of code is consuming. That capability is critical for everything from controlling costs to improving performance to limiting the amount of carbon generated by an application both before and after an application is deployed, he added.

    The resulting Grafana Pyroscope project will be natively integrated with Grafana Labs’ open source dashboard project to make it simpler to visualize profiling data and correlate it with metrics, logs, and traces. Grafana Labs is also committing to adding profiling capabilities to the fully managed Grafana Cloud observability platform.

    Pyroscope currently makes a plug-in for Grafana available in addition to a cloud instance of Pyroscope. Integrating Pyroscope with the Grafana Labs portfolio will make it simpler for DevOps teams to visualize issues before there is a major disruption to an application environment, said Hartmann.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue. The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. Instead, the issue is understanding what queries can help DevOps teams better understand the root cause of an IT issue. Visualization tools, in combination with code profiling tools such as Pyroscope, should make it simpler to surface those issues.

    Grafana Labs is also enabling organizations to better address sustainability concerns that have emerged as more policies are enacted to encourage organizations to reduce the overall size of their carbon footprints. The European Union, especially, has been enacting policies that provide organizations with a range of incentives to encourage greater efficiency from IT environments. It won’t be long before more DevOps tools and platforms provide greater visibility and control over the amount of infrastructure application code is consuming to achieve sustainability goals.

    In the meantime, overall observability should continue to improve as organizations move beyond continuous monitoring to gain insights into how application environments are behaving. As IT environments become more complex, tools that monitor a set of pre-defined metrics are no longer enough to ensure application resiliency. The challenge—and the opportunity—is to determine how to take observability to the next level before the next inexplicable application performance degradation.

  • Large Organizations Are Embracing AIOps

    Large Organizations Are Embracing AIOps

    A survey of 265 IT leaders found the primary reason organizations are applying artificial intelligence to IT operations (AIOps) is to improve service and application availability and performance (60%), followed closely by automation of operations (58%) and processes (54%).

    Conducted on behalf of OpsRamp, a provider of an AIOps platform, the survey polled 138 IT leaders working for enterprise IT organizations and 127 representing managed service providers (MSPs). The organizations surveyed generated at least $25 million in revenue and have more than 500 employees. The survey found monitoring/native instrumentation (55%) ranked as the most important feature of an AIOps platform.

    Bill Talbot, chief marketing officer for OpsRamp, said the survey suggested the initial reason organizations appear to be adopting AIOps is to improve monitoring and overall observability as IT teams continue to find simple tasks—such as discovering what is in their IT environments—challenging to achieve.

    Overall, the survey found the greatest IT operations challenge for enterprises in 2023 was automating as many operations as possible (66%), followed by driving greater efficiency and productivity of IT operations teams and processes (61%). Application-to-infrastructure dependency mapping is the top incident management challenge (64%), the survey found.

    The primary operational benefit cited was reducing open incident tickets (65%), followed by reducing mean-time-to-discovery (MTTD) and mean-time-to-remediation (MTTR) tied at 56% and automation of tedious tasks (52%).

    The survey also found 80% of respondents reported it took less than six months to implement an AIOps platform, with more than two-thirds (68%) noting it takes more than six months to hire engineers with the right skillsets for AIOps. Well over 90% of respondents said AIOps is delivering the level of value they expected.

    Despite advances in AIOps, however, two-thirds of respondents said they are concerned about the accuracy of the data being used to train AIOps platforms. A little more than a third (36%) are also concerned about AIOps deployment causing job loss.

    While there has been a lot of initial skepticism concerning AI applications in IT operations at scale, adoption has now crossed the proverbial chasm, said Talbot. IT teams are finding a wide range of static application environments that lend themselves to being automated using machine learning algorithms, he added.

    Less clear, of course, is the degree to which AIOps can be applied to highly dynamic IT environments where changes to code are frequently made. However, the more routine processes that are automated, the more time DevOps professionals will have to manage more challenging issues.

    At this juncture, it’s not so much a question of whether AIOps will be employed to manage DevOps processes as much as it is to what degree. It remains to be seen how generative AI platforms such as ChatGPT might be applied to IT operations, but it’s apparent that AI will automate a wide range of tasks. It’s not likely those capabilities will eliminate the need for humans any time soon, but it does mean that many of the rote tasks that make working in IT tedious may soon disappear.

  • DevOps Adoption in Salesforce Environments is Advancing

    DevOps Adoption in Salesforce Environments is Advancing

    A global survey of DevOps professionals building apps in Salesforce environments found 44% of respondents reported their organization has a continuous integration/continuous delivery (CI/CD) platform in place, with another 39% planning to adopt one.

    The survey, conducted by Gearset, a provider of a DevOps platform for building custom applications in Salesforce environments, polled 1,254 DevOps professionals that are building and deploying custom applications on top of the Salesforce software-as-a-service (SaaS) platform. The survey also found nearly half (49%) implemented change monitoring, with another 33% planning to follow suit. More than half (52%) implemented source-drive workflows, with another 33% similarly planning to follow suit. A total of 41% of respondents noted that, over the last 12 months, they have more custom code to manage.

    Overall, the survey found 54% of respondents reported increased productivity, followed by improved quality and faster releases at 41% each. Nearly three-quarters (72%) reported they are able to deploy changes from one environment to another within four hours. Well over a third (39%) of this group are able to complete a deployment in less than an hour. Just under a quarter (23%) are also able to release code multiple times a week.

    However, only 18% can release a new feature to production in less than a day. Nearly half can complete the release within one day to a week. A total of 43% claimed that less than 10% of releases include a bug or error, with 46% reporting they can roll back a release in a day or less, if needed. Just over a third can restore a process in a day or less.

    The biggest obstacle to DevOps adoption is lack of experience (41%), followed by a third (29%) of respondents that reported difficulties with collaboration and another 29% that experienced limited buy-in from the rest of the application development team. Only 30% received DevOps training once a month, with 50% citing additional CI/CD and automation training as their biggest need.

    Despite these issues, a full 98% are generating a return on their DevOps investments, with 59% of teams reporting returns of over $10,000 per month and 40% reporting returns in excess of $50,000 per month. The top two priorities for the next 12 months are to consolidate systems and processes and improve flexibility, tied at 47% each, followed closely by 43% that noted that digital business transformation is a top priority.

    David Runciman, technical content manager for Gearset, said that while Salesforce applications are based on unique object architecture, it’s apparent that organizations are extending those applications using, for example, low-code tools more quickly. The issue that creates is, as organizations move to deploy these applications, they are encountering bottlenecks that conspire to slow the pace of innovation, he noted.

    The maturity level of DevOps teams building these applications will naturally vary. However, as the number of applications being built—especially by professional developers—increases, it’s only a matter of time before more organizations embrace DevOps best practices to bring order to the chaos, noted Runciman. While there may be some citizen developers building applications in Salesforce environments, the bulk of enterprise-class applications are built by professional developers that typically appreciate DevOps best practices, he added.

    The issue remaining is just how quickly those DevOps teams will be able to implement DevOps best practices as demand for additional applications grows.

  • JFrog Aligns With New Relic to Improve Observability

    JFrog Aligns With New Relic to Improve Observability

    JFrog and New Relic jointly announced today they will provide a free integration tool that will enable New Relic’s observability platform to consume log data from JFrog platforms for building and deploying applications securely.

    Announced at the Futurestack conference hosted by New Relic, this integration eliminates the manual effort that was previously required to integrate these platforms. Preconfigured New Relic dashboards provide a comprehensive view of performance data, artifact usage and security metrics in real-time that is automatically collected from JFrog Artifactory and JFrog Xray environments and then displayed alongside other telemetry data.

    Omer Cohen, executive vice president of strategy at JFrog, said that capability will make it easier to identify performance issues, urgent vulnerabilities and malicious users in a way that reduces the amount of time required to remediate those issues across the software supply chain.

    The goal now is to eventually provide similar levels of integration between JFrog platforms that enable DevOps teams to manage and secure application binaries with other observability platforms, added Cohen.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on need to be augmented. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue. The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. The biggest challenge is understanding which queries to actually launch to identify an issue that might later cause a major disruption. In the longer term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify those issues. In the meantime, much still depends on the acumen of the DevOps team employing an observability platform.

    In fact, a recent New Relic survey found only 27% of respondents have achieved full-stack observability, with only 5% claiming 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. More than half (52%) of respondents also admitted they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    On the plus side, nearly three-quarters (72%) expected to maintain or increase their observability budgets next year. More than half (52%) of respondents, including 57% of C-suite executives, expected observability budgets to increase over the next year. A total of 14% of all respondents and 16% of IT decision-makers expected to increase observability budgets significantly or extensively. More than a third (36%) believe observability increases their productivity and enables them to find and resolve issues faster. Just under a third (32%) said observability enables cross-team collaboration, while more than a quarter said observability improves their ability to innovate.

    One way or another, visibility into DevOps environments clearly needs to improve as application environments become more complex. The challenge, as always, is determining the cost required to achieve it.

  • Eclipse Foundation Touts Java SE Temurin Certification Momentum

    Eclipse Foundation Touts Java SE Temurin Certification Momentum

    The Eclipse Foundation revealed today the number of downloads for Java Standard Edition (SE)—dubbed Eclipse Temurin—certified using both a technology compatibility kit (TCK) and compatibility tests for evaluating associated runtimes reached 12.3 million in February.

    Tim Ellison, a project lead for creating compatibility tests for the Eclipse Foundation, said that level of activity suggests the governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based OpenJDK source code from multiple providers is gaining traction. Members of the Adoptium working group include Alibaba Cloud, Bloomberg, Google Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, Red Hat and Rivos. Eclipse Temurin has also become the default Java option for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    OpenJDK is a free and open source implementation of Java SE provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that allows it to run compatibility tests to ensure conformance to the Java specification.

    One of the reasons Eclipse Temurin is gaining traction is organizations are looking to reduce Java licensing costs during uncertain economic times by relying on an open source platform. At the same time, a consistent set of certified runtimes also reduces the level of DevOps friction that might otherwise be encountered when building and deploying Java applications, noted Ellison. There will, of course, always be multiple Java runtimes, but the level of incompatibility that would exist without testing them could be substantially higher, he noted.

    Despite the plethora of programming languages developers use, after more than 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Developers may be building and deploying applications faster, but most of them will continue to rely on the programming language they already know rather than master another. In addition, many of the Java applications that have been deployed over the last two decades are now being modernized within the context of a cloud migration.

    Arguably, Java is experiencing a renaissance following efforts to make it simpler for multiple organizations to contribute code to open source projects and increase the pace of innovation. The rate at which organizations can absorb that innovation will naturally vary, but it’s clear that more organizations are now running later editions of Java that improve both performance and cybersecurity overall.

    In the meantime, DevOps teams should expect to see more Java projects moving through pipelines in the months and years ahead. While not every legacy Java application may need to be updated before being retired, it’s apparent that the bulk of Java applications are still relevant. As such, it’s probable the efforts to modernize those applications will keep DevOps teams occupied well through the end of the decade.

  • ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs today announced it added an ability to detect secrets exposed in application binaries to its Software Supply Chain Security (SSCS) platform.

    Tomislav Peričin, chief software architect for ReversingLabs, said this addition will make it easier for DevSecOps teams to identify secrets that are inadvertently left in applications as plain text or that can be discovered because of weak cryptography, scripts that have been included in directories that have secrets configuration files, packaging automation mistakes, compromised developer accounts or the activities of malicious insiders.

    The SSCS platform can identify more than 250 secret types out of the box, including private keys, version control, certs, tokens and more. Once they are identified, the platform also surfaces their precise location, which services are affected and if those secrets are exposed or leaked elsewhere. The platform also identifies third-party, open source, testing keys and other commonly shared secrets in addition to which secrets have already been exposed. Armed with those insights, it then becomes possible to better prioritize remediation efforts on actionable issues to reduce overall manual triage fatigue, noted Peričin.

    ReversingLabs also provides guidance for sensitive information policies, including documentation of public exposures and breakdowns of secrets used for web service access credentials, web service access tokens, web service API keys and webhook service access keys.

    Most software composition analysis (SCA) tools used to secure software supply chains are limited to identifying issues in source code. As applications become more modular, however, the odds authentication credentials such as login credentials, application programming interface (API) tokens and encryption keys might be left exposed because of a developer mistake substantially increase. The overall goal is to make it possible for DevSecOps teams to discover these issues in binary code before an application is deployed, noted Peričin. That “just in time” approach to secrets management includes canary token management and custom detection policies to better ensure application security.

    In general, secrets within applications are becoming more challenging to secure as cybercriminals increasingly scan repositories and continuous integration/continuous delivery (CI/CD) platforms to find them. The ultimate goal is to inject malware into a software component that will be used in multiple downstream applications. Once activated, that malware will then create a backdoor through which cybercriminals can exfiltrate data or launch a full-blown ransomware attack. It was the latter type of attack that led to the U.S. government creating a formal National Cybersecurity Strategy to, in part, lock down the software supply chains employed by federal agencies to build applications.

    A recent survey published by ReversingLabs, however, found that while 87% of respondents agreed that software tampering has become a more frequently used cybersecurity attack, only 37% said they have any means to detect it. Only 7% said they could detect software tampering at each phase of the software development life cycle.

    It’s not clear to what degree best DevSecOps practices are currently being implemented within application development teams, but as more attacks are launched against software supply chains, it’s now only a matter of time before most DevOps teams are routinely required to scan code for exposed secrets and known vulnerabilities long before code is allowed anywhere near a production environment.

  • NETSCOUT Taps F5 to Optimize Custom App Performance

    NETSCOUT Taps F5 to Optimize Custom App Performance

    Through its alliance with F5, NETSCOUT Systems has extended the reach of its nGeniusOne enterprise performance management platform to support custom applications.

    The nGeniusONE platform supports more than 1,000 voice, video and business data applications using NETSCOUT InfiniStreamNG appliances in combination with nGeniusONE to provide visibility into any infrastructure environment, including data centers, private and public cloud and co-location facilities. The integration with F5 extends those capabilities to add support for custom applications via integration with F5 BIG-IP server pool definitions that can now be directly imported into nGeniusOne.

    Eileen Haggerty, area vice president for enterprise product and solutions marketing for NETSCOUT, said that approach enables nGeniusOne to access clear, unencrypted traffic from the BIG-IP Local Traffic Manager.

    As more cloud-native applications built using microservices are deployed across distributed computing environments, network latency is becoming a bigger DevOps challenge. A wide range of networking issues can adversely impact application performance, but without any visibility into network traffic, it can be challenging to determine the root cause of an issue. NETSCOUT has deployed a global network of appliances to surface those issues.

    A recent report published by Cloud Security Alliance (CSA) found the average enterprise uses 464 custom applications and expects to deploy 37 new applications in the next 12 months. At that rate, the number of organizations likely to encounter networking issues is only going to increase, noted Haggerty.

    It’s not clear to what degree network operations (NetOps) teams are becoming integrated with DevOps teams that build and deploy custom applications. The need for both teams to collaborate more effectively is becoming more apparent as more application code is deployed at the network edge. In some cases, developers are now programmatically invoking network resources directly, while other organizations provide developers access to a portal to self-service their requirements within the context of a set of pre-defined guardrails. Regardless of approach, the need for greater visibility into the underlying networks that custom applications depend on has become critical.

    Exactly how much that need will drive organizations to embrace one networking vendor over another remains to be seen. DevOps teams are starting to exercise more influence as organizations realize how much they depend on custom software to drive digital business processes. DevOps teams need to be able to understand whether an issue is the result of a networking problem or an inherent problem with the code written or the way an application has been deployed.

    Of course, DevOps and NetOps teams don’t share a common nomenclature so the cultural divide between these teams can be wide. The simpler it becomes for NetOps teams to share visibility into networking services the easier it becomes to bridge that divide. Developers should be able to see for themselves how changes to application code might potentially improve network performance. In the absence of any proof to the contrary, most DevOps teams will simply assume there is a fundamental flaw in the networking services being provided.

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

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

    Monster.com

    Citibank
    Tampa, Florida
    Application Development Technology Lead Analyst
    $154,000 to $179,000

    Dice.com

    ZealTech
    San Jose, California
    DevOps Architect
    $150,000 to $200,000

    SimplyHired

    Musicnotes
    Remote
    DevOps Engineer
    $85,000 to $100,000

    Indeed.com

    Snowrelic
    Remote
    DevOps Engineer
    $82,486 to $173,694

    LinkedIn

    Oak Ridge National Laboratories
    Oak Ridge, Tennessee
    DevOps Engineer
    $78,000 to $137,000