devopsy.kinsta.cloud

Author: Mike Vizard

  • Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

    Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

    Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

    The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

    That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

    That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

    The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

    Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

  • Cycode Acquires Bearer to Extend ASPM Platform

    Cycode Acquires Bearer to Extend ASPM Platform

    Cycode today announced it had acquired Bearer, a provider of a set of tools for static application security testing (SAST), discovering application programming interfaces (APIs) and identifying sensitive data.

    The provider of an application security posture management platform (ASPM) plans to integrate the Bearer tools into its core platform to enable DevSecOps teams to further consolidate tooling.

    Cycode CEO Lior Levy said the acquisition of Bearer gives Cycode access to a set of tools that take advantage of generative artificial intelligence (AI) to surface suggestions that enable DevSecOps teams to more easily secure modern applications based on, for example, a microservices-based architecture.

    Bearer achieves that goal by continuously scanning for application security issues as developers are writing code, he added. Overall, Bearer claims its approach to scanning is 31% faster than rival tools while simultaneously leveraging tools such as Bearer Assist, currently in beta, to provide more context concerning the level of risk to the business any issue discovered actually represents.

    Those capabilities will be infused into the Risk Intelligence Graph (RIG) that Cycode developed for its ASPM platform.

    Cycode earlier this year added generative AI capabilities to its platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments. The company uses the generative AI platform created by OpenAI to provide a natural language interface for RIG. As part of that effort, Cycode is making available an executive dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

    The company is at the forefront of developing ASPM platforms that continuously ingest data to identify and assess application security risks. Those platforms also provide a foundation for consolidating many of the tools that DevSecOps teams currently rely on to secure applications before they are deployed in production environments.

    It’s not clear how quickly organizations are embracing DevSecOps best practices, but given the number of vulnerabilities that continue to be discovered, there is still much work to be done. The challenge is that legacy tools that lack AI capabilities were not designed to enable organizations to practically shift more responsibility left toward application development teams that typically don’t have a lot of cybersecurity expertise, noted Levy. AI makes it possible to now provide those teams with the context required to address application security issues as they write code versus just before applications are deployed, he added.

    In theory at least, the applications deployed today should be significantly more secure than previous generations of applications. In effect, IT environments are steadily becoming more secure. Less apparent, however, is the rate at which modern applications are being deployed to replace legacy applications that are, all too often, rife with known vulnerabilities that cybercriminals can easily exploit. Given the rate at which vulnerabilities can be discovered and patched in those legacy applications, it may take the better part of the rest of this decade to address those issues once and for all.

  • StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    ServiceNow, Hugging Face and NVIDIA have once again combined their efforts to advance a generative artificial intelligence (AI) platform that has been specifically trained to generate higher quality code than rival approaches based on general-purpose large language models (LLMs) such as ChatGPT.

    StarCoder2 is a family of LLMs created by the BigCode community led by ServiceNow. Three iterations are starting now with a 3 billion‑parameter model trained by ServiceNow; a 7 billion‑parameter model was trained by Hugging Face, while NVIDIA built a 15 billion‑parameter model.

    The 3 billion‑parameter model is capable of matching the performance of the original StarCoder 15 billion‑parameter model.

    Nicolas Chapados, vice president of research for ServiceNow, said as AI research continues to advance, each successive wave of LLMs becomes more efficient. Each organization, depending on the use case and total cost, can then opt to deploy StarCoder LLMs either on a local machine or in the cloud. The more parameters an LLM has, the more infrastructure resources are needed to run any inference engine based on it.

    The StarCoder2 LLMs were trained using 619 programming languages and can be extended to, for example, provide summarizations of code. The foundation of StarCoder2 is a new code dataset called The Stack v2 that is more than seven times larger than version 1 of the dataset. In addition, additional training has enabled the model to understand low‑resource programming languages such as COBOL, mathematics and program source code discussions. Organizations can also fine‑tune models with industry or organization‑specific data using open source tools such as the NVIDIA NeMo platform or Hugging Face transform reinforcement learning (TRL) techniques. StarCoder2 was built using data under license from the digital commons of Software Heritage hosted by Inria.

    The overall goal is to provide development teams with LLMs that, in addition to being less likely to hallucinate, also generates code with much fewer vulnerabilities because the code generated is based on exampled vetted by the BigCode community, said Chapados.

    It’s not clear right now how much of the code finding its way into production environments is being generated by machines versus humans. However, as LLMs continue to advance, the percentage created by machines will undoubtedly increase. The challenge DevOps teams now face is determining how to apply AI to pipelines that will increase in number as codebases not only proliferate but also become inevitably larger.

    In the meantime, DevOps teams would be well-advised to become familiar with what type of LLM is being used to train the generative AI platforms being used to create code. The more general purpose an LLM is, the more likely it is to generate suboptimal code that DevOps teams are only going to need to eventually replace, especially if that code is consuming expensive infrastructure resources inefficiently.

    There is, of course, as far as generative AI is concerned, no going back at this point. The issue now is determining how to keep track of the provenance of all the code being generated to determine how best to fix it whenever needed.

  • Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

    As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

    In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

    Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

    In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

    Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

    In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

    More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

    Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

    Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

  • Logz.io Leverages AI to Identify Anomalies in Real-Time

    Logz.io Leverages AI to Identify Anomalies in Real-Time

    Logz.io this week revealed it has added a real-time anomaly detection capability to its observability platform that makes it simpler to correlate the impact IT events will have on business processes.

    This capability is based on artificial intelligence (AI) models trained using historical data collected via the Logz.io Open 360 platform.

    Logz.io CTO Asaf Yigal said this addition to the Open 360 platform enables DevOps teams to employ machine learning algorithms to identify anomalies in mission-critical processes that warrant further investigation. Armed with insights that go beyond simple IT infrastructure consumption metrics, it becomes possible to significantly reduce mean time to resolution, he added.

    Logz.io has been embedding AI models within its platform since last year. Still, this latest capability will enable organizations to further bridge a divide between IT and the business that has long plagued many organizations, noted Yigal.

    The ultimate goal is to make it simpler for DevOps teams to instantly identify any anomalous application behavior that represents a risk to the business, including cybersecurity events, he added.

    The AI capabilities that Logz.io has been steadily adding to its observability platforms are largely transparent to DevOps teams, said Yigal. Instead, Logz.io is embedding multiple types of AI models into its platform that can be invoked in much the same way any other capability is provided, he added. DevOps teams are not necessarily going to need to build their own models to take advantage of AI to observe application behavior at scale, noted Yigal.

    The goal is to surface those capabilities consistently at a level of cost organizations can afford, added Yigal.

    It’s not likely AI will replace the need for DevOps teams any time soon, said Yigal. After all, there is a reason AI models are referred to as co-pilots versus an automatic pilot, he noted.

    It’s not clear to what degree organizations today can correlate the impact an IT event is going to have on the business. But as organizations continue to realize how dependent they are on applications to drive digital processes, the need to bridge the historic divide between IT and the rest of the business has become more urgent. In fact, many of the product and brand champions that organizations now rely on to manage a business unit often have a background in DevOps.

    Of course, business professionals that are steeped in IT are still relatively rare but as advances in AI continue to make it simpler to understand how complex application environments function the number of users of an observability platform will naturally expand beyond IT. The challenge is presenting each stakeholder with a view into the IT environment that meets their specific requirements.

    It may take a yet before the divide between IT and the rest of the business is permanently bridged but with each passing year it gets narrower. The challenge and the opportunity now is making sure everyone on both sides of that divide understands the art of the possible today that only a few short years ago would have seemed impossible to achieve.

  • New Relic Streamlines Observability Data Management

    New Relic Streamlines Observability Data Management

    New Relic this week made available a live archives capability that provides instant access to historical logs for up to seven years and eliminates the need to rehydrate, reload, re-index or move data.

    At the same time, the company also announced its observability platform is now integrated with infrastructure and observability tools provided by Sentry Software to help IT teams reduce costs and collect additional sustainability metrics alongside logs, metrics and traces.

    Jemiah Sius, senior director of developer relations for New Relic, said overall, New Relic is moving to make it simple to analyze and store telemetry data regardless of when it was collected. For example, rather than requiring historical data to be accessed via a cold storage service in the cloud, the New Relic platform now makes that data available directly within the database that is at the core of its observability platform.

    That approach also provides the added benefit of not incurring ingress and egress fees for moving data in and out of cloud storage services, noted Sius.

    IT teams can simply create a New Relic Query Language (NRQL) to identify which logs to route to a live archive in as little as 30 seconds without having to add an additional log collector.

    The overall goal is to make it simpler to investigate incidents faster, given the urgency that is created whenever there is an outage or audit request that needs to be immediately addressed, noted Sius. That’s critical because DevOps teams are always for time, he added.

    In general, New Relic is reducing the overall toil associated that many DevOps teams encounter today when managing telemetry data. Rather than being confronted with a complex set of data engineering tasks, telemetry data from multiple applications and infrastructure platforms can automatically be collected, analyzed and stored.

    It’s still early days as far as the adoption of observability platforms is concerned, but there is already no shortage of options. The challenge is that in addition to logs, metrics and traces, IT teams are now starting to also track cost and energy consumption metrics. Observability platforms provide the means to centralize telemetry data that is only going to increase in volume as more applications are deployed. The challenge has been framing the queries needed to surface meaningful insights. Fortunately, with the rise of generative artificial intelligence (AI) tools that make it simpler to create queries, the overall level of skill required to invoke an observability platform is dropping. In effect, generative AI is making it possible to democratize DevOps best practices.

    Ultimately, existing DevOps teams should be able to manage highly distributed application environments without having to hire and retain a small army of additional software engineers. The issue is that, in many cases, the size of the overall code base is increasing rapidly as developers take advantage of various generative AI tools to help them write code faster. Hopefully, advances in AI will arrive soon enough to enable DevOps teams to cope with all that code before DevOps teams are inevitably overwhelmed.

  • Observe Inc. Adds Tool for Exploring Distributed Traces

    Observe Inc. Adds Tool for Exploring Distributed Traces

    Observe Inc. this week added a Trace Explorer tool to its namesake observability platform that makes it simpler to search, analyze and visualize billions of traces.

    Traces are being used with greater frequency to track how resources are being invoked across increasingly distributed computing environments. That capability provides DevOps teams with a level of insight into workflows that goes well beyond the logs and metrics that almost every IT team routinely collects.

    Observe Inc. CEO Jeremy Burton said the challenge now is providing IT teams with tools that make it simpler to affordably manage traces at scale to reduce mean time to remediation (MTTR). The Observe platform enables IT teams to store the traces they run in a data lake from Snowflake for 13 months versus other platforms that only store a trace for a few days, which then requires IT teams to rerun the same trace multiple times each time they launch an investigation.

    The overall goal is to encourage DevOps teams to launch more investigations to improve application performance by making traces readily available using low cost S3 storage from Amazon Web Services (AWS) that is accessed via the Snowflake data lake that makes it simpler to apply artificial intelligence (AI) to telemetry data.

    That approach makes it economically feasible for DevOps teams to not just resolve an incident but also provide the level of investigation required to accurately identify its root cause, said Burton. Because the cost of storing telemetry data is so high, DevOps teams that employ other observability platforms are not able to thoroughly investigate incidents because they lack access to telemetry data that their organization decided not to store because of cost concerns, he added.

    Most organizations are still mastering the nuances of observability platforms that enable them to query telemetry data that, in addition to being easier to collect using open source OpenTelemetry agent software, is also increasing in volume thanks to the rise of microservices-based applications. Each microservice now generates its own telemetry data that needs to be analyzed and stored. As microservices make application environments more complex, the need for tools to analyze all that telemetry data becomes more pronounced.

    As businesses become more dependent on software to operate, it’s now more than apparent that legacy approaches to monitoring IT metrics are no longer sufficient, said Burton.

    It’s not clear how quickly organizations are adopting observability platforms, but there is already no shortage of options. Given the current state of funding for startup companies in the IT industry, IT teams would be well-advised to research the level of funding the providers of these platforms have before deciding which vendor to rely on, noted Burton. Last year, Observe Inc. raised an additional $50 million in funding.

    Regardless of the observability platform selected, the one thing that is certain is that observability platforms infused with AI are changing the way IT is managed. The issue IT teams often encounter now is convincing the organization to fund the acquisition of these platforms at a time when budget resources in many organizations are already being stretched thin.

  • Survey: Significant Shift in IaC Tool Preferences

    Survey: Significant Shift in IaC Tool Preferences

    A survey of 350 IT professionals conducted by Firefly, a provider of a platform for managing cloud computing environments, suggests usage of infrastructure-as-code (IaC) tools is evolving rapidly in the cloud computing era.

    For example, more than 40% of the respondents reported that, to some degree, they are already using OpenTofu, an open source IaC tool that was launched as a fork of the Terraform IaC in the wake of changes to the software licensing terms it is made available under by HashiCorp. Well over half said they planned to use OpenTofu in the future. That compares to 60% using Terraform today, but only just over 20% said they planned to use Terraform in the future.

    The licensing changes HashiCorp implemented only affect third-party entities within a third-party platform. However, the survey indicates the number of end users affected by that change is more substantial than anticipated. A full 56% of respondents described the changes made to the Terraform license as disruptive.

    The survey also finds there is a lot more diversity in terms of the types of IaC tools being employed, with both the IaC tools from Pulumi and the open source Crossplane framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) also gaining traction. The report finds more than 40% of respondents are also using Pulumi, with well more than half planning to use that IaC tool in the future.

    Crossplane, meanwhile, is now being used by 40% of respondents, with 60% planning to adopt it.

    Conversely, the report also notes the number of organizations planning to migrate away from CloudFormation from Amazon Web Services (AWS) is rising. While well over 60% use AWS CloudFormation today, only a third plan to use it in the future.

    Cindy Blake, vice president of marketing for Firefly, said as organizations employ additional cloud platforms, IT teams are clearly looking for tools that make it easier to centralize the management of multiple computing platforms. That trend will only accelerate as more DevOps teams adopt platform engineering as a methodology for managing the building and deployment of applications at scale, she added.

    In fact, noted Blake, it’s already fairly common for IT teams to use two or more frameworks. The report finds 57% of respondents work for organizations that are using two or more frameworks. Overall, the report finds that more than 64% of respondents have also codified more than half of their cloud assets.

    The number of organizations employing IaC tools to programmatically manage infrastructure is only going to increase, said Blake. The report, for example, found that three-quarters of respondents either already are or plan to use IaC tools to configure software-as-a-service (SaaS) application environments. In the longer term, advances in artificial intelligence (AI) will make it simpler for organizations to achieve that goal. Open source tools such as AiAC, for example, already make it possible to leverage large language models (LLMs) to generate code. Those types of tools will eventually eliminate the need to master specific programming languages to provision IT infrastructure as code, noted Blake.

    It’s not clear how IaC tools within the context of DevOps workflow will evolve, but the one thing that is certain is that the number of types of tools being adopted has never been more diverse.

  • JFrog Extends MLOps Integration Efforts via Qwak Alliance

    JFrog Extends MLOps Integration Efforts via Qwak Alliance

    JFrog today announced it has integrated its DevSecOps platform with a managed machine learning operations (MLOps) platform from Qwak to advance collaboration between teams building and deploying multiple classes of software artifacts.

    This alliance comes on the heels of a similar Amazon Sagemaker alliance announced last month that also integrated a managed service for building artificial intelligence (AI) models provided by Amazon Web Services (AWS) with the JFrog Software Supply Chain Platform.

    Both machine learning operations (MLOps) platforms provide data science teams with a complete stack of curated tools required for building AI models from the ground up versus, alternatively, customizing AI models that were previously built.

    Gal Marder, executive vice president for strategy for JFrog, said integration with the Qwak platform makes it possible to manage the software artifacts created by MLOps teams alongside the rest of the software artifacts a DevSecOps team is already managing. That approach makes it possible to also detect and block the use of malicious ML models in addition to ensuring models comply with company policies and regulatory requirements, he noted.

    As it becomes apparent that more AI models will be directly embedded within applications, the need to integrate DevOps workflows with machine learning operations (MLOps) platforms used to create AI models is becoming more pronounced, said Marder.

    JFrog Software Supply Chain Platform can be used to provide both data scientists and developers with a single source of truth for securely managing software artifacts using a common repository to foster greater collaboration between teams that, in most cases, are still determining how best to collaborate, he added.

    The challenge is data scient teams typically train and deploy AI models every few months, while DevSecOps teams are often updating applications multiple times a month. Data science and DevSecOps teams, as a result, generally have distinct cultures, but in the long term, DevOps and MLOps workflows will eventually merge, said Marder.

    Most organizations are still trying to determine how best to operationalize AI using their own data. In the term, AI models are being invoked via application programming interfaces (APIs). Still, it’s also now only a matter of time before more AI models are embedded in applications to improve overall performance. The challenge is that AI models can’t be updated the same way other software artifacts are patched, so managing versions of AI models will require a different set of controls as one model replaces another. JFrog, for example, has developed versioning capabilities that can be applied to AI models in the context of a DevOps workflow.

    There is, of course, already no shortage of MLOps platforms, so DevOps teams should expect to see a wave of alliances being formed between the providers of these platforms. Less clear is to what degree those alliances might lead to mergers and acquisitions among the providers of those platforms.

    One way or another, however, AI models are coming to DevSecOps workflows. The only issue to be resolved is how best to manage their deployment alongside all the other types of software artifacts already moving through existing DevOps pipelines.