Author: Mitch Ashley

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

  • We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves.

    We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves.

    After graduating with degrees in computer science and business in hand, I entered the software industry with the energy and optimism of someone ready to create great software. My first job wasn’t called “software developer”—I was hired as a systems engineer. And that title mattered, a lot more than I first realized.

    Right after being hired, I was sent through a formal systems engineering program and was immediately placed on a project that would become the foundation of a new division: Future Banking Systems. After two years of heads-down redesigning and building banking systems in Garden City, New York, I was shipped to Dallas, Texas, for an “exciting opportunity” in a new group just being formed.

    Turns out the new group began with me and one salesperson, starting from zero, to form the foundation for a group that would create banking systems for an industry experiencing massive disruption due to deregulation. Our current customers were disappearing because of acquisitions, which were rolled up to become financial institutions that were beyond the scale and capabilities of our current products and business model.

    Inventing Without A Net

    There was no approved business plan. No product definition documents. No product roadmap. No backlog. Just a vision document, leaders with foresight standing beside us, and the knowledge that the industry was headed somewhere new and our current path wouldn’t get us there. However much we thought it would cost, we instinctively knew it would probably cost 4x more. It was our responsibility to build systems for much larger financial institutions in an industry still very much in flux.

    We weren’t just creating next-gen banking applications. We were inventing systems for where the industry was going to be, not where it was. It was early, messy, and it was foundational. And it eventually led me into my first experiences with AI, developing in Lisp, Prolog, and expert systems while teaching database theory. Those formative experiences taught me something that’s stayed with me ever since: Creating software isn’t just about shipping code. It’s about inventing what comes next.

     

     

    That mindset—the instinct to look ahead, to build with intent—is what real engineering is about.

    Today’s AI Moment

    Fast forward several decades…We’re now in one of the most disruptive and transformative moments in software history. AI can write code, scaffold entire applications, generate test cases, and devise solutions to problems in seconds. Developers are using copilots, models, and mega-prompts to accelerate their work at a pace we’ve never seen. And agents are coming online, backed by models with reasoning capabilities, to automate development tasks and tackle harder problems.

    And with this combination of exuberant expectations and feverous innovation in AI, comes a familiar claim: “We won’t need developers anymore.”

    I couldn’t disagree more.

    Yes, AI can generate code. But just code isn’t the application, system, or product. Underlying every working application is a complex system. There are architectural decisions, engineering challenges, design trade-offs, failure modes, built-testing, security constraints, integration boundaries, long-term lifecycle concerns, and, oh yes, operability. Those don’t just come from better context and prompts.

    AI massively expands what’s possible. And software development is the landing zone for AI innovations. (See Tech Vendors See the Future – Software Development Is the Agentic AI-Proving Ground.) But someone still has to know what to build, why to make it, when to create what, and for whom, and how to keep it working when the world around it continuously changes. Today’s design decisions are tomorrow’s technical debt.

    What Software Engineering Really Means

    Leading software teams taught me that engineering is the art behind software. It’s where experience, discipline, creativity, and instinct converge.

    When a team is deep in shipping the release with heads down, checking in code, solving bugs, driving toward delivery, engineering leaders raise periscope. You have to scan for the problems that haven’t surfaced yet, the threats and opportunities forming at the edge of the horizon, and verify that our instrumentation matches course, depth, and speed. That’s engineering. It’s not just watching the project plan or tracking how many issues are in Jira. It’s reading the signals others might miss.

    I’ve learned to trust that instinct: the kind of bugs we’re finding, the questions we’re not asking, the problems we haven’t had to solve yet. These are clues. They tell me if we’re still on track, or if we are behind, even when the project status says otherwise. Engineers know to pay attention to how we’re progressing, not just what we’ve done and how fast.

    Engineering is more than shipping by a deadline. It’s knowing when the real blockers will hit and deciding when to face them. It’s applying instinct in tangible ways: adjusting the design, pulling forward a hard dependency, probing deeper when something hard is too easy. This isn’t about perfectionism. It’s about intent. It’s about leading a system into existence, not following a script or just building what’s asked.

    We Lead the Loop

    I’ll say it again: I take issue with the idea that AI will simply replace developers. We hear the phrase “human in the loop” tossed around like it’s some kind of failsafe. But that’s not what this is.

    Humans aren’t destined to just be in the loop, supervising AI. We lead the loop, and where the loop is going.

    We define the problem. We decide what great, good, and bad looks like. We understand when to trust, when to probe, when to double-check, and when to ask if we are asking the right questions. We raise the periscope. And that’s what this moment means more than ever.

    Skating to Where the Puck Will Be

    AI is where the puck is. But engineering? That’s how we skate to where the puck will be.

    And more than that, it’s how we set the puck on a new arc entirely. That’s what we’re here to do now: not just follow the capabilities of AI, but lead us into new innovations in how software is created, new architectures, new apps, and systems we wouldn’t have imagined. We are the force. AI is the force multiplier.

    That’s what excites me about this moment. We’re not automating ourselves out of relevance. We’re stepping into a higher role: engineers with expanded reach, clearer intent, and tools that extend our vision—not replace it. The AI IDE of the (near) future looks more like the game Starcraft, engaging through language, voice, and keyboard, versus today’s code editor and NLP interface hybrid.

    We’re Being Called Forward

    For those of us who’ve built real systems, who’ve led teams through impossible delivery schedules, who’ve watched the intangibles reveal deeper design flaws—we know what this era asks of us.

    It’s not about writing every line. It’s about knowing that what we are doing ultimately matters.

    It’s about being the one who sees the storm before it hits. The one who adjusts course, not because it’s easy, but because it’s necessary.

    AI will continue to evolve. And so will we. So will all the roles across the software development lifecycle. AI is raising the bar for engineering, but remember…

    We lead the loop.

     

    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.

  • Internet Performance Monitoring Wins the Day

    Internet Performance Monitoring Wins the Day

    We’ve spent years refining our ability to monitor systems, applications and networks, yet businesses still struggle with performance issues. The problem isn’t a lack of data—it’s too much of it. IT, network and cloud operations organizations are overrun with massive amounts of monitoring, performance and telemetry data. So much so, we must move for dashboards and alerts to metrics and KPIs that tie directly to business impact metrics and customer experience KPIs.

    In my recent conversation with industry leader Mehdi Daoudi, CEO of Catchpoint, one thing is clear: Performance monitoring must evolve to account for the modern reality that connectivity across networks, the Internet, and Internet-based resources outside of IT operations have a profound effect on the performance of any application.

    Key Takeaways: Modern applications performance is intrinsically linked with the performance of Internet and Internet-based resources, making Internet Performance Monitoring vital to meeting business and customer expectations. By extending observability and monitoring beyond internal systems and networks, organizations are better equipped to reduce downtime, optimize the user experience, and ensure their digital service delivery truly wins the day.

    Moving Beyond Traditional Monitoring

    For decades, organizations held the mindset that more data will result in better insights. However, this often creates the opposite effect. As Mehdi Daoudi points out, companies end up drowning in a sea of metrics, trying to extract meaningful insights from overwhelming amounts of information. Instead of enabling faster issue resolution, this data overload slows teams down.

    Mehdi’s combined experience at DoubleClick, Google, and Reuters shaped his view that performance monitoring isn’t just about application performance—it has to extend beyond internal infrastructure to include the Internet. Internet Performance Monitoring (IPM) takes a more holistic approach by accounting for everything from third-party services to ISP networks, CDNs, DNS, and even cloud providers.

    Internet Performance – Beyond Uptime and MTTR

    It’s time to redefine what success looks beyond monitoring, uptime and mean-time-to-recover (MTTR). Today’s users have zero tolerance for a poor user experience. If an application or website takes too long to respond, it might as well be down. In many cases, it’s too easy to switch to an alternative mobile app, site or SaaS solution when the current choice doesn’t deliver.

    Mehdi’s philosophy behind Catchpoint of “monitor what matters from where it matters” aligns with today’s reality. Businesses must monitor the end-user experience, not just the backend infrastructure and application stack. Synthetic monitoring, coupled with real-user monitoring (RUM), provides a clearer picture of end users’ actual experience, helping teams optimize for speed and reliability.

    Beyond just user expectations, performance also directly affects business outcomes. Studies consistently show that faster websites and applications lead to better customer retention, higher conversion rates, and improved revenue. With so many third-party services and dependencies in today’s digital stacks, understanding and controlling performance holistically is more critical than ever.

    Catchpoint’s IPM service is designed to go beyond application monitoring, performance or uptime by actively testing performance across the entire delivery stack. This holistic approach helps businesses pinpoint problems often before they escalate into major customer and business disruptions.

    AI’s Role in Performance Intelligence

    Artificial intelligence (AI) is an essential tool in the modern IPM stack. AI-driven analytics help organizations cut through noise and focus on the signal, prioritize real issues, and automate response strategies. With platforms like Databricks and Snowflake enabling real-time data analysis, AI is making correlating performance insights with business outcomes easier.

    AI reduces alert fatigue that plagues IT and Ops teams. Teams can focus on solving meaningful problems faster and with greater precision. AI can also predict potential issues before they escalate, allowing companies to take preventative action rather than waiting for a crisis to unfold.

    The Future of Monitoring: A Business-Centric, Delivery Stack Focused

    The core takeaway from my discussion with Mehdi is that monitoring isn’t about technology—it’s about business and customers. Companies must align their performance monitoring strategies with their business goals.

    Organizations can adopt a proactive IPM approach and gain deeper visibility into the entire customer experience and digital stack. This ensures that not only are applications working as expected, but that third-party services, global internet conditions, and external integrations are all functioning optimally as well.

    This shift also means that business and technical leaders need to work more closely together. Performance monitoring must be part of the broader conversation about business growth and customer experience. Organizations that prioritize this alignment will be better positioned to compete in an increasingly digital-first world.

    How Internet Performance Monitoring Wins the Day

    Catchpoint’s vision for Internet Performance Monitoring is one promising way to ensure your performance monitoring wins the day. By extending monitoring beyond internal infrastructure to the entire internet ecosystem, companies gain the proactive insights they need to ensure seamless digital experiences, reduce downtime, and optimize performance where it matters most.

    For information about Catchpoint, visit the Catchpoint blog and their latest SRE Report.

    [This was a conversation packed with great insights, and if you haven’t already, be sure to check out the full interview on DevOps Dialogues.]

  • DevOps Must Learn From CrowdStrike’s Outage

    DevOps Must Learn From CrowdStrike’s Outage

    The CrowdStrike outage on July 19, 2024, is a stark reminder of DevOps practices’ critical role in deploying updates to maintain the security and reliability of applications and systems. While the underlying software defect was the immediate cause, the broader issue lies in the deployment process that allowed a severe flaw to impact a global customer base.

    Key Takeaway: To maintain trust and reliability in today’s complex software, security, cloud and data center ecosystem, we must prioritize robust, measured deployment strategies.

    The ability to rapidly deploy software updates across large, diverse environments is necessary for many software offerings. Updates can have unintended and, rarely, catastrophic consequences if done improperly or without diligent governance. The CrowdStrike incident highlights the importance of adopting more sophisticated deployment strategies—such as staggered, A-B, canary and phased rollouts—to minimize the blast radius of any potential defects. By initially releasing updates to a smaller subset of systems, organizations can validate changes in real-world conditions, catching issues before they affect the entire user base. Then, the update can be released in stages to increase the number of customers. This approach significantly reduces the risk of widespread disruptions and ensures that problems are contained and addressed quickly.

    Additional Resources

    Let’s move beyond this single CrowdStrike incident and focus on the lessons we need to learn to avoid repeating them in the future. As software delivery becomes faster and more automated, the need for meticulous, well-orchestrated deployment processes has never been greater. It’s not just about preventing the next outage; it’s about building a culture of reliability and accountability in every step and layer of the software supply chain. The urgency of this need cannot be overstated.

    Customers of software vendors bear a crucial responsibility in ensuring their systems remain secure and reliable. They should not rely on automatic updates without oversight, as doing so can leave their environments vulnerable to unforeseen issues. Organizations need to implement their own vetting and validation processes, testing updates in controlled environments before widespread deployment. This added layer of scrutiny helps catch potential problems early and prevents disruptions from unquestioningly trusting every update. In this way, customers play an active role in maintaining the integrity of their systems and minimizing risks.

    This is our call to action: To maintain trust and reliability in today’s complex software, security, cloud and data center ecosystem, we must prioritize robust, measured deployment strategies.

     


    Mitch Ashley is Chief Technology Advisor with The Futurum Group and CTO of Techstrong Group’s tech media platforms covering DevOps, cybersecurity, AI, cloud native, cloud infrastructure, platforms and ITSM.

    Mitch’s analyst research is available on FuturumGroup.com and TechstrongResearch.com. 

     

  • DevOps Unbound Special Edition from KubeCon Paris 2024 – DevOps Unbound EP 44

    DevOps Unbound Special Edition from KubeCon Paris 2024 – DevOps Unbound EP 44

    During this special KubeCon + CloudNativeCon Europe 2023 edition of DevOps Unbound , Alan Shimel and Mitch Ashley are joined by Martin Klaus, Tricentis VP Product Marketing. The trio discuss the progress software testing has made during the rise and adoption of DevOps and cloud native. Adapting to increased delivery velocity and modern cloud native software architecture are but a few of the strengths testing teams continue to build up along with testing AI/ML and generative AI within applications.