Tag: microsoft

  • Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Development rarely follows one straight path. You sketch ideas, prototype, test, swap tools, iterate, and repeat. The increasing availability of free, limited-use AI tiers and locally run open-source AI LLMs is accelerating that loop. These tiers are not marketing fluff. They are practical on-ramps for developers and engineers. They offer the freedom to test, compare, and refine without upfront cost.

    Free Tiers For The Taking

    GitHub provides a free Copilot tier: up to 2,000 code completions per month, plus 50 premium requests (chat / “agent mode”) interactions. Available in VS Code, Visual Studio, JetBrains IDEs, and more. It includes access to Claude 3.5 Sonnet and GPT-4o models. (https://github.com/features/copilot/plans, https://docs.github.com/copilot/concepts/copilot-billing/about-individual-copilot-plans-and-benefits)

    Anthropic’s Claude is free to use on the web, iOS, Android, and desktop with usage limits. Its API is not free. (https://www.anthropic.com/pricing, https://docs.anthropic.com)

    OpenAI’s GPT-5 is available to free ChatGPT users with strict usage caps. Its API requires prepaid credits, minimum $5. (https://www.wired.com/story/openais-gpt-5-is-here, https://help.openai.com/en/articles/8264644-how-can-i-set-up-prepaid-billing)

    New AWS accounts get up to $200 in credits valid for six months. Generative AI services like Bedrock move to pay-as-you-go after that. (https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan)

    Google Cloud AI Studio and Firebase are free to access. The Gemini API has a free tier with lower rate limits; paid tiers offer higher capacity. (https://ai.google.dev/gemini-api/docs/pricing)

    Cursor offers a free plan with usage limits. Windsurf provides monthly prompt credits across free and paid plans. (https://cursor.com/pricing, https://docs.windsurf.com/windsurf/accounts/usage)

    Why This Matters to Developers

    Flexible Model Switching: You can test multiple models (GPT-4o, Claude) without changing workflow or integration. That removes friction from choosing the best fit for your task.

    Rapid Prototyping: No billing setup. You can try ideas, logic paths, and prompt styles immediately.

    Cost-Effective Scaling: Validate with free tiers. When it works, choose paid tiers intentionally, not by guesswork.

    Hybrid Model Approaches: Use GPT-5 or o1 for reasoning tasks, then cheaper models like Llama for bulk processing. Free access to each lets you refine that pipeline.

    AI in Your DevOps Pipeline

    Free models pair neatly with toolchains:

    • GitHub Actions could use a free model to auto-generate release notes, analyze test failures, or lint code.

    • Microsoft Azure DevOps can use GitHub Copilot Chat and Azure OpenAI Service to assist in pipeline creation, YAML authoring, and automated documentation generation.

    • Google Cloud Build can use Gemini to generate deployment docs or config templates.

    • AWS CodePipeline could incorporate Bedrock calls for compliance checks or IaC validation.

    • CLI tools across platforms can invoke these models for tasks like refactoring YAML, generating manifests, or annotating dashboards.

    These are just a few examples of how these tools can be used with AI models. Running these in staging pipelines gives you low-risk experimentation before you roll out to production.

    Go Local

    Open-source and locally run LLMs such as OpenAI’s GPT-OSS, Meta’s Llama 3, and Mistral’s Mixtral are giving developers new options for building AI-driven applications without relying entirely on cloud APIs. These models can be downloaded, hosted on personal hardware, or deployed within private infrastructure, allowing full control over data, latency, and customization.

    Running models locally means teams can experiment with fine-tuning for domain-specific tasks, integrate AI into environments with limited internet connectivity, and meet strict compliance or privacy requirements.

    While local models may not match the scale or capability of their largest cloud-based counterparts, they offer a powerful balance of cost efficiency, adaptability, and independence that can be especially valuable for development, testing, and edge computing scenarios.

    Who Else Should Care

    It’s not just about developers: Test Engineers can generate synthetic test data, edge-case inputs, and test scripts. DevOps Engineers can automate pipeline scaffolding, log review, and incident summaries. Platform Engineers can prototype developer automation, self-service templates, and internal documentation.

    Getting early hands-on experience helps you understand where AI adds value and where it doesn’t.

    If you code, automate, build pipelines, test, or run platforms, start exploring these free AI tiers today. Plug models into your editor, Actions workflows, test frameworks, and CLI tools. Use them on real tasks, not just sample prompts. Track what works, what stumbles.

    Experimentation costs almost nothing. Delay could cost your team time and innovation.

    Recent articles by Mitch Ashley:
    Kubernetes, AI, APIs, and YAML – A Future 2.0?
    We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves
    AI and You: Don’t Wait… Or Be Weight

     

    Mitch Ashley is VP and Practice Lead of Software Lifecycle Engineering at The Futurum Group. The voice of “AI across the SDLC”, Mitch is a serial-CTO, speaker, advisor, entrepreneur, and product creator. He leads analyst coverage of the Software Development Cycle (SDLC), with emphasis on AI-native and agent development, cloud-native, DevOps, platform engineering, and software security.

    See Mitch’s analyst research on the Futurum website.

    Subscribers can access Mitch’s Software Engineering Lifecycle practice, decision-maker data, insight reports, and advisories through the Futurum Intelligence Platform.

  • Microsoft Previews Additional Copilot Tools for Azure

    Microsoft Previews Additional Copilot Tools for Azure

    At its Ignite 2023 conference, Microsoft this week previewed Copilot tools to simplify the management of the Azure cloud service along with a tool that streamlines the building and deploying of artificial intelligence (AI) applications on the Azure platform.

    In addition, Microsoft launched Microsoft Copilot Studio, a low-code tool that automates the process of creating data integration plugins and adding custom copilots within the Microsoft Copilot for Microsoft 365 tool that Microsoft previously launched.

    Microsoft Copilot for Azure leverages large language models (LLMs) to enable IT teams to use natural language to create, configure, discover and troubleshoot Azure services. It also enables IT teams to create complex commands, ask questions and optimize costs.

    Erin Chapple, corporate vice president for Azure Core at Microsoft, told Ignite attendees that Microsoft, along with a handful of customers, is already using Microsoft Copilot Azure to manage Azure infrastructure.

    In the long term, it’s clear that Microsoft is moving toward streamlining the building and deployment of AI applications using Azure AI Studio, a framework for invoking the AI models that Microsoft makes available on the Azure platform. The goal is to make it possible for organizations to create their own copilots based on AI models they have trained.

    It’s still early days in terms of organizations leveraging AI models to build applications, but it’s already apparent that DevOps and machine learning operations (MLOps), along with data engineering and cybersecurity best practices, will need to converge. Microsoft is making a case for Azure AI Studio as the framework that will enable IT organizations to achieve that goal.

    Of course, Microsoft is not the only provider of IT infrastructure resources with similar ambitions, but thanks to its investments in OpenAI and the acquisition of GitHub, it is furthest along in terms of defining a framework for building AI applications at scale. Last week, GitHub previewed an extension of the Copilot tools it already provides to help developers write code that leverages generative AI to automatically propose an editable plan for building an application based on natural language descriptions typed into the GitHub Issues project management software. Copilot Workspace will generate editable documents via a single click that can be used to create code that developers can then visually inspect. Any errors discovered by application developers or the Copilot Workspace platform can also be automatically fixed.

    At the same time, GitHub has extended the scope and reach of Copilot Chat to make it simpler for developers to use natural language to discover issues in their code base.

    Generative AI is already having a massive impact on the rate at which applications are developed, but that code still needs to be reviewed. Chat GPT is based on a general-purpose large language model (LLM) that is trained by pulling in code of varying quality from all across the web. As a result, code generated by the platform might contain vulnerabilities or be inefficient. In many cases, professional developers still prefer to write their own code.

    Of course, not every programming task requires the same level of coding expertise. In many instances, ChatGPT will generate, for example, a script that can be reused with confidence across a DevOps workflow. There is no shortage of mediocre developers who are now writing better code thanks to tools such as GitHub Copilot, and soon, domain-specific LLMs will make it possible to consistently write better code based on validated examples of code.

    The next challenge is going to be finding a way to manage increased volumes of code. There is no doubt that AI will be applied to the management of DevOps pipelines, but for the moment, at least, the pace at which AI is being applied to writing code is already exceeding the ability of DevOps teams to manage it.

  • Nobl9 Allies With Microsoft to Simplify SLO Creation

    Nobl9 Allies With Microsoft to Simplify SLO Creation

    Nobl9 this week revealed it has integrated its reliability center platform for managing service level objectives (SLOs) as code with the Microsoft Azure Monitor service to make it simpler to both create and track service levels.

    The Nobl9 Reliability Center provides access to dashboards for a single source of truth about the state of reliability in an application environment based on the metrics collected from the SLOs that have been defined.

    Nobl9 Chief Growth Officer Kit Merker said the integration with Microsoft Azure Monitor is the first in a series that will ultimately make it easier to define SLOs using historical data collected by third-party tools.

    The Nobl9 Reliability Center is already integrated with more than 50 DevOps, observability and incident management tools through which it collects metrics, events, logs, traces, alerts to track incidents, releases, rollbacks, runbooks and other documentation.

    Those integrations will ultimately make it simpler for IT teams to create SLOs using historical data that today are still challenging to define from scratch, noted Merker. In fact, the data tracked by Nobl9 can be used to automate remediations via those integrations, he noted.

    As more microservices-based applications are built and deployed, it’s becoming more challenging to maintain SLOs across applications that have many more dependencies than legacy monolithic applications. Each feature and application programming interface (API) added over time conspires to adversely impact performance. It‘s not so much that any given service will outright fail as much as it is determining where degradations are occurring that result in SLOs not being met.

    Ultimately, each IT team needs to provide some sort of objective benchmark that assesses their overall effectiveness at delivering application services by making it simpler to track whether SLOs are achieved and maintained. Not every service needs to necessarily meet a stringent requirement. Instead, IT teams need to have confidence in the fact that, on average, certain levels of performance are being consistently maintained.

    That’s crucial because as more organizations depend on software to deliver digital services, any disruption is likely to have a direct impact on profit and revenue. As such, the reliability of application environments has become a major concern in an era where IT teams are now trying to manage distinct services rather than individual applications.

    The challenge and the opportunity now is to find a way to proactively reduce that stress by programmatically managing SLOs as code rather than having to overprovision infrastructure resources to ensure maximum availability at the highest cost possible. At a time when more organizations are encountering economic headwinds, that’s no longer a luxury they can afford.

    Each organization will need to determine for themselves how aggressively they need to manage SLOs. Of course, SLOs as a concept have been around for decades, but with the rise of digital services that span multiple organizations, the level of reliability DevOps teams are expected to provide is now being written into business contracts. Not surprisingly, the overall level of associated stress DevOps teams are experiencing has correspondingly increased.