devopsy.kinsta.cloud

Author: Mike Vizard

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

  • 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

    SiriusXM
    Associate Director for Software Delivery
    Deerfield Beach, Florida
    $157,000 or $250,000

    SimplyHired

    Nagarro
    Remote
    Senior Staff Engineer – DevOps
    $155,000 to $196,000

    Dice.com

    Engage Partners
    Davie, Florida
    DevOps Architect
    $130,000 to $160,000

    Indeed.com

    ServiceNow
    Orlando, Florida
    Staff DevSecOps Engineer
    $114,000 to $144,000

    Monster.com

    Swift Group
    Fort Belvoir, Virginia
    DevOps Engineer
    $80,000 to $180,000

  • New Relic Report Surfaces Spike in Amazon JDK Usage

    New Relic Report Surfaces Spike in Amazon JDK Usage

    An analysis of the Java applications observed by New Relic showed nearly one-third of organizations (31%) are using the Amazon Java development kit (JDK) compared to 28% using the Oracle JDK as more Java applications are built and deployed in the cloud.

    The report also found the number of Java applications running in containers is remaining steady year-over-year at 70%.

    Overall, the report published last week found more than 56% of applications are now using Java 11 in production, followed by Java 8 at nearly 33%. However, more than 9% of applications are now based on Java 17, representing a 430% growth rate.

    Jemiah Sius, director of developer relations for New Relic, said it’s clear that Java 17 is starting to gain traction in production environments. This is happening at a faster rate than previous releases of the venerable programming language as more cloud-native applications based on containers are being built and deployed, noted Sius.

    Regardless of the version of Java, it doesn’t appear developers are moving away from Java as they build cloud-native applications, noted Sius. Rather than requiring developers to learn a new programming language, it’s simply been more cost-effective to enable them to continue building applications using a programming language they already know.

    Java, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under open source licenses. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications being modernized. As a result, most organizations will continue to deploy Java applications everywhere from the network edge to the cloud.

    New Relic, of course, is betting that as more cloud-native applications are deployed, the need for an observability platform that addresses the needs of developers and IT operations teams alike will become more apparent.

    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.

    The expectation is that that augmenting DevOps teams with observability tools and platforms that are increasingly being infused with artificial intelligence (AI) will reduce outages, even as cloud-native applications make IT environments even more complex than they already are. The issue is, however, those application environments are becoming more complex at a rate that is far exceeding the pace at which observability platforms are currently being adopted.

  • Mezmo Adds Free Community Plan for Managing Observability Data

    Mezmo Adds Free Community Plan for Managing Observability Data

    Mezmo this week added a free trial and a community plan for the Mezmo Telemetry Pipeline service to make it simpler for DevOps teams to store and manage the large amounts of telemetry data they are collecting.

    Mezmo CEO Tucker Callaway said as more DevOps teams embrace observability to minimize disruptions to application environments, they are struggling to manage the explosion of data being created. The Mezmo platform makes it possible to apply data engineering best practices to manage that data using a set of drag-and-drop visual tools, he added. A set of data transformation tools also makes it simpler to extract metrics embedded in the logs, summarize events and metrics and then forward those metrics to downstream platforms for analysis.

    The free edition of the platform makes it possible for organizations to begin to apply those capabilities without any upfront costs required, noted Callaway.

    It’s not clear to what degree DevOps teams may need to add data engineering to manage all the telemetry data being collected. It’s already apparent that the cost of storing and managing all that data is becoming a significant issue as more applications are instrumented. In fact, it’s nearly impossible to manage cloud-native applications without being able to observe interactions between the microservices used to construct them.

    Log management has always been a challenge, but with the addition of traces, the amount of telemetry data being collected to surface metrics has increased. The Mezmo platform makes it possible to set a daily or monthly hard limit on the volume of logs stored or, alternatively, set soft daily or monthly quotas that can apply throttling logic to ensure mission-critical log data will continue to flow.

    DevOps teams can also make use of soft limits to reallocate storage resources from one team to another based on how much log data might be generated for a specific amount of time.

    Reducing storage costs has naturally become a higher priority during challenging economic times, so there’s a lot more pressure for DevOps teams to be more efficient. Finance teams are reducing costs by, for example, applying quotas to the amount of storage resources being made available to individual DevOps teams. The days when cloud storage resources were made available indiscriminately are over.

    It’s not clear how quickly DevOps teams are embracing observability, but it is certain that relying on predefined metrics to monitor IT environments is no longer sufficient. DevOps teams need to be able to query telemetry data to, for example, identify bottlenecks that are often created by dependencies between microservices. The issue is striking a balance between the amount of data being collected and the cost of storing it all.

    Regardless of approach, observability is rapidly becoming a requirement for DevOps teams to succeed. In fact, there is already no shortage of observability platforms to choose from. The issue is that not every observability platform provider is equally concerned about the cost of storing all the data being collected.

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp is adding templates and collaboration tools to make it easier to access generative artificial intelligence platforms such as ChatGPT from within its project management application.

    Haris Butt, head of product design for ClickUp, said ClickUp AI now includes pre-built department-specific prompts that any product managers, developers or designers can easily access rather than having to develop prompt engineering skills to engage a generative AI platform more effectively.

    The templates, for example, make it simpler to produce summaries of project timelines in addition to the ability to automatically generate a whiteboard that lists tasks that need to be finished to complete a project.

    In the longer term, ClickUp is also moving toward developing its own large language model (LLM) using its own data to provide a generative AI experience specifically optimized for project management, added Butt.

    ClickUp is embedding AI into project management applications as part of an effort to eliminate drudgery, added Butt. One of the primary issues that makes project management challenging is that navigating workflows can be challenging, especially for stakeholders that might not be as well versed in, for example, how a Gantt chart flows.

    It’s still early days as far as generative AI is concerned, but it’s already apparent that a wide range of templates are being developed to make it simpler to invoke these platforms. The need for project managers to become well-versed in all the nuances of prompt engineering techniques to optimize generative AI queries is likely to be limited.

    In fact, the general expectation is that every application will eventually include templates for invoking generative AI capabilities. Less clear is the impact that should have on productivity. In the case of DevOps teams, however, many tedious project management tasks should become increasingly automated.

    Generative AI will, of course, soon be employed across the entire DevOps workflow. Many of the tasks that have historically conspired to make DevOps processes tedious will be automated. In fact, many application developers are already using AI to test and review code. DevOps teams that have historically advocated ruthless approaches to automation are likely to be at the forefront of AI adoption.

    There are, of course, concerns about the accuracy of generative AI platforms such as ChatGPT that have been trained using data that hasn’t always been verified. As a result, it’s possible that some of the results being surfaced by these platforms should be reviewed by humans before being acted on. However, LLMs trained on narrower ranges of validated data will soon become commonplace. As those AI advances are made, the accuracy of generative AI platforms that are optimized for specific use cases will increase.

    In the meantime, DevOps teams should be more concerned about being left behind than about how generative AI impacts their employment prospects. There is no doubt generative AI will transform DevOps workflows along with a wide range of processes. The issue now is determining where DevOps teams can add value—and where machines can’t—in an era where IT environments are becoming more complex with each passing day.

  • Device42 Brings Power and Carbon Emission Tracking to IT Asset Management

    Device42 Brings Power and Carbon Emission Tracking to IT Asset Management

    Device42 today made available a power and CO2 Summary Dashboard to its agentless platform that employs machine learning algorithms to discover and track IT assets.

    Raj Jalan, Device42 CEO, said the dashboard makes it possible for IT teams to combine the tracking of assets and associated dependencies with a capability that enables them to reduce power consumption costs and levels of carbon emissions.

    It’s not clear yet how carbon emission tracking will be integrating into IT management frameworks, but as sustainability becomes a more pressing issue, it’s only a matter of time before IT teams will be required to monitor power consumption and associated carbon emissions more closely, said Jalan.

    The Device42 dashboard simplifies that task by identifying carbon emissions by location, business unit, vendor or application. Armed with that data, it then becomes possible to consolidate servers and applications or move workloads to more efficient platforms, added Jalan.

    Arguably, the biggest challenge when it comes to managing IT infrastructure is the number of organizations that are still using spreadsheets to do so. The Device42 approach to discovery and assessment uses the application programming interfaces (APIs) exposed by cloud services providers and IT vendors. Once mapped, it then becomes possible for IT teams to use a search function to uncover, for example, dependencies between multiple services.

    In theory, it should be possible for DevOps teams to also programmatically implement policies based on the Device 42 data to move workloads in way that reduce IT infrastructure costs. Over the years, many organizations have lost track of how workloads have been deployed in, for example, cloud computing environments—only to discover a surprise expense at the end of the month.

    In fact, one of the hottest segments of IT these days is the emergence of financial operations (FinOps) as a discipline to control cloud computing costs. Fundamentally, FinOps is the discipline that promotes a shared responsibility for an organization’s cloud computing infrastructure and costs. Rather than having disparate procurement teams working in silos to identify and approve costs, business, financial and IT leaders establish policies and best practices for usage that are programmatically enforced.

    It’s still early days as far as the adoption of FinOps is concerned, but adding that capability first requires a deep appreciation for what IT assets are being used to run which workloads. From there, it then becomes possible to not only optimize usage but also reduce both electricity costs and carbon emissions.

    Of course, the tracking of carbon emissions right now is a bigger issue in Europe and elsewhere than it is in the U.S. However, a global framework for trading carbon credits is now impacting IT teams as organizations look to minimize their carbon footprints. Sustainability has become an economic issue.

    In the meantime, DevOps teams should expect that soon, power consumption and carbon emissions will be added to the list of metrics they are measured on.

  • InfluxData Makes Processing Observability Data at Scale More Efficient

    InfluxData Makes Processing Observability Data at Scale More Efficient

    InfluxData today made available an update to its open source time series database that can now analyze metric, event and trace data in a single datastore with unlimited cardinality in terms of how they are aggregated.

    The company is now making available a single-tenant instance of InfluxDB as a managed service alongside its already-existing multi-tenant cloud service that is based on a serverless architecture.

    Finally, InfluxData also announced that later this year it will make available InfluxDB 3.0 Clustered and InfluxDB 3.0 Edge to provide a curated version of the database that organizations can deploy themselves where they best see fit.

    InfluxData CEO Evan Kaplan said InfluxDB has been developed to support a wide range of emerging applications that require access to time series data, including the observability platforms core to DevOps workflows that require visibility into metrics, events and trace data.

    Over the past three years, InfluxDB has been revamped to run on a columnar engine, dubbed IOx, that leverages the open source Apache Arrow memory format and written in the Rust programming language. Kaplan said that approach makes it possible to continuously ingest, transform and analyze hundreds of millions of time series data points per second without limitations.

    At the same time, InfluxDB takes advantage of high compression object storage to reduce the total cost of storing all that data. It also provides interoperability with Open Data Architecture (ODA) to integrate with data lakes based on open source platforms such as DataFusion, Flight SQL and Parquet that are being advanced by the Apache Software Foundation.

    The arrival of version 3.0 of InfluxDB comes as many DevOps teams are starting to struggle with the amount of observability data being generated. DevOps teams want to be able to move beyond monitoring a set of pre-defined metrics and query data in a way that enables them to surface anomalies indicative of a potential issue before there is a major disruption to an application service.

    One of the major challenges today is the tradeoff between how much data is collected and analyzed versus the cost of processing and storing it. InfluxDB provides a mechanism for analyzing high cardinality data involving metrics, events and traces cost-effectively.

    Observability is, of course, only one of several use cases for a time series database capable of processing data in near-real-time. As organizations embrace digital business transformation initiatives, they need to be able to process data in near-real-time at the point where it is being created and consumed. Those applications won’t necessarily replace existing applications based on batch-oriented processing but, over time, they create two distinct classes of applications that process data in fundamentally different ways. The challenge, as always, will be defining the DevOps workflows required to manage applications running on multiple distinct types of architectures.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird today added an application programming interface (API) to its low-code platform for building mobile applications that enables developers to add bots that communicate with OpenAI’s ChatGPT.

    Shailesh Nalawadi, head of product for Sendbird, said this API makes it possible to add the ability to communicate directly with the generative artificial intelligence (AI) platform from within both new and existing applications in just a few minutes.

    Most developers will add natural language processing (NLP) interfaces to complement the graphical user interfaces that most mobile applications today surface, added Nalawadi. It will be up to each development team to determine how best to employ that capability, but Sendbird envisions, for example, a health care application being able to invoke ChatGPT to answer queries, he noted.

    In the longer term, Sendbird will provide APIs to enable mobile app developers to invoke a wide range of large language models (LLMs). LLMs are increasingly being developed for generative AI platforms and are being optimized for a range of use cases.

    While OpenAI’s generative AI model is being widely used thanks mainly to Microsoft, there are already LLMs that are being created for a narrower range of use cases using much less data. DevOps teams should expect APIs invoking any number of generative AI platforms from within applications to become commonplace in the weeks and months ahead as more end user come to expect to be able to engage these platforms from within almost every application Sendbird’s chatbot API can now be invoked by more 1,300 existing mobile applications alone.

    In general, developers have tended to employ chatbots sparingly because they are often too scripted and inflexible. ChatGPT, conversely, provides a much more open-ended user experience. Organizations can also feed historical conversations or customer relationship management (CRM) data to ChatGPT to drive more personalized and accurate responses, given the veracity of some of the data used to train ChatGPT.

    A recent survey of digital quality testing professionals conducted by Applause, a provider of a platform for accessing a networking of independent testers, found nearly one-third (30%) of respondents are dissatisfied with their current chatbot, IVR and conversational assistant experiences, with wrong answers (29%) and a lack of understanding (24%) as the top two reasons cited. The results indicate there is plenty of opportunity for improvement.

    Nearly three-quarters (74%) said they had a positive experience with the ChatGPT generative artificial intelligence (AI) platform, with more than two-thirds (67%) reporting the platform provided helpful answers to questions. In terms of work-related tasks, most said ChatGPT would either be “very” (43%) or “somewhat” (37%) helpful.

    It’s apparent now that generative AI platforms are about to change the way humans engage with machines. Instead of always creating an abstraction to interface with a machine it’s now feasible for interactions to occur between them using language humans readily understand. As such, the way applications are built and employed is about to fundamentally change in ways that are difficult to predict.