devopsy.kinsta.cloud

Category: News

  • Dynatrace Adds Generative AI Capabilities to Davis Engine

    Dynatrace Adds Generative AI Capabilities to Davis Engine

    Dynatrace today revealed it has added generative artificial intelligence (AI) capabilities to its Davis engine it uses to apply machine learning algorithms to its observability platform.

    Steve Tack, senior vice president for product management at Dynatrace, said that hypermodal approach to AI will allow DevOps teams to take advantage of probabilistic AI capabilities provided by Davis CoPilot that are enabled by large language models (LLMs) originally developed by OpenAI.

    The generative AI capabilities effectively provide DevOps teams with a tool that surfaces workflow recommendations via a natural language interface. The recommendations are based on historical data such as sales and customer experience trends, seasonality and cloud application health. It is also able to analyze dependencies across large sets of data while retaining context accessed via the Dynatrace Grail data lakehouse and the Dynatrace Smartscape application visualization and mapping framework.

    Dynatrace is now making a case for a multimodal AI platform that uses a common set of metrics, traces, logs, user behavior and topology to enable machine learning algorithms to predict anomalies and causal-AI dependencies to determine the root cause of an IT issue and then leverage generative AI to provide recommendations to resolve it. The company is forecasting IT teams will achieve 10% to 20% productivity improvements year-over-year as a result.

    It’s too early to determine the full extent to which a multimodal approach to AI will transform IT management, but it’s clear that as IT operation teams become more productive, more time will be freed up for innovation, noted Tack. Many of the manual tasks that IT teams still need to perform divert time away from building and deploying additional applications, he added.

    Naturally, there’s a lot of speculation concerning the impact AI will have on DevOps. Some contend it’s only a matter of time before the entire software engineering process is automated. As those advances are made, the cost of building applications will effectively drop to zero. Others argue that AI will augment DevOps teams in a way that makes it simpler to manage IT at scale using either the same number or possibly even fewer engineers.

    The one thing that is certain is that AI will soon be pervasive, which will drive the adoption of automation frameworks as organizations look to operationalize the insights surfaced by AI platforms. As rich as the insights any AI model surfaces might be, they only provide real value when integrated with an automation framework, noted Tack.

    Ultimately, most DevOps professionals will not want to work for organizations that don’t provide them with AI tools that make it more likely for them to be successful. Organizations that embrace AI may not have a sustainable competitive advantage when every other organization is doing the same, but those that don’t will soon be left behind. Those that succeed will benefit from managing application environments at a previously unprecedented level of scale at minimal additional cost. The challenge is determining which tasks will be automated with an eye toward planning how DevOps roles will need to evolve.

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

    Indeed.com

    SAP
    San Francisco, California
    DevOps Engineer
    $141,378 to $162,000

    CareeerBuilder.com

    Citigroup
    Tampa, Florida
    DevOps Lead Engineer
    $110,090 to $165,130

    Dice.com

    Cognizant Technology Solutions
    Seattle, Washington
    xStore DevOps Lead
    $114,365 to $127,538

    LinkedIn

    J.Crew
    New York, New York
    Lead DevOps Engineer
    $108,800 to $136,000

    SimplyHired.com

    Hearst Media Services
    New York, New York
    DevOps Engineer
    $98,900 to $125,000

  • AI ‘is Getting Worse’ ¦ AI ‘Will Lose India Jobs’ (Probably Isn’t ¦ Probably Won’t)

    AI ‘is Getting Worse’ ¦ AI ‘Will Lose India Jobs’ (Probably Isn’t ¦ Probably Won’t)

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

    This week, a conundrum: On the one hand, researchers say ChatGPT is losing the plot; and on the other, we hear outsourced coding jobs in India will be replaced by AI. (more…)

  • Google Announces Availability of iPaaS Service

    Google Announces Availability of iPaaS Service

    Google today made available an integration platform-as-a-service (iPaaS) capable of invoking a range of methods to integrate applications.

    Initially developed for the Apigee application programming interface (API) management platform Google acquired in 2016, the Application Integration service can now, for example, also consume a publish and subscribe event or an event driven through a Salesforce platform.

    Amit Zavery, vice president and general manager for Google Platform, said the Application Integration service provides IT organizations with all the benefits of an iPaaS without requiring them to stand up and manage an integration platform themselves.

    The Google Application Integration service also provides access to a Visual Integration Designer tool that can be used to build workflows using a low-code tool. In total, there are now more than 75 connectors that can be used to integrate multiple Google Cloud services and third-party platforms that can run in either a cloud or on-premises IT environment, said Zavery.

    In general, visual tools are transforming how integrations are created and expanded within organizations, noted Zavery. Rather than using lower-level procedural code, a visual tool enables developers to employ low-code to create integrations. That makes it simpler to collaborate with business users that can now more easily participate in developing workflows.

    In fact, in some cases, business users, otherwise known as citizen developers, have enough technical acumen to create their own workflows using low-code tools.

    There are, naturally, going to be plenty of complex integration challenges that will require procedural code, but the bulk of the integrations required today are not especially complex.

    Regardless of who creates the integration, the number of them being employed across an enterprise organization continues to increase as more digital business transformation initiatives are launched. Developers are not going to be able to keep pace with the demand for those integrations if they rely solely on procedural code. The only way to effectively reduce the backlog for integrations is to rely more on visual tools to construct them. In most cases, the integration being created is relatively trivial. The only reason it wasn’t created sooner is there are not enough developers available to complete that task using procedural code.

    There are, of course, no shortage of iPaaS options available. As more workloads are deployed in the cloud, Google is betting the center of gravity for integration will shift toward the places where modern microservices-based workloads are deployed to reduce overall latency.

    It’s not clear whether organizations still view integration as an afterthought versus employing an integration platform around which all applications revolve. That latter approach tends to reduce the total cost of integration when compared to using multiple point products that are not managed via single framework, noted Zavery.

    Ultimately, IT teams that adopt an iPaaS are able to focus more on higher-value IT tasks. The issue is determining which integration projects really require professional developers with lots of integration expertise and which, via a low-code tool, can be handled by almost any developer.

  • Postman Acquires Akita Software to Gain API Observability

    Postman Acquires Akita Software to Gain API Observability

    Postman today announced it has acquired Akita Software to gain access to a platform for monitoring and observing application programming interfaces (APIs).

    The first integration of the respective products offered by both companies will arrive in beta this fall.

    Postman CEO Abhinav Asthana said the acquisition of Akita Software will make it much simpler for organizations to discover what APIs are being employed across an enterprise. A recent Postman survey found that 28% of developers are now deploying APIs at least once per week.

    The Akita Software platform will make it simpler for organizations to discover both rogue APIs that have been created by a shadow IT project and zombie APIs that have been inadvertently left exposed long after they are needed.

    Akita Software’s CEO Jean Yang said the integration with Postman’s API management platform will provide a rich source of data that can be used to add artificial intelligence (AI) capabilities to Akita’s API observability platform. For example, generative AI capabilities should make it simpler to create summaries in natural language that explain the calls an API is making to specific data sources.

    In addition, the combined company will be in a better position to enable organizations to better secure their APIs after deployment by surfacing anomalous behavior indicative of an API that is being used to exfiltrate data, she added.

    The merger with Postman will, in effect, enable the combined entity to provide a complete ecosystem for managing APIs, noted Yang.

    Most APIs are used primarily to interconnect internal-facing applications and systems, with a subset used to integrate partners. Only a relatively small percentage of APIs are externally facing in the sense that they expose data to the internet. Many organizations, however, fail to appreciate how quickly an internally facing API can become externally facing over the course of its life cycle. As such, IT teams need tools and platforms that can manage and secure APIs as they evolve.

    As APIs continue to play a crucial role in advancing business goals, there is a clear need for increased visibility as the types of APIs employed also continue to expand. Most APIs in use today are based on the REST format, but there are also APIs based on GraphQL, event-driven architecture and various messaging platforms. None of these newer APIs will supplant REST APIs any time soon. Rather, they are being applied to drive additional processes alongside REST APIs.

    In the longer term, it’s not clear how many APIs will be managed by the developers that created them versus a centralized DevOps team. However, the more APIs that are deployed in a production environment, the less feasible it becomes for developers to manage their life cycle. The challenge is making sure there is some type of structured workflow in place that, at the very least, makes everyone involved in the process aware that a new API has been created and deployed.

  • Webb.ai Launches AI-Based Continuous Root Cause Analysis

    Webb.ai Launches AI-Based Continuous Root Cause Analysis

    Webb.ai today opened an early access program access to a Continuous Automated Root Cause Analysis platform that uses artificial intelligence (AI) combined with a knowledge graph to dynamically keep track of and analyze changes to IT environments.

    Manish Gupta, CEO of Webb.ai, said the platform uses a mix of machine learning algorithms and generative AI capabilities based on large language models (LLMs) to aggregate alerts into higher-order insights that are presented in natural language to members of a DevOps team.

    That approach differs from legacy approaches because it tracks causal relationships between changes versus relying on probabilistic models that tend to create a lot of false positives, he noted.

    Webb.ai is also taking advantage of Kubernetes clusters to enable its platform to scale up and down as needed when analyzing data, added Gupta. That platform is also more efficient than other approaches to observability that require IT teams to store massive amounts of data. In contrast, the Continuous Automated Root Cause Analysis automatically surfaces anomalous events that DevOps teams can choose to save rather than requiring them to save all the metrics, logs and traces that would otherwise need to be tracked, he noted.

    Most IT incidents can be traced back to the most recent changes made to an IT environment. The challenge is as IT environments have become more complex, it’s not feasible for humans to keep track of those changes without relying on AI and a knowledge graph, said Gupta.

    As businesses become more dependent on software to drive digital processes, the cost of downtime is exponentially increasing. The need to identify the root cause of an IT incident as fast as possible has become a critical requirement, he added.

    Webb.ai doesn’t see AI technologies replacing the need for DevOps professionals and site reliability engineers (SREs) for at least another 10 to 15 years. In the meantime, many tasks that today are completed manually will be increasingly automated, said Gupta. A DevOps engineer dragged out of bed at 2:00 A.M. to address an issue does not want to have to sift through alerts. Instead, generative AI tools will summarize the issue at hand with recommendations on resolving it, noted Gupta. In effect, DevOps teams will be augmented by AI so they can manage IT environments at even higher levels of scale, he said.

    There is always going to be some sense of fear and loathing when it comes to AI, but ultimately, AI should reduce the burnout rates that today adversely affects any organization’s ability to retain DevOps professionals. Far too much time is spent trying to identify the root cause of a slowdown in a cloud-native application’s performance that could be caused by any number of issues involving one dependency or another. The frustrating thing, of course, is that while it may take days to identify the root cause of an issue, it often takes just a few minutes to resolve.

  • Splunk Goes Azure With Microsoft Partnership

    Splunk Goes Azure With Microsoft Partnership

    It’s not every day that a well-established technology provider announces they are building their solutions on a new cloud technology stack, but that’s what Splunk announced at its .conf23.

    “…[O]ne of the most exciting [announcements] is Splunk’s new strategic partnership with Microsoft to build Splunk’s cloud solutions natively on Microsoft Azure. Together, our approach will enable our joint customers to migrate, modernize and grow their environments with end-to-end cloud and hybrid visibility at scale,” Splunk President and CEO Gary Steele said in a Splunk blog post this morning.

    Why such a bold move, might you ask? “Splunk’s strategic partnership with Microsoft to build Splunk natively on Azure demonstrates our commitment to advancing digital resilience and meeting our customers where they are…” Well, indeed, a big, big draw is the vast landscape of customers building and operating applications in Azure. While Gary didn’t share too many details about specific new capabilities or offerings yet, customers will get to use their Azure credits for Splunk offerings. I suspect two other important underlying factors made such a tech marriage happen: Open source and AI.

    First, Microsoft is far removed from the days of being viewed as a pariah by the open source community and is now a leader and contributor to well-known open source projects (OpenTelemetry, to name one); it abandoned its proprietary service mesh tech and got behind Istio (a recently-graduated CNCF project) and now owns the largest open source repository ecosystem with GitHub.

    While Splunk is by no means a noob when it comes to incorporating AI into products, the company continues to announce new AI capabilities, including a generative AI chat interface with a preview of Splunk AI Assistant, an improved version of the former SPL Copilot. Other AI-related announcements include Splunk App for Data Science and Deep Learning (DSDL) 5.1, which allows customers to leverage LLMs to build and train models with their domain-specific data for text summarization and text classification use cases. Stay tuned for more from .conf 2023!

  • Splunk Adds Generative AI Tool and OpenTelemetry Collector

    Splunk Adds Generative AI Tool and OpenTelemetry Collector

    At its .conf23 conference, Splunk today revealed it added a slew of capabilities to its portfolio of operational analytics tools, including an assistant that leverages generative artificial intelligence (AI) capabilities that use large language models (LLMs) the company developed to enable IT teams to use natural language to invoke the Splunk Processing Language (SPL).

    In addition, Splunk is also previewing OpenTelemetry Collector, an add-on that uses open source agent software being developed by the Cloud Native Computing Foundation (CNCF) to capture metrics and traces. It is designed to enable IT teams to use OpenTelemetry alongside existing agent software that Splunk uses to capture metrics.

    Tom Casey, senior vice president for products and technology at Splunk, said the domain-specific LLMs that the company created enable Splunk Assistant to write or explain customized SPL queries in a way that augments rather than replaces the need for IT professionals. Splunk Assistant is designed to surface recommendations to optimize IT environments to reduce toil rather than automate entire processes, he noted.

    Splunk is adding other tools infused with machine learning algorithms to its portfolio. These include the Splunk App for Anomaly Detection and an Outlier Exclusion for Adaptive Thresholding to detect and omit abnormal data points that has been added to version 4.17 of the Splunk IT Service Intelligence platform.

    In addition, Splunk is previewing an ML-Assisted Thresholding tool for Splunk IT Service that uses historical data and patterns to create dynamic thresholds with a single click.

    The company is making available a 5.4 update to the Splunk Machine Learning Toolkit (MLTK) 5.4 and a Splunk App for Data Science and Deep Learning (DSDL) 5.1 toolkit that provides access to additional data science tools that can extend MLTK to enable organizations to build their own custom LLMs and AI assistants.

    Finally, Splunk added Unified Identity to make it simpler to access Splunk Cloud Platform and Splunk Observability Cloud along with an update to Splunk Cloud Platform and Splunk Enterprise that make it simpler to ingest, route, search and export data.

    It’s still early days as far as the application of generative AI is concerned, but it’s already clear that the way IT is managed is about to be transformed. Coupled with tools such as OpenTelemetry that make it less expensive to collect massive amounts of data, the opportunity to train LLMs that streamline a wide range of processes is immense. Those capabilities won’t replace the need for humans to manage those processes, but they will most certainly cause staff realignments as many manual tasks become increasingly automated.

    In fact, it’s hard to imagine an IT team that would not want to take advantage of AI capabilities to simplify the management of complex IT environments that now function at a level of scale that few IT professionals can successfully manage on their own. One way or another, AI is going to be broadly applied to IT workflows. The only thing left to be seen now is the ultimate impact.

  • The Cyber Resilience Act Threatens the Future of Open Source

    The Cyber Resilience Act Threatens the Future of Open Source

    The European Union (EU) is currently considering approval of the Cyber Resilience Act (CRA), a proposed regulation that is a major threat to the future of the global open source industry. While the intention of the act is to enhance cybersecurity (which is extremely welcome), its current form lacks clear liability exemptions for many open source developers and maintainers, which could be a death knell for open source in the EU and which could spark additional, global implications.

    The CRA regulation for the EU was proposed on September 15, 2022, by the European Commission. The intent is to improve cybersecurity and cyberresilience in the EU through common cybersecurity standards for products with digital elements. In theory, this is welcome. But there are some notable areas that many open source developers and industry organizations are concerned about.

    Modern applications are comprised of 90% open source code; penalizing open source developers would lead to a fragmented community and hinder important projects across various sectors, including critical infrastructure, health care and even military systems.

    The seemingly purposeful omission of exemptions for open source would put undue onus on open source foundations and maintainers and poses a serious risk to not just EU innovation and security but global collaboration. Something we, and many others in the industry, have tried to raise awareness about over the past six months. Unfortunately, the EU has largely ignored the industry’s voice. Holding open source developers whose components end up in commercial products liable for security issues will stifle innovation and harm the EU economy without providing a substantive improvement in security.

    This legislation is slated for a vote on July 19 in the parliament’s Industry, Research and Energy (ITRE) committee, where it will then be sent on to the full parliament. And, if nothing is done, it could be adopted without even a vote in a plenary session by the Parliament itself. I feel strongly that if the open source industry doesn’t take a stand now, it will become law and the open source community as we know it will be no more.   

    There are two main problems with the proposed CRA: It discourages commercial support of open source and imperils vulnerability disclosure.

    CRA Discourages Commercial Support of Open Source

    The revised CRA offers new cybersecurity requirements for hardware and software products, much like the U.S.’s National Cybersecurity Strategy does. It calls for software vendors and producers to understand what components are in their software and to be able to recall software that is affected by a vulnerability. But, unlike the recently released details for the U.S. strategy, it seems to be trying to call out certain open source projects from foundations and large companies. By doing so, it potentially impacts every open source project, which creates a web of issues.

    It goes without saying that open source projects rely heavily on volunteers, individual contributors and small teams who often work without significant resources or financial support. The support that foundations and contributors do get often comes from commercial entities who have adequate resources to provide developer time to give back to the community.

    The current CRA text only excludes OSS software that has no commercial activity around it. Unfortunately, it defines commercial activity in part, this way:

    “where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.”

    This can be read to mean that if the main contributors are not unemployed, then the project is commercially tainted. It does not clarify what was probably intended—that the employer fully controls the project here.

    Additionally, it says:

    “Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.”

    The first part is acceptable, but recurring donations from commercial entities are the upside of contributing back to open source. This may force the projects to reject large contributions to avoid becoming “tainted,” and will likely cause commercial entities to enact further bans on OSS contributions and pull their support entirely.

    Further, if the CRA is passed without proper exemptions, these developers and maintainers may face legal risks and liabilities for vulnerabilities found in code used in commercial products. The OSS developers have no visibility into how and in what instances their components are used; only the final manufacturer of the product has this visibility.

    The potential legal risk, without an upside, would discourage OSS developers from contributing to and maintaining open source projects. This situation not only undermines the spirit of open source but could bring about an open source crisis and isolate the EU from the rest of the world. Non-EU open source producers will avoid the EU market, meaning no access to Linux, Apache, Kubernetes and many other projects. Repositories like Maven Central, npm and PyPi may be prompted to ban EU consumption to avoid being considered a distributor. EU projects concerned about liability could pull their source code off the internet, and EU businesses may be forced to halt contributions to open source projects.

    CRA Imperils Vulnerability Disclosure

    The regulation also would require that vulnerabilities be disclosed to the European Union Agency for Cybersecurity (ENISA) within hours of discovery, whether or not a fix is available. This would make it difficult to conduct coordinated disclosure—where researchers give vendors time to develop security patches before vulnerabilities are disclosed publicly. This would increase the chances that bad actors will develop exploits for the vulnerabilities before they are fixed, putting every company that uses that software at risk. This would be an unfortunate outcome for a law whose purpose is to improve security of software.

    What Can we Do?

    As I mentioned earlier, time is of the essence since this measure is moving quickly and faces a vote this week. We need the community to take immediate action. GitHub and other industry bodies need to publicly oppose the proposed measure. EU developers, maintainers and others need to ask their European Parliament Members (MEPs) to investigate further and bring the voices of the open source community to the discussion.

    Legislators need to understand the importance of collaboration and the role of the global developer community in driving open source innovation. Open source projects underpin much of the software we use every day. It’s the lifeblood of the internet. Legislation that deters contributors would interfere with the open source community’s ability to maintain existing projects and deliver new software, impacting the tech industry, hurting the EU economy and compromising overall software security.

  • Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk today launched a platform for ingesting data from sensors, industrial equipment and internet-of-things (IoT) platforms so that it can be analyzed alongside data collected from IT environments.

    Announced at the company’s .conf23 conference, the Splunk Edge Hub extends the reach of the troubleshooting platform Splunk provides that increasingly involves various types of edge computing platforms.

    Tom Casey, senior vice president for products and technology at Splunk, said Splunk Edge Hub is designed to be deployed in those edge computing environments and reduce the total amount of data that needs to be transferred back to an instance of the Spunk analytics platform running in a data center or in the cloud.

    That approach makes it possible to remotely monitor everything from environmental conditions to identifying anomalies indicative of an outage that might be prevented. The overall goal is to unify visibility across IT and operational technology (OT) environments as these systems and applications become more integrated, said Casey.

    It’s not clear how quickly that integration is occurring, given the historic cultural divide that has existed between IT and OT teams. But with the rise of digital business transformation initiatives, the data collected from edge computing platforms is increasingly being incorporated into a wide range of applications deployed at the edge, in local data centers and in the cloud.

    In general, observability tools are being used to not only improve processes but identify and block suspicious activity. Of course, OT teams have been monitoring edge computing platforms for decades, but observability platforms make it feasible to interrogate logs, metrics and traces to hopefully discover issues before there is a disruption to services. The challenge, of course, is that not everyone on either the OT or IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue. The Splunk approach essentially leverages the skillset of IT professionals that have mastered its platform to address that issue; something most OT professionals are not going to be able to do using their existing tools and platforms.

    One way or another, DevOps teams will soon need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than responding after a metric that OT teams are monitoring has already exceeded its threshold.

    In the event there is still an issue, observability platforms should also reduce mean-time-to-remediation (MTTR) as visibility into IT environments, including edge computing platforms, is improved.

    It’s not likely that OT and IT teams will ever be completely unified, but as observability platforms continue to evolve, there will be much greater opportunities for collaboration.