devopsy.kinsta.cloud

Category: DevOps Toolbox

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

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

  • Navigating the Rise of AI-Generated Code in Software Development

    Navigating the Rise of AI-Generated Code in Software Development

    The year 2023 saw the rise of many technologies and innovations, but none quite as prominent as generative AI. Trained on vast amounts of data, these models are designed to “generate” the next sequence of values based on inputs and create novel content for various purposes. The emergence of generative AI has forced industries to rethink how they operate and where adjustments should be made. A recent study from ISG indicates that financial services are the leading industry for generative AI adoption, making up 24% of total use cases. This is followed by manufacturing at 14%, healthcare and pharma at 12% and business services at 11%.

    More recently, organizations have started contemplating generative AI’s impact on software development and its ability to effectively generate code. AI-enabled tools will have a major impact on software development, increasing the volume and velocity of code delivery and innovation. However, there are ethical and practical guardrails that need to be considered.

    Key Capabilities of Generative AI in the SDLC

    The advantage of AI tools lies in their ability to enhance the software development workflow by automating repetitive tasks. Mundane and time-consuming boilerplate code generation or routine code reviews can now be handled by the same machines that we are writing the programs for. This not only accelerates the software development lifecycle (SDLC) but liberates developers from monotonous tasks, allowing them to focus on more creative projects that require human insight.

    For developers, the strength of AI-enabled tools lies in their ability to expedite the development process. By harnessing machine learning (ML) algorithms, AI can analyze vast datasets, find patterns and generate simple code quickly, often requiring numerous iterations to get it right — hopefully! But at its core, the benefit of AI-enabled tools stems from the premise that it’s easier to refine a set of initial ideas than it is to generate them. In other words, generative AI models create the “sparks” that a good developer can turn into a full creative process.

    Challenges, Concerns and Ethical Considerations

    As the adage goes, there are two sides to every coin. While AI tools hold the power to provide immense benefits to developers, they also introduce an array of risks that cannot be overlooked:

    ● Challenges in understanding context and user requirements: Despite its sophistication, AI struggles to grasp the intricacies of specific project contexts and the diverse needs of end-users. The contextual understanding that human developers possess, gleaned from experience and intuition, is still a facet where current AI encounters hurdles.
    ● Potential security risks: The automated nature of AI-generated code introduces potential security risks that demand careful consideration. While AI algorithms strive for efficiency, they may inadvertently generate code with vulnerabilities. Addressing security concerns requires ongoing vigilance, thorough testing, and the incorporation of robust cybersecurity measures to ensure the integrity of the developed software.
    ● Adapting to evolving technological environments: The dynamic nature of technology presents another challenge for AI-generated code, as rapid changes in programming languages, frameworks and methodologies require an adaptive approach. AI models may struggle to seamlessly transition to new technological advancements, potentially causing compatibility issues and requiring continuous updates to maintain relevance.

    It’s important to note that developers will not be the only ones affected by AI’s integration into the SDLC. Security teams are barely keeping pace now, and in many organizations, they’ve become the bottleneck. Increased developer velocity will put security teams under even more pressure—the volume of scans, the range of vulnerabilities and the patches that need to be applied are all guaranteed to skyrocket.

    Automation Alone is Not Enough; We Still Need Human Developers

    While the introduction of AI marks a significant milestone in the evolution of software development, it’s essential to recognize the nuanced interplay between automation and human ability. Rather than replacing human expertise altogether, generative AI is poised to augment and complement the skills of developers. Human creativity, critical thinking and the ability to navigate complex problems will continue to be invaluable assets in the development process — true potential only appears when collaborating seamlessly with human developers, blending the efficiency of automation with the creativity and problem-solving skills inherent to human intelligence.

    Looking towards the future of software development, the trajectory of generative AI presents intriguing possibilities. It has become increasingly clear that the rise of AI-generated code is not a story of replacement but one of enhancement. While AI brings undeniable efficiency and automation to certain aspects of coding, the role of human developers is still irreplaceable. The understanding of context, the intuition required for creative problem-solving, and the adaptability to evolving technological environments are hallmarks of human expertise. These are facets that, as of now, AI struggles to replicate.

    As we embrace the future of AI-generated code, let us not forget the essence of our craft. The evolution of technology is inevitable, but it is the human touch, ingenuity and ethical foundation that will define the software landscape of tomorrow.

    Image courtesy of Josh Calabrese via Unsplash

  • Self-Hosting is Dead. Hybrid is the Way to Go

    Self-Hosting is Dead. Hybrid is the Way to Go

    If I scroll back through my photo library, it’s astonishing how few photos I have from before 2004. And in 2006 (and probably for a few years after that), I still kept every photo I had on the hard drive of my laptop computer. If I lost that laptop, those photos would be gone forever. At some point, I went through the process to back them up to an external hard drive.

    And then along came the cloud. At some point, I could give my pictures to Apple or Google and not worry about backups. There was always the possibility they could have a critical disaster and lose every wedding photo I had or all the early pictures of my kids (it could still happen). But as a father who takes way too many pictures of my kids, I no longer maintain an external drive of backups because the several terabytes of photos I have are sufficiently stored and backed up in the big cloud provider I pay to handle it. The SaaS solution in a cloud backup was more than sufficient for me.

    Camera Rolls and Data Centers

    Likewise, it wasn’t that long ago that any meaningful internet presence required a company to have a large server room and host their own infrastructure. That meant racks and racks of computers and an enterprise internet connection to make sure customers could access those racks of computers. Most services you relied upon had to be close by physically to deal with latency and ensure the experience worked for your customers.

    Logging and metrics were kept locally, as were backups. I’m sure I’m not the only one who remembers swapping out big tape drives for daily backups and storing them in large plastic bins somewhere we really hoped wouldn’t flood.

    If you were using a significant piece of software, you would need to self-host that software for many reasons—but the biggest reason was that shared infrastructure wasn’t a reality yet. There was no way to share hardware and no meaningful way to share software in a multi-tenant environment.

    IaaS, the Cloud, Automated Backups and SaaS

    Today, the infrastructure-as-a-service (IaaS, or “Cloud”) providers are offering everything from email hosting to Kubernetes-as-a-service (KaaS), from serverless to logging. They even make sure the software that enables your edge computing is obscured from you and managed by them (backups are automatic! And included in the price! And happen without a single person touching a tape drive!). This frees us up significantly to spend time shipping code and bits instead of fiddling with wires, CPUs and drives. It’s like shipping your photos to a SaaS photo storage provider—it takes the headache and the worry away. Yet when companies move to the cloud, many maintain the “old way” of doing things because they haven’t adjusted to the new reality yet.

    There is now no need to self-host your own email service. The cloud provides it, or you can use a third-party service that runs in the same cloud. Data proximity is no longer a concern, and latency won’t suffer. Similarly, there is no need to self-host your backups or even your logging service—because the cloud will provide it, and similarly, a third-party service is no longer a latency concern—that third party is probably hosted by the same cloud in the same region.

    This move to the cloud and shared infrastructure has been a game changer. SaaS is the name of the winning solution. Still, there will always be some companies with compliance or security needs that want to maintain data residency, just like there will always be people with such sensitive data or important family photos that no matter how safe and reliable the cloud is, they’ll insist on self-storage for photos and backups.

    The Hybrid Solution

    That’s why a hybrid cloud is the future of cloud-native solutions for complex enterprise applications and data. You host the data, but the SaaS provider hosts the application. The data stays under your control, but the SaaS firm updates the application regularly. Today, a large enterprise may have five engineers just to handle a self-hosted version of a logging app. At $180,000/year per engineer (a reasonable tech salary today), that’s almost a million dollars per year to maintain a software product that the vendor will gladly maintain for you.

    This is a simple shift, but it has only become a reality recently due to advances in technology, the things the cloud has enabled and the increased headache—now seemingly unnecessarily dated—of self-hosting (and then upgrading and patching) software built by a third party.

    With a hybrid cloud offering, you’re always using the latest version of the software because you’re using the software hosted and updated by the SaaS provider. There is no need to self-update, scale up or down or security patch a self-hosted install. The SaaS provider handles the compute and scaling required to make the service run smoothly. And you get the best of both worlds — zero software maintenance while still keeping your data in your own hands.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

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

  • Tabnine Extends Generative AI Testing Platform by Embracing RAG

    Tabnine Extends Generative AI Testing Platform by Embracing RAG

    Tabnine today revealed that its namesake generative artificial intelligence (AI) platform for creating test code can now surface more accurate and personalized recommendations based on specific code and engineering patterns.

    At the same time, Tabnine also announced that Tabnine Chat, a tool for interacting with the large language models (LLMs) at the core of the Tabine platform using a natural language interface, is now generally available.

    Data that resides in a codebase or an integrated developer environment (IDE) can now be used to extend the large language models (LLMs) on which the Tabnine platform is based using retrieval augmented generation (RAG) techniques. Previously, the Tabnine platform would only generate test code based on the data that Tabnine had exposed to its LLMs.

    Tabnine president Peter Guagenti said RAG makes it possible to provide additional contextual awareness for the test code generated along with documentation and explanations of the test code created. The overall goal is to leverage generative AI to make it easier to shift more responsibility for application testing further left toward developers, he noted.

    That approach enables developers to create and run more routine tests earlier in the software development life cycle, which should provide application testing teams with more time to run more complex tests before applications are deployed, added Guagenti. Rather than being a job killer, generative AI will eliminate rote tasks that most members of the DevOps team don’t really enjoy doing, he noted.

    Tabnine uses a mix of LLMs it developed with Google to apply generative AI to application testing. Unlike general-purpose LLMs, the ones used by Tabnine were trained using a narrower base of testing code that the company curated using tests made freely available on the internet.

    It’s now only a matter of time before generative AI is applied across the entire software development life cycle (SDLC). It’s not clear how automated testing will become in the age of AI, but the overall quality of applications should steadily improve as more tests are run. The goal is to make it possible to conduct more tests without slowing down the overall pace of application development.

    There continues to be as much irrational exuberance about AI as fear and loathing. Still, DevOps teams that committed early on to ruthless automation will naturally be at the forefront of adoption. The immediate challenge is assessing what functions will be automated and the impact those changes will have on the way DevOps teams are currently structured. Ultimately, the goal is to eliminate as many of the bottlenecks that conspire to slow application development and deployment while simultaneously improving the quality of the application experience.

    It may be a while before generative AI is pervasively applied across DevOps workflows, but one of the first places it will undoubtedly manifest is in test automation. The challenge and the opportunity now is determining how best to apply it in a way that augments DevOps teams that arguably have never had enough time to properly test code in the first place.