Forem: John Vester

The Future of Agentic AI

John Vester — Wed, 04 Feb 2026 16:37:52 +0000

The era of passive AI chatbots is ending. We are now entering the age of Agentic AI: systems that actively reason, plan, and execute tasks.

For organizations, this represents a potential leap in productivity, but it also introduces new engineering challenges. Moving from a simple prompt to a reliable agent ecosystem requires a new, robust architecture.

In this article, we’ll explore the anatomy of AI agents, how the Model Context Protocol (MCP) has finally solved the integration bottleneck, and how you can architect safe, scalable systems where humans and agents collaborate effectively.

What is an AI agent?

Some AI agents are simply a system prompt and a collection of tools that are sent to a model that does all the thinking. However, there are also more powerful AI agents that use the LLM to recommend and propose actions, then the AI agent runs its own code to perform functions such as:

• Control execution: state machines, task graphs, retries, timeouts

• Enforce policy: auth, scopes, RBAC, allow/deny rules

• Validate actions: schema checks, safety filters, sandboxing

• Manage memory/state: databases, vector stores, session state

• Coordinate agents: message passing, role separation, voting

• Handle failure: rollbacks, circuit breakers, human-in-the-loop

While a standard LLM (large language model) is passive and waits for your input to generate a response, an AI agent is active. It uses reasoning to break down a goal into steps, decides which tools to use, and executes actions to achieve an outcome.

Agentic AI systems initiate a session by sending an LLM a system prompt, which may include the definition of multiple agents and their tools. Some of these tools may allow agents to invoke other agents, manage the context itself, and even select the model for the next step.

	LLM Chatbot	AI Agent
Flow	User Input -> Model -> Output	User Goal -> LLM -> Reasoning/Planning -> Tool Use -> Action -> Verification -> Output
Summary	Gives you advice but you have to do the work.	You give the agents a goal and access to software, they come back when the job is done.

The mastery of building Agentic AI systems is finding the right mix of agents, tools, and prompts that allow the LLM to accomplish your goals while still providing adequate guardrails and verification.

To this end, managing the tools and other resources available to the AI agents is a major focus. This is where the Model Context Protocol (MCP) comes in.

The Model Context Protocol

MCP is an open standard introduced by Anthropic in November 2024. It standardizes how AI systems connect to external data and services.

The idea behind MCP is that all LLM API providers allow the LLM to invoke tools. Developers can benefit from a structured way to define those tools and make them available to the LLM in a uniform and consistent way.

Prior to MCP, the integration of 3rd party tools into Agentic AI systems added a lot of friction. But by providing a universal interface for reading files, executing functions, and handling contextual prompts, MCP enables AI models to access the data they need securely and consistently, regardless of where that information lives.

Since its release, the protocol has been adopted by major AI providers including OpenAI and Google, cementing its role as the industry standard for AI system integration.

MCP operates through a straightforward client-server architecture with four key components:

The host application such as Claude Desktop, modern IDEs, or your AI system.
The MCP client which establishes one-to-one connections from the host to a server, often a built-in capability of AI frameworks.
The MCP server which exposes tools, resources, and prompts.
The transport layer which manages communication between clients and servers.

MCP also opened the door to an ecosystem where 3rd party platforms expose their capabilities to AI agents by publishing their own official MCP servers. Large enterprises such as Microsoft, AWS, Atlassian, and Sumo Logic have all published MCP servers.

MCP solves an important problem, but it is just one among many for agents. Let’s look next at how to design safe Agentic AI systems.

Designing Safe Agentic AI Systems

Agentic AI can go catastrophically wrong. There are multiple risks such as:

Prompt injection that hijacks workflows to exfiltrate data or execute ransomware.
Privilege escalation via tool chaining that drains accounts or deletes production systems.
Infinite loops that burn millions in API costs.
Hallucinated actions that trigger irreversible trades or compliance violations.
Token Torching where malicious actors hijack token spend through MCP.

Agents are often entrusted with access to APIs, browsers, and infra systems. Without safeguards, this greatly amplifies your risks. Safe Agentic AI requires a “defense-in-depth” approach built on multiple overlapping layers.

Input validation, output auditing, and human-in-the-loop escalation form the verification backbone.
Decisions are never fully autonomous when the blast radius or financial impact is high.
Sandboxing and explicit permission boundaries prevent unauthorized access.
Each agent should receive a distinct identity with least-privilege credentials and scoped tokens, rather than inheriting user permissions.
Fault tolerance through retry logic, fallback models, and anomaly detection ensures that systems degrade gracefully under failure.
Deep observability implemented via standardized telemetry, structured logging, metrics collection, and real-time monitoring dashboards enables rapid detection and response.

Engineering effective multi-agent systems requires deliberate architecture design that incorporates one or more coordination patterns:

Centralized orchestration where a supervisor agent coordinates specialized workers and maintains global state.
Decentralized peer-to-peer communication enabling flexible agent-to-agent interaction.
Hierarchical delegation that organizes agents into levels of abstraction.

Development environments like Sumo Logic's Dojo AI (an Agentic AI platform for security operations centers) can help significantly, providing essential infrastructure for safely iterating on agentic systems before production deployment. Dojo AI is carefully curated according to its design principles and safeguards. Customers can use Dojo AI as is and they can build their own agentic AI environment (similar to Dojo AI) for their own AI-based core competencies. The Sumo Logic MCP server lets you run data queries and make Dojo AI agent calls when needed from your own AI agents.

Next, let's see some of the different ways people interact with Agentic AI systems.

How People Collaborate with AI Agents

Traditional systems follow a well-defined workflow and pre-programmed algorithms. User input and outputs are fully structured. Even in dynamic systems, user input can deterministically control the flow.

Agentic AI systems, however, are different. The LLM controls the flow (within its guardrails). Users provide initial intent and motivation, and later operate as approvers and a gating function. In particular, the free text conversation is novel.

So how do we best collaborate with these agents?

One of the most common ways to interact with AI agents is through chatbots, where you can exchange text, images, and files with LLMs and their agents. Voice conversations are also becoming more popular.

Of course, generic chatbots like ChatGPT, Gemini, and Claude Desktop are not aware of your agents out of the box. However, agents can be introduced as MCP tools.

Another interesting option is to build a Slack application allowing agents to join channels, interact with users, automatically monitor the channels, and automatically respond to events.

This is a rich environment as it allows humans and agents to collaborate smoothly. The Slack user experience already supports group channels and threads, so agents can add details such as their chain of thoughts or citations without cluttering the screen. Multiple human users can engage with each other and AI agents all in the same channel.

If you need even more specialized user experience, you could build a custom web, desktop, or mobile application for your agents.

You could even create a chatbot like Mobot, a Slack application integration, or a custom suite of agents like Dojo AI.

The Future of Agents

Perhaps the most important thing to understand about AI agents is that they are coming faster than you think. In the past, major technological revolutions like the personal computer, the internet, and mobile phones took decades to become ubiquitous and the pace of innovation was manageable. AI is different.

Many experts predict that in just the next few years, AI agents will be able to perform any knowledge work better than the best humans. They will unlock scientific discoveries and provide unprecedented productivity gains. Manual labor is not far behind, with humanoid robots making impressive strides powered by AI agents.

LLMs can already perform many tasks as well as humans, though they lack the ability to plan and operate over long time horizons, deal with complexity, and maintain coherence. But with a carefully constructed web of agents and a curated set of tools that collaborate over multiple iterations to accomplish long horizon tasks, these constraints are being removed. There is much innovation in this domain beyond just MCP such as agent orchestration, toolkits, and verification layers.

Industry Standardization

We’re starting now to see the standardization of techniques, tools, and formats for AI agents. For example, the Agentic AI Foundation (AAIF) is a new initiative under the Linux Foundation to ensure Agentic AI evolves in an open and collaborative manner. Its members include Anthropic, OpenAI, Amazon, Google, Microsoft and Block. It hosts several prominent agent technologies, including MCP, goose, and AGENTS.md.

There are other prominent open efforts as well, including Google's Agent2Agent (A2A) protocol and Agent Skills (also originating from Anthropic).

Dynamic User Experiences

The future of the user experience is all about generative UI. The LLM and agents will generate an appropriate UI on the fly depending on the query, user, conversation history, and more.

For example, if you ask about the stock market, rather than provide a generic overview of today’s business news, the AI system may decide to show a historical timeline and a pie chart with your current positions as well as links to relevant educational material. Everything will be tailored per user.

The Shift to AI Agents

The agentic shift is here. We’re moving from passive text generation to active, autonomous work. As we’ve seen, this shift requires more than just new models. It calls for a careful architecture.

To succeed, organizations should focus on:

Leveraging the Model Context Protocol (MCP).
Moving beyond simple prompts to a "defense-in-depth" strategy.
Designing interfaces, such as Slack apps and custom UIs, where humans provide the intent and agents handle the execution.

AI agents may soon outperform top human knowledge workers, unlock major scientific and productivity gains, and eventually expand into physical work through robotics. Understanding their basics is the first step to harnessing their power for your organization.

Have a really great day!

Effectively Managing AI Agents for Testing

John Vester — Thu, 18 Dec 2025 02:23:00 +0000

Large language models and AI agents have already transformed many fields and are changing our lives in fundamental ways. In the testing domain, AI agents have a clear path for making immediate improvements in process and quality, and ultimately for producing reliable, performant, secure, and compliant software. Check out Demystifying Agentic Test Automation: What It Means for QA Teams.

But it’s not obvious how to take advantage of these capabilities. While AI agents are not fully predictable, they can be managed reliably via robust control mechanisms. Let's see how.

What does it mean to manage AI agents in QA?

There are several important aspects to managing AI agents, both in general and specifically in the testing domain.

Configuration and guardrails involve setting agent autonomy levels and boundaries, defining test objectives through prompts and constraints, and specifying which areas require human approval. These steps ensure that the system operates within controlled parameters while meeting goals.

For example, you may allow your agentic AI system to write test code and even tracking and reporting systems, but not necessarily modify your production code.
Model selection and updates focus on deciding when to upgrade models versus maintaining stability. This includes testing model changes before rolling them out to production to avoid unexpected issues. If the quality of testing and coverage deteriorates when you upgrade models, it's a clear signal your AI agents are too finetuned to a specific model version.
Oversight and validation encompass quality gates and verification protocols, monitoring for flaky tests and low-value coverage, and managing the budget for execution costs. These practices help maintain test reliability and cost-effectiveness throughout the development lifecycle.

How to manage AI agents in practice

With those aspects in mind, let's see how to actually control your agents.

Consider a scenario where your team is migrating to agentic AI testing. You want to configure your agent's autonomy carefully. Here is a concrete example of how to go about it.

First, configure the agent system prompt. For example, you might specify: "You may generate API and UI test code for the /checkout and /payment flows. You may create test reports and update tracking dashboards. You must NOT modify production code or database schemas. All destructive operations (deleting tests, changing CI/CD pipelines) require human approval."
Next is tool integration. Connect your agent to your test management platform via APIs so it can read existing test cases and understand coverage gaps. This may be done through an MCP server like the Tosca MCP server or via custom tools you build.
Next, it’s time for a progressive rollout:

Week 1 - Agent generates tests in "suggestion mode" only.

Week 2-3 - Agent executes tests in an isolated staging environment.

Week 4+ - Agent runs tests in pre-production with human review of failures.
Finally, set up quality gates in your CI/CD pipeline that require a minimum pass rate (for example, 80%) before agent-generated tests can block deployments. Monitor false positive rate weekly and tune prompts accordingly.

How to Control AI Agents: prompts, tools, and feedback loops

Learning to control your agents is critical. AI agents, contrary to common beliefs, don’t actually have intelligence or agency. Agents are best understood as a system prompt combined with state/memory and a selection of tools. All the intelligence lies within the large language model (LLM), which accepts the agent (system prompt plus tools) and the user prompt as context. It then decides which tools to invoke and how to process both prompts until generating a final answer.

There are three ways to help control your AI agents: prompt engineering, tool integration, and performance monitoring/feedback loops.

Prompt engineering serves as the primary interface with these agents. This process involves writing effective test objectives and acceptance criteria, building a library of proven prompts, and iterating based on the outputs generated by the agent. Well-crafted prompts guide the agent to deliver precise and useful results.
Tool integration can be achieved through the MCP server, connecting agents to source control, design documents, and CI/CD pipelines. This integration provides essential context that enhances the agent’s intelligence. Additionally, emerging platforms like Applitools (for visual AI testing), Katalon Studio (for codeless test automation), and Selenium combined with AI extensions provide varying levels of autonomy and control for different organizational needs.
Performance monitoring and feedback loops track key metrics such as coverage, bug detection, false positives, and maintenance time. Real-time monitoring and alerting systems help determine when to reconfigure or retrain the agent for continued optimal performance.

Let's next consider the trajectory from traditional testing to agentic AI testing

How to migrate from traditional testing to agentic AI testing

Transitioning from traditional testing to agentic AI testing will be different for each organization as they start with their own unique combination of test automation, skill, and culture.

Organizations with existing automation typically run agentic AI tests alongside their legacy scripts, adopting gradual migration strategies and increasing the system’s autonomy as confidence grows.

This approach allows for a smoother shift without disrupting existing processes. The primary value here is flexibility and the ability to adapt quickly to changes.

Organizations that rely primarily on manual testing often start the process with low-risk regression suites to minimize risk. They focus on codifying tribal knowledge, transforming informal, human-centered test expertise into formalized, repeatable tests.

Additionally, for these organizations there is a cultural shift within QA teams, moving from maintaining scripts towards overseeing autonomous agents. But, in some ways it is easier to effect this change because the value is so much greater compared to already automated organizations.

Practical integration typically involves hybrid testing methods that combine manual, AI-assisted, and fully agentic approaches. Platforms like Tricentis Tosca and qTest enable unified management across these methods.

Example: Evolving a Traditional Test to an Agentic Approach

Let's compare how a typical test scenario might evolve from traditional to agentic approaches.

In a traditional Selenium test (using manual scripting) a QA engineer might write an explicit WebDriver code like this:

driver.findElement(By.id("username")).sendKeys("test@example.com")

But this test breaks when the UI changes (e.g., ID becomes class-based selector). Manual updates are required for every locator change. And with dynamic UI changes (very common when practicing A/B testing) the maintenance overhead and chance for errors is significant.

However, with AI-Assisted Testing (with tools like Tricentis Tosca or mabl):

The QA engineer records user actions via visual test builder.
Self-healing locators adapt to minor UI changes automatically.
This approach still requires human intervention for test design and assertion logic.

And with fully Agentic AI Testing:

The QA engineer provides high-level intent: "Test the login flow with valid and invalid credentials, edge cases, and security scenarios."
The agent autonomously discovers UI elements, generates test cases, and creates assertions.
It self-adapts to UI changes and refactors test logic without human input.
It learns from failures and adjusts test strategies in real-time.

The key insight is that traditional testing requires constant developer/QA time. Agentic AI shifts effort from execution and maintenance to strategic oversight and prompt engineering.

This is all great. But it’s also good to remember that agentic AI testing is a new paradigm, and migration to the bleeding edge always comes with challenges. So next, let's review some of the common challenges and solutions.

Common challenges in agentic AI testing

A common challenge with implementing agentic testing is calibrating trust in the AI, which is best done through incremental rollout.

Teams can introduce AI agents into the process gradually, validate their behavior on constrained scopes, and expand their responsibilities as confidence grows based on real outcomes and monitored performance.

Another persistent challenge is dealing with flaky tests, which can undermine trust and inflate maintenance costs.

Effective strategies include isolating unstable scenarios, tagging and quarantining flaky tests, and using AI agents to surface patterns in failures so teams can harden those areas.

At the same time, cost control and coverage deduplication require continuously pruning redundant scenarios and ensuring that additional test coverage actually adds incremental value rather than just increasing execution spend.

Finally, maintaining clear accountability is critical as agents take on more work. Even when agents generate, execute, and update tests, QA must own all agent outputs and remain the ultimate decision-maker on what ships. This means establishing review workflows, audit trails, and sign-off checkpoints so that autonomous activity is always paired with human oversight and responsibility.

But, even here AI agents can help as they are perfectly capable of performing review tasks. Moreover, it is possible to try multi-agent review: run three review agents, let them debate their findings, come to an agreement, then have a human receive the final distilled report and perform their own sanity checks.

The end game is integrating agentic AI testing directly into the software development lifecycle where agents don't just test code written by human developers. Instead they operate as part of a multi-agent AI development team where:

AI engineers write code
that AI testers develop and execute tests for
and together they iterate until the task is complete.

Conclusion

The key takeaways? To move to agentic AI:

Start with low autonomy and constrained scope.
Use MCP/tools to give agents context without giving them production write access.
Track failure rate, coverage, and costs.
Expand autonomy only after reliability is proven.

Managing agentic AI for testing shifts the focus from traditional script maintenance to strategic oversight. It requires QA teams to embrace a new mindset where they guide, monitor, and refine autonomous agents rather than manually updating scripts.

To get started with agentic AI testing, organizations should begin small, validating AI agents on low-risk scenarios and gradually expanding their scope as confidence builds.

By following best practices and leveraging robust tools, QA teams can transform their testing processes, accelerate releases, and improve software quality in an increasingly complex digital landscape.

Have a really great day!

Demystifying Agentic Test Automation for QA Teams

John Vester — Wed, 10 Dec 2025 14:09:22 +0000

Agentic test automation is a fundamental shift in how we test. Instead of depending on static, hand-written scripts that must be continually updated, agentic systems analyze apps, plan testing strategies, execute tests, and adapt to changing code—largely on their own.

In this blog post, we’ll look at agentic test automation. We’ll cover what it is, how it improves traditional test automation, the skills needed in order to move to the agentic world, how to navigate the pitfalls of agentic automation, and some of the tools that you can use.

What is Agentic Test Automation?

Agentic test automation is a type of software testing where AI (often powered by large language models) plans, executes, and adapts tests autonomously.

Unlike traditional automation that relies on static, hand-written scripts, agentic systems can understand context, analyze changes in real time, and decide what and how to test, all on their own. This often means broader test coverage, better and faster detection of defects, and less maintenance.

Large Language Models (LLMs) play a big role here. LLMs can understand application context and user intent, interpret the purpose and meaning of different components, and focus on what’s most critical. This means they can not only help create and adapt tests, but they can also identify edge cases and scenarios that conventional automation will probably overlook.

Agentic test automation can be seen as the pinnacle of the test automation spectrum:

Manual scripts - require constant maintenance and breaking with UI changes. Relies on manually crafted scripts that are brittle and fail when applications change or evolve. These scripts require constant maintenance and updates whenever the user interface or application structure changes, making them time-consuming and expensive to maintain over time.
AI-assisted tools - intelligent locators and visual recognition that still need human oversight. While AI-assisted tools can introduce intelligent locators, visual recognition, and reduced maintenance requirements to help identify elements more reliably and adapt to minor UI changes, they still require human oversight and predefined test cases, and don't fundamentally change the need for human-defined test strategies. (examples include Applitools Visual AI or Mabl)
Agentic automation - autonomously explores applications and discovers edge cases without constant oversight, as seen with platforms like Tricentis Tosca and qTest, which support scalable, agentic workflows with features like model-based automation and broad test management across environments.

However, agentic test automation is not a panacea just yet. You can think of agentic test automation as shifting QA focus away from people testing and to people giving oversight of independent and strategic AI agents.

Skilled and thoughtful QA engineers are still needed for high-level oversight and to ensure the agentic automation operates effectively and within policy.

Essential Skills for QA Engineers in an Agentic World

So if the testing world is moving more towards agentic AI (with human oversight), what skills do QA engineers need to adapt?

Prompt engineering: The ability to communicate clearly with agents becomes essential, as engineers need to articulate test objectives and quality criteria (through prompting) in ways that guide automated decision-making.
Strategic thinking: Rather than focusing on writing detailed test scripts, QA engineers should cultivate strategic thinking about test coverage. They need to understand which areas require attention and how to evaluate the comprehensiveness of agent-generated tests.
Model oversight: QA engineers will need to be active in oversight. They must evaluate when the AI’s reasoning is sound, catch false positives or hallucinations, and know when to step in.
Integrations: QA will be responsible for making sure the agents have access to context. Source control, CI/CD systems, and design documents are necessary to help agents understand when a test is truly a failure. Tools such as Tricentis’ Model Context Protocol (MCP) is an example of how teams can allow AI agents to directly interact with testing frameworks.
Accountability: When the final results come in, QA engineers will still be responsible for the results. They need to embrace accountability for all agent-generated tests, ensuring that results meet the same quality standards as human-created tests, even if they didn’t manually create them.

It’s also critical for QA professionals to stay current with emerging AI models and testing frameworks. While newer models are often faster and more cost-effective, stability and alignment with company workflows matter more than novelty. QA engineers will need to understand and implement this balance.

Navigating the Pitfalls of Agentic Test Automation

Of course, as with all new technologies, agentic test automation comes with pitfalls.

Trust calibration is key. QA engineers must have robust verification protocols to ensure accuracy and reliability, especially in the beginning when engineers are still fine-tuning agent prompts.
In the early learning phases, agents may frequently generate false positives. QA engineers will need to provide careful oversight and tuning to avoid wasted effort.
QA maintenance duties will shift from labor-intensive script updates to configuring agent parameters and guardrails. This is a challenge, but it can be made easier by platforms like Tricentis Tosca/ qTest or Applitools Execution Cloud (focused on self-healing infrastructure), both of which simplify maintenance with built-in agentic workflow controls and model-based automation.
Even as agents take on more testing responsibilities, human-in-the-loop validation remains vital for safeguarding critical workflows and ensuring decisions align with enterprise priorities.
Flaky tests are the bane of high-quality testing. Agentic test automation can quickly generate a lot of tests. If some of those are flaky, the value is greatly diminished, productivity will drop, and trust in the overall QA process will fall. Make sure to help the LLM weed out flaky tests.
Finally, agentic AI systems might generate many low-value tests with coverage overlap. And this can be quite expensive both in time and money. As part of human oversight, QA engineers will need to carefully monitor, and budget, their tests.

Getting Started: Practical First Steps

Getting started with agentic test automation is best approached incrementally.

First, begin by experimenting with low-risk regression suites or exploratory tests in non-production environments. This allows teams to validate agentic outputs alongside legacy automation.
It’s also wise to constrain the agent’s initial autonomy to specific features or flows, making oversight manageable and learning outcomes clear.
Finally, take full advantage of agentic test automation and incorporate automatic root cause analysis when tests fail.

Agentic Testing with Tools/Platforms

Agentic testing can be wildly successful for metrics—and can be made easy to implement with the right tools. Platforms such as Tricentis Tosca and Mabl have already shown strong results in improving key metrics. For example Tricentis (which can automatically generate test cases using agentic AI and natural language prompts) has shown up to a 85% reduction in test creation and 60% increase in productivity by automating complex regression suites across thousands of test cases with agentic orchestration.

But when using these tools, QA engineers should continually compare new agent-generated results with existing baselines to be sure their tests are accurate and on-task. Use success metrics like expanded coverage, higher bug detection rates, and reduced maintenance time to guide adaptation. A structured and monitored onboarding process helps QA teams build confidence, understand limitations, and embrace agentic automation and the right tools.

Conclusion

Agentic test automation marks a transformative leap for QA teams, shifting the focus from manual scripting and maintenance to strategic oversight and collaboration with AI agents.

By embracing new skills, teams can unlock better test coverage, improved metrics, and streamlined workflows. And as agentic systems mature, QA teams that embrace and prepare for the shift will move successfully from manual work to orchestrating AI.

Have a really great day!

Why the MITRE ATT&CK Framework Actually Works

John Vester — Fri, 21 Nov 2025 03:22:35 +0000

The alert goes off at 2:17 p.m.

You count yourself lucky that this one’s in the afternoon, not morning. You drop what you’re doing, open the console, and start digging in.

Oh, a significant spike in outbound traffic from a Kubernetes node. A privileged service account authenticating from an unfamiliar IP. Hmm, some DNS requests look… odd, but not that odd. You pivot through dashboards, trace the source in your SIEM, check cloud logs, query identity data, and even pull container logs. Nothing definitive. No confirmed breach. No clear story is emerging.

Was it a misconfigured workload? A developer testing a deployment script? A legitimate automation job or the first step of lateral movement by someone already inside? The indicators blur together until you can’t tell if you’ve caught an attack in-progress or another false positive in a sea of noise.

Twenty minutes later, you close the ticket with the same note as the last one: “Monitoring.”

Imagine doing that fifty times daily. The backlog grows as threats move through the network using valid credentials, blending in with legitimate activity, leaving ambiguous traces. Many security teams face a harsh reality: traditional detection systems catch known threats such as signature exploits, anomalies, and documented indicators. But attackers now mimic user behavior, hijack processes, and pivot beyond correlation rules, flooding alerts with few meaningful ones. Analysts are overwhelmed chasing false alarms while real threats go unnoticed.

Security shouldn’t just be about stopping the bad, but understanding how the bad actually happens. Enter the MITRE ATT&CK framework. Built from years of real-world threat research, it offers a living map of how adversaries operate, move laterally, and exploit systems step by step. And when paired with a modern analytics platform, it turns that understanding into actionable visibility by showing exactly where your defenses are strong and, by contrast, where they may be weak.

This article explains how MITRE ATT&CK shifts threat detection from reactive to proactive, how modern analytics platforms support this, and shares best practices for developing adaptive detection logic.

The ATT&CK framework

Most security frameworks start with what went wrong after the fact. MITRE ATT&CK begins with how things go wrong in the first place.

Developed by the nonprofit MITRE Corporation, ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a living knowledge base of real-world attacker behavior. Each entry in the ATT&CK Matrix maps tactics (the why) and techniques (the how) that adversaries use across different stages of an intrusion.

Instead of focusing on malware signatures or static indicators, it emphasizes observable behavior, attacker tactics like gaining access, escalating privileges, lateral movement, or data exfiltration. It's a structured playbook covering phishing, credential dumping, command-and-control, linked to threat groups and campaigns.

For instance, the framework details how APT29 (Cozy Bear), a threat group tied to multiple espionage operations, frequently abuses legitimate credentials to blend into regular network traffic. By mapping detections to those same techniques, teams can uncover blind spots that purely signature-based tools miss.

This behavioral model helps security and engineering teams speak a shared language. A SOC analyst investigating a PowerShell command might tag it as T1059.001 (Command and Scripting Interpreter: PowerShell), while a cloud engineer reviewing IAM logs might reference T1078 (Valid Accounts). Each technique includes definitions, detection ideas, and references to confirmed incidents, making ATT&CK as practical for detection engineering as it is for incident response.

ATT&CK's strength lies in its ongoing evolution, incorporating recent threat intelligence, observations, and community input to reflect current attacker behavior. Engineers should follow the principle: Log what matters, detect observable actions, and verify assumptions against real adversary behavior.

Real-world ATT&CK

Today, every major security platform claims “MITRE ATT&CK integration”: Splunk, Microsoft Sentinel, Palo Alto Networks, Sumo Logic and Check Point. They all offer dashboards mapping detections to ATT&CK tactics and techniques. But not all dashboards are equal. Some provide only surface-level, color-coded matrices that look impressive but don’t show what’s detectable in your environment. Others display only one or two data sources, leaving visibility gaps. Few help compare coverage to real-world tactics. That’s where a modern analytics platform can help.

For this article we’ll use Sumo Logic’s Threat Coverage Explorer as an example of the kind of tool you can use to map detections to ATT&CK techniques. Rather than only displaying an ATT&CK matrix, it connects the dots between your real detection rules and the techniques they map to. It analyzes your security content, including correlation rules, log patterns, and detections-as-code. And it builds a visual model of your defensive coverage across all ATT&CK tactics and techniques across all this content.

By combining the right tool with ATT&CK you can:

See which ATT&CK techniques you can actually detect. Instead of relying on vendor defaults, you can evaluate your detections and map them to relevant ATT&CK TTPs. You see where you have visibility and where you don’t.
Perform gap analysis and peer comparison. You can benchmark your coverage against industry peers at both technique and technology levels. Are your detections strong on credential access (TA0006) but weak on lateral movement (TA0008)? You’ll see it immediately.
Tag custom rules with ATT&CK techniques. Detection engineers can label correlation rules with specific ATT&CK IDs like T1055 for Process Injection or T1552.001 for Unsecured Credentials in Files, enabling your content library to map to the framework automatically. This simplifies documenting, testing, and maintaining coverage as attacker behavior evolves.
Visualize coverage at a glance. You can see a heatmap that shows which techniques are fully, partially, or not covered. You can drill down from tactic summaries to rules, events, and data sources. It’s more than a dashboard—it’s an actionable view of your detection maturity.

This approach transforms ATT&CK from a theoretical framework into a living operational map. Imagine a scenario in which your logs capture credential misuse (T1078) but miss persistence mechanisms such as scheduled tasks (T1053). It exposes that blind spot before an attacker can exploit it. And because it updates dynamically as your rules or content evolve, it becomes part of your continuous detection engineering workflow rather than a one-time assessment. In the same way DevOps teams rely on observability metrics to measure system health, modern SecOps teams can now measure detection health.

Using ATT&CK for a better SecOps

The real power of MITRE ATT&CK isn’t in its taxonomy. At its core, the ATT&CK taxonomy is a schema for adversarial behavior. Each tactic is like a stage in an attacker’s workflow, while each technique describes the specific implementation of that step. It’s a structure of how attacks unfold, grounded in empirical evidence from real intrusions rather than theoretical models. This taxonomy enables a shift from reactive firefighting to proactive defense.

Many organizations spend their days chasing alerts. Every detection is treated as an isolated event instead of a step in a larger narrative. ATT&CK flips that mindset. By mapping activity to known adversarial tactics and techniques, teams start thinking like attackers and thereby anticipating what comes next instead of waiting for another alert to tell them.

When combined with the right tool, this mindset becomes operational. You can test hypotheses (“If an attacker gained initial access through phishing, would we see their lateral movement?”), validate detection logic, and continuously measure improvements over time. Again, the goal isn’t about collecting more data for its own sake; it’s about collecting the correct data and understanding what it tells you in context.

Because ATT&CK evolves as adversaries do, your detection logic can grow too. New techniques emerge in the framework as they’re observed in the wild, giving engineers a head start on updating correlation rules, dashboards, and automation playbooks before those tactics appear in production environments.

Proactive security is a process, not a steady-state. With ATT&CK as your blueprint and the right tool as your lens, your team can move from reacting to alerts toward anticipating attacker behavior. That’s the difference between being surprised by a breach and detecting it before it becomes one.

MITRE ATT&CK is Your Blueprint

Security isn’t about building taller walls; it’s about understanding how attackers move within them. The next time that 2:17 p.m. alert fires, it doesn’t have to end with “Monitoring.” The MITRE ATT&CK framework works because it’s grounded in how real adversaries think and operate.

With MITRE ATT&CK as your blueprint and the right tool as your lens, those same signals become context, not chaos. You’ll know which behaviors matter, where your defenses stand, and how to strengthen them before attackers can adapt. Together, they transform security from reactive noise management into a cycle of continuous learning and proactive defense, which is why ATT&CK continues to work in practice, not just in theory.

Have a really great day!

Why Enterprise AI Needs Agentic Messaging Platforms

John Vester — Tue, 07 Oct 2025 01:06:44 +0000

Enterprise AI initiatives often follow a predictable pattern. They launch with ambitious goals: "We need AI agents that can automate workflows, integrate with our systems, and execute complex business logic." The demonstrations are compelling. The potential is clear.

But then the implementation reality sets in.

Months pass while teams wrestle with infrastructure challenges instead of focusing on intelligence. The problem isn't that the AI lacks capability—it's that organizations get bogged down in building infrastructure instead of moving quickly to bring solutions to market.

Most enterprise teams get trapped in endless cycles of integration work. They write custom code to connect APIs, stitch together services, debug fragile workflows, and make everything scale. By the time they've built the foundation, business requirements have evolved, and the cycle begins again.

Why Enterprise AI Gets Stuck

Understanding why promising AI initiatives stall requires examining the fundamental challenges that emerge when moving from concept to production.

API integration complexity represents one of the most significant bottlenecks. What appears simple on paper—connecting to existing enterprise systems—becomes an exercise in digital archaeology. Each system communicates differently, uses unique authentication schemes, and has distinct ideas about data flow.

In some cases, APIs need to be adjusted and require enhanced documentation Or converting them to MCPs so AI systems can understand how to use them effectively. Without this, integration work consumes weeks instead of days.

Building business logic requires significant resources. Developing and maintaining enterprise workflows, rules, and decision trees demands close collaboration between product managers, analysts, and developers. Translating high-level business requirements into executable code, handling exceptions, and ensuring consistency across systems requires significant effort. Complex rules often span databases, microservices, and legacy systems, making implementation time-consuming and error-prone. Even small changes in requirements can trigger substantial work to update and validate workflows, slowing iteration, increasing costs, and raising the risk of inconsistencies.

Workflow orchestration visibility poses ongoing challenges for complex AI systems. Multi-step processes involve interactions between various services, but traditional enterprise systems provide limited insight into these workflows. When issues arise—and in complex systems, they inevitably do—teams are left reconstructing events from scattered log files across different systems.

Scaling requirements expose the limitations of traditional enterprise architectures when faced with AI workloads. Production systems need to handle sudden spikes—market events triggering thousands of simultaneous alerts, or batch jobs processing millions of records in parallel. Building this infrastructure requires expertise in distributed systems, message queuing, load balancing, and fault tolerance patterns.

Governance and compliance considerations often emerge as afterthoughts, creating significant delays when teams realize they need comprehensive audit trails, access controls, and compliance monitoring. Retrofitting these requirements into existing systems isn’t just technically challenging—it requires coordination across security teams, legal departments, and compliance officers.

How Enterprises Try to Solve This Today

Organizations typically pursue one of several approaches to address these infrastructure challenges, each with distinct trade-offs.

Custom development efforts involve building orchestration and integration frameworks internally. This approach offers complete control and perfect alignment with specific organizational needs, but typically consumes entire engineering teams for months. Teams end up rebuilding infrastructure that already exists—message queues, workflow engines, monitoring systems—instead of focusing on their core business problems and AI capabilities.

More technically sophisticated organizations often choose robust messaging platforms like Kafka, RabbitMQ, or NATS as their foundation. These are proven, battle-tested systems capable of handling enormous volumes and complex routing patterns. The challenge is that they're building blocks rather than complete solutions. Organizations still need to layer on orchestration logic, compliance monitoring, agent management, and comprehensive observability tools. What begins as a straightforward messaging implementation evolves into a complex system-of-systems requiring specialized expertise to maintain and operate.

Each approach addresses portions of the overall challenge, but none provides a complete solution that allows teams to focus primarily on AI logic rather than infrastructure complexity.

KubeMQ- Aiway: Next Generation Agentic Messaging Platform

KubeMQ's revolution in this space reflects an understanding of these enterprise realities. The company has been powering mission-critical messaging for finance, telecom, and defense organizations—environments where system reliability is paramount. Their development of KubeMQ-Aiway represents recognition that messaging alone isn't sufficient for AI-driven enterprise requirements.

The platform combines proven enterprise messaging capabilities with the orchestration layer that AI agents require. Rather than treating messaging as merely a transport mechanism, the architecture integrates intelligence and workflow automation directly into the messaging foundation.

The approach offers several key capabilities: business logic can be written in natural language and automatically converted into executable workflows. API documentation—including comprehensive specification documents—can be uploaded to generate ready-to-use tools that agents can immediately consume. These tools abstract away the complexity of raw APIs, making them reusable building blocks across multiple workflows. Complex flows can then be assembled using these tools, with built-in parallelism and observability, all running on messaging infrastructure proven in production environments.

The architecture maintains enterprise reliability and security requirements while enabling the development speed that modern business environments demand.

Exploring KubeMQ-Aiway’s Features in Practice

Having recently explored KubeMQ-Aiway firsthand, I was able to see how its design reduces much of the complexity described earlier. Unlike traditional messaging platforms that require separate orchestration tooling, KubeMQ-Aiway brings everything into one workspace: tools, APIs, agents, and flows.

Tools & APIs

The Tools dashboard lets teams register any service API (e.g., proprietary systems, partner services, SaaS/market feeds). This means a team can quickly add a legacy CoreBanking API, a real-time MarketData feed, or a compliance service, and monitor usage directly. The platform supports both synchronous request/reply and streaming connections, all managed via KubeMQ’s underlying broker. This visibility ensures that when APIs misbehave or hit limits, teams see the warning signals before workflows break.

Agents

Aiway’s Agents panel shows how AI-powered components connect to tools. Each agent can be configured with:

An underlying model (e.g., GPT-5, Sonnet 4.1)
Natural language prompts that define its role (“You are a stock trading agent for our bank…”)
Flexible messaging patterns, enabling a single agent to coordinate multiple tools in different ways simultaneously. For example, the same agent might place portfolio-update requests into a queue for a risk analysis service, while also streaming real-time market data to a monitoring tool—all orchestrated from the instructions given in the prompt.
Linked tools it can call during execution

This capability is particularly important for enterprise workflows, where one agent often needs to manage different communication patterns across heterogeneous systems. Instead of splitting responsibilities across multiple agents or hardcoding integrations, teams can define rich, multi-tool behaviors within a single prompt. The result is tighter coordination, less fragmentation, and easier maintenance—while still providing complete transparency and auditability for compliance.

Flows

The Flow Editor is where orchestration happens. Teams can visually design sequences that link APIs and agents. For example, a TradingAgent might:

Pull account balance from CoreBanking via request/reply.
Validate KYC with CustomerKYC service using a cached check.
Run a compliance validation through the ComplianceAgent via pub/sub.
Forward results to a notification service for customer updates.

All of these are configured through drag-and-connect nodes, backed by KubeMQ’s messaging guarantees (queues, pub/sub, streams). The visual interface makes it clear how data flows, while the messaging backbone ensures it never gets lost.

Monitoring, Cost Control & Analytics

Aiway’s Analytics dashboard provides system-wide insight across operations, performance, and costs:

Message volume (e.g., 2.4M daily transactions)
Response times (e.g., 43ms average latency)
System health (e.g., 99.9% uptime)
Cost control metrics, including per-agent and per-tool usage tracking, allowing enterprises to monitor API call volumes, model consumption, and infrastructure load. This visibility helps teams forecast expenses, identify cost-heavy workflows, and optimize where necessary without compromising reliability.

Equally important, Aiway delivers deep observability into agent coordination and system behavior. Enterprises can trace message flows end-to-end, identify bottlenecks across distributed services, and drill down into per-agent execution details. With real-time dashboards, anomaly detection, and exportable audit logs, teams can ensure compliance while also improving operational efficiency.

This isn’t just cosmetic. For enterprise teams, observability and cost transparency are often the missing link. By unifying these capabilities in one platform, Aiway shortens mean time to detect and resolve issues, prevents cost overruns, and gives stakeholders the confidence that large-scale AI operations remain both sustainable and accountable.

Use Case Example: AI Index Fund Selection

In this use case, the bank wants to provide customers with an AI‑powered filtering service that goes beyond static programmatic checks. Customers may ask broader questions such as: Which S&P 500 index fund should I consider? or What robotics‑focused funds are available right now? Rather than replacing a financial advisor or giving prescriptive recommendations, the IndexAgent helps customers by narrowing down a large universe of funds into a filtered, ranked list that best matches their stated preferences, portfolio, and risk profile. The agent provides clear explanations of why certain options were selected, while still requiring the customer to make the final decision. This service adds value by simplifying complex fund choices into an understandable shortlist backed by real‑time data, portfolio alignment, and compliance checks.

Setup of the required tools

The bank uploads the API specs of its key services into the Tools tab. Each tool is registered separately:

MarketData provides live quotes, spreads, and constituents so the agent always works with the latest market context.

PortfolioService delivers current holdings and exposures, enabling personalized filtering aligned with customer portfolios.

RiskProfile supplies suitability and risk tolerance information to ensure shortlist results fit the customer’s profile.

CustomerKYC checks eligibility and residency rules, preventing options that customers cannot legally access.

BenchmarksAPI maps funds to benchmark indices, supporting comparisons across families like S&P 500 or sector‑focused indices.

NotificationService handles delivery of outputs such as shortlists and rationales directly to the customer portal or app.

Optionally, an Execution Broker API can be added if the customer later chooses to place an order, connecting shortlist results to trade execution.

Setting up the main Agent (IndexAgent)

The IndexAgent prompt is written to coordinate all these tools and ensure the flow remains compliant and explainable. Here is the full prompt assembled:

You are IndexAgent for our bank. Your job is to narrow a large universe of index funds/ETFs into a filtered, ranked shortlist that fits the customer’s stated intent, portfolio, and risk profile.

Do not place orders unless the customer explicitly approves.

When a customer request arrives via [Pattern:Queue:advisor.requests], begin a new advisory session and tag all messages with advisor_session_id and customer_id.

Pull live prices, spreads, ADV, and constituents for candidate funds from [Tool:MarketData] via [Pattern:Stream:prices]. If the stream stalls, fall back to the last 30s snapshot.

Fetch holdings, sector exposure, and concentration limits from [Tool:PortfolioService] via [Pattern:Request/Reply].

Retrieve risk band and suitability constraints from [Tool:RiskProfile] via [Pattern:Request/Reply].

Validate product eligibility and restrictions using [Tool:CustomerKYC] via [Pattern:Cache:5min].

Query index families and fund‑to‑benchmark mappings from [Tool:BenchmarksAPI] via [Pattern:Request/Reply].

Score candidates on expense ratio, liquidity (ADV/spreads), tracking error, diversification (top‑10 weight), historical drawdowns, tax efficiency, and fit to portfolio & risk constraints. Output a TOP‑3 shortlist with a plain‑language rationale and a small metrics table for each option. Include explain_trace=true.

Publish a compliance summary for review to [Agent:ComplianceAgent] via [Pattern:Pub/Sub:compliance]. If flagged, revise the shortlist or request human approval.

Present the shortlist and rationale to the customer. If the customer clicks BUY, emit an order‑intent event with an idempotency key and hand off to execution via [Pattern:Queue:trading.orders].

This single agent prompt demonstrates how Aiway unites multiple tools, a sub‑agent, and different messaging patterns in one cohesive flow. The IndexAgent coordinates MarketData, PortfolioService, RiskProfile, CustomerKYC, and BenchmarksAPI, while also publishing to a ComplianceAgent as a sub‑agent. It shows how queueing, streaming, request/reply, cache, and pub/sub patterns can be combined in one agent to orchestrate a complete advisory workflow. This highlights how a bank can use agentic infrastructure not only to answer general questions like Which S&P 500 index fund should I consider? but also handle specific sector‑based requests such as Show me index funds following the robotics industry. In both cases, the IndexAgent narrows the universe of options into a clear, compliant shortlist, leaving the customer in control of the final decision.

The Power of Integrated Agenting on Top of a Messaging Platform

The integrated approach changes the fundamental economics of enterprise AI deployment. When messaging and orchestration layers are designed together, entire classes of integration problems that typically consume months of development time are eliminated.

Organizations will continue using various approaches—some building on Kafka or RabbitMQ while layering orchestration and compliance tools on top, others gravitating toward integrated platforms that combine agent workflows with proven messaging infrastructure. Both approaches can succeed, but integrated platforms dramatically reduce expertise requirements and time-to-market.

KubeMQ’s specific advantages make this integration particularly effective. The platform features Kubernetes-native architecture that works naturally within modern cloud infrastructures, eliminating complex bridge configurations that often introduce failure points. Resource usage scales efficiently from proof-of-concept deployments to massive enterprise workloads handling millions of transactions, with automatic performance optimization as demand changes.

The underlying principle is fundamental: agentic AI requires enterprise messaging at its core. Without robust messaging infrastructure, AI agents cannot coordinate reliably at enterprise scale. The question isn't whether messaging is needed—it's whether to build it internally or leverage proven platforms that already address these challenges.

Conclusion

Enterprise AI success increasingly depends on the ability to deploy reliable, observable, and scalable agent systems quickly. The intelligence capabilities of AI are largely established—the challenge lies in making them work reliably within enterprise environments.

KubeMQ has revolutionized this space with KubeMQ-Aiway, transforming workflows that traditionally required months of manual integration into solutions deployable in weeks. The platform recognizes that enterprise messaging isn't just about data movement—it’s about enabling the coordination, observability, and cost control that intelligent systems require.

As enterprises transition from proof of concept to production AI, success will depend less on agent capabilities and more on how reliably and efficiently these systems can be deployed at scale. The infrastructure foundation chosen today will determine whether AI initiatives become transformative business capabilities or expensive technical exercises.

Organizations that establish effective AI infrastructure foundations first will gain significant competitive advantages. Those that don't will find themselves rebuilding infrastructure while competitors deploy working AI solutions.

Have a really great day!

Beyond Code: How to Use AI to Modernize Software Architecture

John Vester — Tue, 09 Sep 2025 01:33:54 +0000

Enterprise teams today ship more code, more frequently, than ever before — fueled in part by AI-driven coding tools like GitHub Copilot and Amazon Q.

But there’s a problem.

While AI helps enterprise teams ship more, faster, the legacy systems they’ve inherited — along with years or even decades of architectural debt — are getting worse. As complexity mounts, many organizations are turning to modernization — not just to keep up, but because cloud migration demands it.

The reality is that while much of the excitement around AI coding focuses on greenfield projects and newly built applications, most developers spend their time maintaining and modernizing legacy systems that are filled with outdated code, old frameworks, and accumulated architectural debt.

Teams have been given this mandate to modernize, but with their AI tools having little to no context of the existing software architecture (or architectural debt), problems such as tight coupling, tangled dependencies, and architectural drift are exacerbated. Developers are quickly discovering AI isn’t improving their architecture … it’s making it worse.

But there’s an answer. Because modernization isn’t just about quickly rewriting code. It’s about reshaping software architecture to support scalability, faster delivery, and cloud-native goals. And with the right approach to using AI, these goals can be achieved.

In this article, we’ll explore how to enable AI-assisted software architecture modernization. While most articles focus on using AI to code, we’ll look at specific examples of how AI can actively help modernize software architecture, including how to create effective prompts. Because with the right tools and the right context, AI can provide consistent, and correct, architectural suggestions that help, not hinder, your team’s efforts..

Whether you’re wrestling with a monolithic legacy system or navigating the intricacies of inherited microservices, AI can be an effective and powerful co-architect.

The Problem with AI and Software Architecture

We know that AI has transformed coding. Most developers rely on AI coding assistants in their daily work, using these AI agents as a smart, experienced, and tireless coding assistant. AI agents can now write (or rewrite) entire blocks of code, and even entire systems if we ask.

The problem is that in this daily use, AI is also affecting architecture.

When a developer writes code, they are constantly asking, and considering the answer to, questions such as:

How should I organize my classes?
How should I handle caching?
Where should I put this business logic?
What are the external dependencies?
How does this fit into our overall software architecture?
And more

Whether developers realize it or not, AI agents are also asking these questions — and implicitly making architecture decisions — with every line of generated code.

And along with these decisions comes risk — especially when the AI agent (as is typical) doesn’t understand any context of the architecture. Your smart, experienced, and tireless coding assistant is making uninformed decisions that on the surface seem correct — but when viewed from the context of software architecture are adding more debt, more problems, and more hours debugging. That “redundant” logic? You know it handles an edge case you found last year. But the AI, when it decides to quietly delete that code, does not.

And to make your problems worse, these mistakes aren’t usually immediately obvious. With legacy systems, code coverage is often less than ideal. And even then, software architecture doesn’t usually announce its breakdown loudly. Problems like tight coupling or unscalable modules are often invisible to monitoring and testing tools. Yet they wreak havoc over time.

Software Architecture Drift

Architecture drift (the slow and nearly invisible erosion away from structured and controlled architecture) is particularly insidious. Consider this Fortune 100 bank that struggled with modernizing a massive Java monolith comprising over 8 million lines of code. It’s a familiar story: the system’s complexity was overwhelming, internal modernization attempts took years, and efforts stalled repeatedly due to hidden architectural pitfalls.

In a recent survey, 93% of respondents reported experiencing negative business outcomes due to misalignment between implemented architecture and documented standards — making the cost of these gaps impossible to ignore.

Architectural problems may be less visible than code bugs, but they are much more problematic.

How AI Can Actually Help Modernize Your Software Architecture

But it doesn’t have to be this way.

AI can not only understand and follow your architecture decisions, but can help improve them as well. In brownfield modernization efforts, where static diagrams and tribal knowledge fall short and developers and architects are left in the dark, AI isn’t just an assistant. It’s a lifeline.

Just as AI tools can detect and recommend improvements at the code level, AI can detect and repair architectural problems during your modernization efforts if it is fed with architectural context based on runtime analysis.

Used properly and with runtime context and preliminary domain driven structural analysis, AI can:

Detect and correct architectural antipatterns before they become critical
Suggest precise refactoring strategies
Prioritize what to fix, conserving an engineering team’s limited time (whereas coding assistants help immediately remediate small-scale issues)
Untangle complex dependencies
Automate the repair of architectural drift, effectively making the system self-healing

Effective Prompting for Successful Modernization

So we know AI can be our best friend when modernizing systems. But how do we get started?

The first step to effective use of AI in software architecture is effective prompting. The results you get are directly tied to the quality of your prompt. And the quality of your prompt is typically a result of giving the AI context and being specific.

If you are in any way vague in your prompt, the result will most likely be very wrong.

So what does an effective prompt look like?

1. Be specific.

Don’t prompt “Build a REST API to manage orders.”

This prompt, while perhaps exaggeratedly bad, leaves significant room for AI interpretation in both architecture and design.

Instead, prompt specifically with architectural direction:

“Build a Python REST API to manage orders using Flask and SQLAlchemy. Structure the application with:

a controller layer (Flask routes) for handling HTTP requests,
a service layer for business logic,
and a repository layer for data access using the SQLAlchemy ORM.”

2. Be thorough.

Don’t just mention code logic. Also include non-functional requirements.

“Extend the Python Flask REST API to support operational robustness and maintainability. Include the following:

Log every incoming HTTP request and its response status. Log execution time for each request using Python’s built-in logging module. Logs should be structured and include a timestamp, endpoint, status code, and latency.
Validate all incoming request payloads using Pydantic models at the controller layer. Ensure validation errors return standardized JSON error responses with clear messages and appropriate HTTP status codes.
Implement retry logic with exponential backoff for transient database errors in the repository layer. Use Tenacity to handle retries without duplicating logic in the business layer.
Ensure that all error responses follow a consistent JSON schema, including error code, message, and optional details for debugging.”

3. Always be an architect.

Convey your architecture design and goals, and how they should be incorporated into the system. Be specific and exact.

“Develop a modular email delivery system for the order system, designed to scale horizontally and can later be separated into its own microservice. The system must follow these architectural goals:

Clear Separation of Concerns — structure the codebase into clean layers:

Controller Layer (i.e., the Flask routes): Accepts and validates email send requests.
Service Layer: Handles business rules like rate limiting, content templating, and retries.
Repository Layer: Manages persistence of email send attempts, statuses, and delivery logs using SQLAlchemy.

2. Statelessness:

Do not maintain session or request-specific state between calls.
All context (e.g. sender ID, email content, headers) must be carried in each request.
Persist all state in external stores (database, cache, or queue) to maintain stateless compute nodes.

3. Scalability and Microservice Readiness:

Design each major concern (e.g., send queueing, email rendering, status tracking) as an internal module that could later become an independent service.
Avoid hardcoded implementations — interfaces should be defined for each major component (e.g., EmailProvider, EmailQueue, TemplateEngine).
Inject all service and repository dependencies via constructors or a simple DI container.

4. Non-functional requirements:

Resilience: Gracefully handle SMTP errors and retry failures using backoff strategies.
Observability: Log all email activity with request IDs and delivery metadata.
Extensibility: Make it easy to support multiple providers (e.g., SendGrid, SES) behind an interface abstraction.”

Remember: prompts effectively are your architecture. Be specific, add context, be thorough, always.

Add architectural context to your prompts

An apt reader will notice that the last statement included “add context” … but we haven’t yet addressed that need.

To add architectural context to our prompts, we need some help. For this example, I’ll use vFunction, a tool that analyzes application architecture and provides structural guidance to GenAI assistants in refactoring. We’ll use static and dynamic analysis combined with data science to understand the logical domains of your app and identify the optimal boundaries of those domains. This in turn allows us to find architectural issues in complex Java and .NET apps, such as:

Circular dependencies
Anti-patterns
Architectural technical debt
Domain boundary violations
Dead code
And more

You then feed that information into your agent to guide its steps, giving your AI agents the information they need to write the code you want. It’s a great example of the kind of information you need to be successful with AI.

A step-by-step example

Let’s walk through the steps above to see how we supply architectural context to code assistants.

Analyze your app.

Start by collecting static and dynamic data from your application. We’ll use vFunction to identify potential logical domains in your application and their boundaries. This baseline allows the tool to identify relevant architectural issues like sub-optimal domain boundaries, inter-domain class dependencies, resource dependencies, high-debt classes, circular dependencies, and shared code across domains. Afterward, you can query the analysis to find errors in need of immediate refactoring, asking questions such as: Which domains contain the highest number of common classes?

Analysis of a mid-size app and its entangled business domains (represented by spheres) and accompanying technical debt.

Review the architectural TODOs

Next generate a list of prioritized architectural TODOs, each with a contextual explanation and an AI-ready prompt you can use in tools like Amazon Q or GitHub Copilot.

Use the prompt in your AI assistant.

Send the generated prompt into your IDE or code assistant. It will understand the context and help you break up god classes, resolve domain pollution, or implement suggested changes to increase the modularity of your code. For example, in the screen shot above we see suggestions for refactoring a circular flow dependency.

Validate and repeat.

Rerun the analysis after applying changes. It will show you whether modularity improved, which TODOs were resolved, which weren’t, and suggest the next step in the refactoring process.

By combining this insight with your LLMs, you create a powerful, context-aware assistant ready to build and to do the hard work of refactoring.

AI is Your Partner in Software Architecture

AI-powered coding is only part of the story. The real value comes from using those same AI assistants not just to generate code but as a partner to help you modernize and improve your existing software architecture.

By using architecture-aware, runtime based context to generate effective, consistent and precise prompts, AI can help you overcome legacy architecture debt, modularize your code, and implement a scalable, cloud-native, modernized system.

Have a really great day!

Bring Your Own Feed (BYOF): An Engineer's Guide to Effective Threat Intelligence

John Vester — Wed, 30 Jul 2025 20:31:08 +0000

As software continues to eat the world, and AI becomes a force multiplier for attackers, those of us tasked with defending our systems have to be more focused, deliberate, and proactive in our approaches. We have to rise up to meet this onslaught of new cyber threats.

In this article, we’ll look at threat intelligence, what it is and why it’s important, how threat intelligence feeds can help us in our daily defense, and how we can create custom threat intelligence feeds that match our organizations’ specific needs.

Understanding Threat Intelligence

Threat intelligence is all the contextual information we need about potential or active cybersecurity threats to help us understand risks. These pieces of information are called threat intelligence indicators. Examples include malicious IPs, domains, malware hashes, and attacker tactics.

Threat intelligence is critical—it helps organizations detect, prevent, and respond to threats by enriching the raw security data with indicators and behavioral patterns. The most effective threat intelligence combines technical information with insights about the threat actors’ goals, methods, and infrastructure.

Threat intelligence is crucial for battling alert fatigue and noise. Too much information creates desensitization. We end up responding slowly to, or even ignoring, critical issues. The goal with threat intelligence is to make it meaningful so that we never miss an important alert.

There are several types of threat intelligence indicators. Let’s look at each along with its scope and purpose.

Threat Intelligence Indicators and Feeds

Threat intelligence indicators are often grouped into categories, such as atomic (single pieces of information), computed (information derived from analysis), and behavioral (what the attacker is doing).

We also often group the information into feeds—data streams of threat intelligence indicators that we use to feed our systems ongoing updates about risks and threats. That’s what we’ll focus on here.

Threat intelligence feeds can be:

Strategic feeds - high-level threat trends, emerging risks, and evolving attack vectors, helping with long-term planning and resource prioritization.
Operational feeds - active threats, monitoring the tactics, techniques, and procedures (TTPs) used by adversaries, enabling SOC teams to anticipate and defend against attacks.
Technical feeds - precise, actionable data (such as IP addresses, domains, and malware hashes) that can be used immediately to block known threats.
Tactical feeds - real-time threat data that supports rapid incident response, allowing SOCs to react quickly.

Luckily, you don’t have to build all of these feeds from scratch. Commercial vendors, government agencies, and open-source communities provide pre-built threat intelligence feeds in standard formats such as STIX 2.1 (JSON), OpenloC (XML), and MISP (JSON).

These feeds vary in scope, quality, and specialization. Some focus on nation-state actors and advanced persistent threats (APTs), while others emphasize malware campaigns, botnets, or phishing infrastructure. Security teams can choose to aggregate multiple feeds to build a comprehensive threat picture appropriate for their organization’s needs.

Examples include:

AlienVault OTX - a collaborative threat intelligence platform where security professionals share and consume real-time indicators of compromise (IOCs). It provides access to community-curated threat data, including IPs, domains, malware hashes, and attack patterns.
FBI InfraGard - a partnership between the FBI and the private sector focused on protecting critical infrastructure through trusted information sharing. InfraGard provides private threat intelligence alerts and sector-specific feeds derived from FBI investigations and partnerships with infrastructure operators.
Google Threat Intelligence (previously Mandiant) - delivers high-confidence IOCs, malware signatures, YARA rules, actor profiles, and campaign telemetry. Feeds are accessible via API, STIX/TAXII, and integrations with SIEM/SOAR platforms for automated detection and correlation.

Private Threat Intelligence Feeds

But what if these feeds don’t give you everything you need? In that case, you need to BYOF! (Bring your own feed.)

Private threat intelligence feeds can be created based on your proprietary organizational needs and added to your threat intelligence systems just like industry feeds.

Ideally these private feeds are generated by sifting through your (potentially massive amount of) alerts and events, then intelligently surfacing the most relevant indicators. Once you have created your private feed, you can combine it with the standard threat intelligence feeds above. This creates a customized view of threats that allows your security team to zero in and respond to threats quickly.

But creating these private feeds can be a challenge. You need to build a system that can store, aggregate, analyze, and combine industry feeds with your private feeds as well as display the information to the security team and integrate with other common tools, all while keeping the system reliable, scalable, and secure.

Most organizations prefer to leverage a solid existing platform and focus their resources on their core competencies. Let’s look at one way this can be done. For our example, we’ll use Sumo Logic—a cloud-based log management and analytic service most people are familiar with.

How to Bring Your Own Feeds to Sumo Logic

With Sumo Logic, we can use both existing industry feeds and our own custom feeds. Let’s look at how to add both industry and private feeds through the web UI.

Set Up the Permissions

First, if you haven’t already, go to the administration menu and create a new role with the threat intel capabilities.

Navigate to Threat Intelligence Configuration

Now go to the Configuration menu. In the Logs section, click Threat Intelligence.

You can also just browse directly to https://service.sumologic.com/threat-intelligence.

Pre-Built Feeds

You’ll see right away that Sumo Logic already provides pre-built global threat intelligence feeds: Intel471 and CrowdStrike.

Intel471 provides threat intelligence focused on adversary behavior gathered from sources like the dark web and criminal forums. Its feed includes actor profiles, early warnings about planned attacks, malware and exploit kit tracking, and context-rich indicators of compromise (IOCs) tied to specific threat actors.
CrowdStrike delivers intelligence derived from real-time endpoint and cloud telemetry collected via its Falcon platform. It includes high-confidence IOCs, adversary attribution, and detailed insight into tactics, techniques, and procedures (TTPs) observed during live attacks, often mapped to the MITRE ATT&CK framework.

Together, these feeds give you a great start with a complementary view of the threat landscape: Intel471 focused on attacker intent and planning, and CrowdStrike on active execution and observed campaigns.

Adding a New Custom Indicator (BYOF)

But we don’t want to just use the pre-built feeds. We want to add our own custom indicator (and eventually feed). So let’s do that next.

There are three supported formats:

We’ll use JSON. Here’s an example:

{
 "indicators": [
   {
     "id": "0001",
     "indicator": "192.0.2.0",
     "type": "ipv4-addr",
     "source": "TAXII2Source",
     "validFrom": "2023-03-21T12:00:00.000Z",
     "validUntil": "2025-03-21T12:00:00.000Z",
     "confidence": 30,
     "threatType": "malicious-activity",
     "actors": "actor1,actor2",
     "killChain": "reconnaissance",
     "fields": {
       "kill_chain_name": "lockheed-martin-cyber-kill-chain",
       "kill_chain_phase": "reconnaissance"
     }
   },
   {
     "id": "0002",
     "indicator": "192.0.2.1",
     "type": "ipv4-addr",
     "source": "TAXII2Source",
     "validFrom": "2023-03-21T12:00:00.000Z",
     "validUntil": "2025-03-21T12:00:00.000Z",
     "confidence": 30,
     "threatType": "malicious-activity",
     "actors": "actor3,actor4",
     "killChain": "reconnaissance",
     "fields": {
       "kill_chain_name": "lockheed-martin-cyber-kill-chain",
       "kill_chain_phase": "reconnaissance"
     }
   }
 ]
}

See the Threat Intelligence Indicators documentation from Sumo Logic for more details.

Custom indicators will show up after a few minutes.

Updating Indicators

As you may have noticed, this isn’t a dynamic feed that Sumo Logic can query and refresh. Instead, we created a feed that needs periodically updated with the latest threat intelligence.

Why a push-based model? This is quite common and allows Sumo Logic to maintain secure boundaries (no storage of credentials, no webhook/API at risk for attacks) and remove any reliability risks tied to external systems. This also ensures that ingestion is deliberate, standardized, and under the organization’s control.

Build Your Own Feed

With the above, we can now build our own private threat intelligence feed and combine it with the industry feeds above, creating a customized feed that meets our organization’s exact needs.

Building your own feed requires a plan and careful execution. Here are some questions your plan should address:

What threat indicators do you want to expose to Sumo Logic?
Do you expose a single indicator or multiple indicators?
How do you collect the relevant information from your system?
How do you filter and prepare the data?
How often do you upload/update indicators?

For example, let’s say we have a periodic scan of our S3 buckets to ensure they are not public. But some S3 buckets contain public assets that should have public read access. A smart private feed can compare the list of public buckets against a whitelist and upload only the public buckets not in the list.

Once you have your answers (and indicators), you build a service that collects, filters, and uploads the indicator files to the Sumo Logic API at regular intervals (or when urgent threats are detected). Sumo Logic will combine this feed with the other selected industry feeds for a customized set of indicators for your organization.

Conclusion

Integrating threat intelligence into your security operations is essential for staying ahead of rapidly evolving cyber threats. By leveraging both public and private threat intelligence feeds, we can gain a better understanding of the threat landscape. And ultimately, we can take faster, more precise action.

Have a really great day!

One Checkbox to Cloud: Migrating from Tosca DEX Agents to E2G

John Vester — Sat, 05 Jul 2025 20:51:38 +0000

If you saw my recent article on the Elastic Execution Grid (E2G), you know I’ve been exploring newer releases in the Tosca ecosystem. It’s been a great learning experience.

But I was thinking that for some readers, you might be sitting comfortably with your DEX testing workflows. And you might be a little stuck in the “hey it works fine for me—no need to change” mindset. Or even sitting on the “sounds like way too much work” excuse.

If you are, I think you should reconsider. Because not only is it simple to switch to E2G, but by doing so you’ll see some substantial benefits that will be worth your time.

In this article, I want to look again at the Elastic Execution Grid. But this time, I’ll walk through how simple the changeover is from DEX to E2G and why I think you should go for the upgrade.

Should I switch to E2G?

First, let’s talk about why you should switch.

My first reason for changing—flexibility. Instead of being locked into the expense and time of configuring and maintaining your own fleet of machines, with E2G you have much more flexibility.

You can pick from three types of agents in E2G. (Note: if you don’t know much about E2G, or its agent types, you can read all the details in my previous article).

Personal Agents: your own local agents for one-off runs
Team Agents: self-managed VMs (on-prem or cloud) that run under your control
Cloud Agents: fully managed, disposable instances offering zero-footprint execution

It’s up to you which agent you use for each test, giving you lots of flexibility.

My next reason to switch—simplicity. As you’ll see below, running tests with E2G is simple. For most cases, XML, scripting, and network configs are no longer needed. Now, just tell E2G what agent type, then check if your playlist can run in parallel or if it needs to be run sequentially. Add some characteristics to your tests, and you’re off. If for some reason you still need to control the hardware/VM (such as specialized hardware, custom middleware, etc.) you can always still choose to use the team agents.

My third reason to switch—money! If you pick a cloud option, you no longer need to keep your testing machines. That means you can repurpose your hardware, shut off those pay-by-the-hour VMs, and stop patching and maintaining machines you only use when running tests.

And my final reason? Scaling. When you use the Cloud Agents, you also gain easy scaling. Need more resources? E2G auto-scales your agent pool to match. Need less resources? E2G tears down idle instances. You don’t have to worry about it.

Now let’s look at the other side. Here are some reasons you may not want to switch.

You have strict requirements for on-prem or air-gapped environments. You can’t run on the cloud if you can’t get to the internet!
You have highly predictable, always-on workloads. In some of these cases, a dedicated DEX VM might be more cost-effective and convenient. It’s worth evaluating to see.
As I’ll mention later, there is a cold-start latency with the first run on E2G. If you have ultra-low-latency needs, you may not be able to handle the start time (~60s or less). If every second truly counts and there’s no workaround, a DEX solution is probably better.

How can I move from DEX to E2G?

Now that you know why (or why not) you should make the move, let’s get into how to move from DEX to E2G.

First, we all know that infrastructure changes can present risks. It takes many hours—and headaches—to make major changes. But in most cases, it actually takes minimal effort to change from DEX to E2G. Your core tests don’t need to change. While there will be some effort configuring agents (especially if you have a large number), the actual switching is easy.

Team agents

Your first option is to start with E2G Team Agents. Maybe your organization (or you) just isn’t comfortable with cloud yet. Maybe you have lingering requirements to continue using your boxes. With Team Agents, you still manage your own infrastructure, but E2G manages the Team Agents. So you can retire your old distribution server, but still keep the infrastructure. It’s a baby step to Cloud Agents.

This move is straightforward.

1 - Spin down the DEX server. It’s probably safest to keep the machine provisioned, though, until you’re comfortable with the switch.

2 - Create your E2G Team Agents.

Download and install the Tosca Cloud launcher
Follow the three-step wizard to name the agents, assign them to pool, and define their characteristics.

3 - Execute your playlist! E2G will distribute the tests to available agents and report back with the results.

Cloud Agents

You can also jump straight into Cloud Agents and run your tests on the cloud. No more managing and configuring local hardware. It’s still simple to get started—basically the difference is just a checkbox and some options.

1 - Open the Playlist Details, find the Agent Characteristics tab, and check the “Cloud-agent” box.

2 - Choose your options for run order and recording. If your tests can run in parallel, you could see significant time savings by choosing that option.

3 - That’s it! Now execute your tests.

Regardless of whether you choose Cloud, Person, or Team Agents, the results and logs are shown in the E2G dashboard.

Again, keep in mind that even if you’re using Team Agents, if you ever need specific hardware or configurations, you can always drop back to Team Agents.

Edge cases

The above clear path is pretty easy. But let’s look at some potential problems I’ve run across that you should watch out for:

Mismatched characteristics — Tag mismatches can cause problems. If you mistype or forget to update a tag, E2G won’t find a matching agent, and your runs might get stuck on “Pending.”
Network/data access — Since Cloud Agents live on Tricentis-managed resources, if your app sits behind a VPN, you’ll need to configure appropriately for access.
Cold starts — The first run of a fresh flow can take a bit of time (~60s or less) while the cloud VM spins up.
Custom plugins — If you use custom plugins, you may need extra packaging or installation scripts.

Once you’ve accounted for these edge cases, you should be good to go.

Conclusion

As you can see, moving to the Elastic Execution Grid is pretty easy, and I think the benefits are well worth it. Compared to using DEX Agents, E2G is simple and flexible. It’s exciting to stop managing machines and simply “check a box.” I can’t wait to keep exploring!

For more info, check out this detailed getting started guide.

Have a really great day!

How to Banish Anxiety, Lower MTTR, and Stay on Budget During Incident Response

John Vester — Fri, 27 Jun 2025 01:00:15 +0000

Since I started in technology in 1992 (over three decades ago!), I’ve encountered countless scenarios where I was expected to “do more with less.” Whether it meant delivering more with fewer team members or working within constrained hardware resources, this mindset has been a recurring theme.

One experience stands out from my time as a backend architect on a cloud modernization project. To reduce costs, we were asked to minimize or eliminate service-level logging—logging that we relied on heavily for debugging and incident analysis. The decision was driven by the high cost of log ingestion on our observability platform.

This worked—until it didn’t.

We Really Needed Those Logs!

Inevitably, an unexpected issue arose, and we needed those missing logs. They turned out to be the only way to pinpoint the root cause. Without them, hours ticked by without a solution, uncertainty grew, and anxiety followed the entire team.

// Sample (but not the real) log line removed during our cost-cutting
{
  "timestamp": "2025-03-21T14:05:03Z",
  "service": "preference-engine",
  "level": "ERROR",
  "message": "Worker queue overflow: unable to dispatch to worker pool",
  "requestId": "abc123",
  "userId": "admin_42"
}

Had we kept it, a simple structured error log (such as the above) could have been easily filtered in a logging platform with a simple log query (such as the below) and allowed us to understand, diagnose, and fix the problem.

_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId

Being told to drastically reduce our logging put the entire project into a vulnerable state.

Lean Doesn’t Have to Mean Starved for Resources

To be clear, the “do more with less” mindset isn’t inherently bad. Many startups thrive by focusing on key priorities and leveraging lightweight, efficient software. Minimalist design can lead to better quality, provided that key tooling remains in place.

But this wasn’t the “good” kind of lean. And our deadline to move to the cloud was fixed. We were racing against a browser deprecation date. That meant rewriting services to a cloud-native design, coordinating with client teams, and delivering under pressure. With no time for complete test coverage or deep observability integrations, we relied on logs to resolve our issues and help determine the root cause for unexpected scenarios. That was OK at first, we just inserted the necessary logging while working on each method.

But when logging was cut back, the team was exposed. Our primary safety net was gone.

Root Cause Without a Net

Internal testing went well. As production approached, we felt confident in our new cloud-based architecture. We had resolved known issues in test and met our deadline.

But we soon realized that our confidence was misplaced and our test coverage was lacking.

Once we were in production and real customers were using the platform, those pesky unanticipated edge cases emerged. And of course, without detailed logs or sufficient observability, we had no way to investigate the issue. The limited telemetry available simply wasn’t enough to determine what had gone wrong.

If we had logs for both the backend tests and production customers on the frontend, we could have known what was happening and alerted the team (and the user). It would be a simple log query:

_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message

But without the logs, reproducing the incidents locally was nearly impossible. There was just too much variability in real-world use cases. We attempted to re-enable partial logging, but this just led back to the increased ingestion costs we were asked to cut, without delivering actionable insights.

In some cases, we couldn’t identify the root cause at all. That’s a tough position to be in: knowing there’s a problem affecting users and being unable to explain it. It created a pervasive sense of helplessness across the team.

MTTR versus Signal Quality

Yet another problem was that in our incident retrospectives, mean time to recovery (MTTR) was being treated as a headline metric. But we found that MTTR was most often a symptom, not a root cause.

Industry benchmarks usually show elite teams achieve MTTR in under an hour. But what we realized was that speed isn’t just automation—it’s high-fidelity signals. Low-fidelity signals, such as generic 500 errors or delayed alerting from aggregate metrics, don’t really help. They just introduce ambiguity and waste resources (such as precious triage time and logging budget).

In contrast, detailed, contextual signals—like structured logs with userId, requestId, and a service trace—cut directly to the root cause. Observability platforms can reduce MTTR, but only if the data you ingest is actionable.

If your logs aren’t answering these questions, your MTTR isn’t about team speed—it’s about signal clarity.

How Sumo Logic’s Model Could Have Saved The Day

So what could have gone differently—and better—during my cloud modernization project?

First, I really wish we would have had better log analytics and application performance monitoring (APM). And along with that APM, log management, service monitors, alerts, and defined metrics closely aligned with functional success or failure. I wish (on every project) that for every new feature I had an associated metric tied to its success.

And I want my logs back! In my earlier publication, “DevSecOps: It’s Time To Pay for Your Demand, Not Ingestion,” I explored how Sumo Logic disrupted the observability space by offering a pay-per-analysis model. Logs can be ingested continuously, but you only pay when you need to query or analyze them.

Are you a team without full unit test coverage? Suffering from a lack of real-time alerts or granular metrics? On a tight budget? Withering from lack of logs?

With zero-cost full ingestion, teams can log as much as they need without worries. And when that incident does finally occur (and it will), analysis can be triggered on-demand, at a justifiable cost directly tied to customer impact or business continuity. The budget folks are happy; you’re happy.

This approach restores control and lowers anxiety because teams are empowered to investigate thoroughly when it matters most.

But Wait: You Also Need Machine-Assisted Triage to Clear Up Your Queries

But there’s one more step. Modern observability isn’t just about having all that beautiful log data—it’s also about knowing where to look in that data. As mentioned above, you need organized, high-fidelity signals.

When you have unlimited ingestion, you have a ton of data. And when you start looking for information, you need a place to start. To help, Sumo Logic also provides machine-assisted triage tools that automatically group anomalous behavior, detect outliers, and surface correlated signals across services before you write a single query.

Behind the scenes, Sumo Logic used statistical algorithms and machine learning to:

Cluster logs by similarity (even if phrased differently across nodes).
Detect outliers in metrics and logs (e.g., error spikes per service, region, or user cohort).
Enrich anomalies with metadata (e.g., AWS tags, Kubernetes pod info, deployment markers).
Natural language processing clusters logs by semantic similarity, not just string matching.

This is especially useful in the high-volume environment of unlimited ingest. Instead of sifting through tens of thousands of log lines, you get “log signatures”—condensed patterns that represent groups of related events.

Example Workflow

_sourceCategory=prod/* error
| logreduce

This single command clusters noisy log data into actionable buckets like:

Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *

Once clustered, teams can pivot to deeper context:

| where message matches "Auth token expired*"
| count by userId, region

The result? Fewer blind searches. Faster decision paths. Less anxiety during an incident.

Conclusion

The “do more with less” philosophy doesn’t have to put engineering teams at a disadvantage. But it must be accompanied by the right tools. Without them, even the most capable teams can feel like they’re navigating aimlessly during an incident—leading to frustration and stress.

My readers may recall my personal mission statement, which I feel can apply to any IT professional:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester

In this article, we looked at how a zero-cost ingestion model aligns with this mission. It helps teams quickly identify root causes, reduce downtime, and lower stress levels—all without breaking the budget. Let’s keep those logs!

Have a really great day!

Exploring Cloud-Based Testing with the Elastic Execution Grid

John Vester — Sat, 21 Jun 2025 10:42:51 +0000

You know those regression packs that used to finish while you grabbed coffee? Are they now taking hours? And that testing box you requisitioned six months ago? Is it already maxed out? And do you find yourself complaining about how resources are idling 90% of the day?

Yes, it’s time to look at cloud-based testing. Which is exactly what I recently started doing. I wanted to find a testing solution that was fast, easy, and gave me flexible capacity. And one that took minimal effort for me to maintain.

My first trial was the Tricentis Elastic Execution Grid (E2G). In this article I’ll cover what it is, what it does, and what I thought.

What is the Elastic Execution Grid?

The Tricentis Elastic Execution Grid (E2G) is “a cloud-based environment where you can run and track tests over time.”

E2G lets you run tests on cloud infrastructure that spins up when you need to run your tests … and spins down when you don’t. With E2G you aren’t required to maintain your own testing infrastructure or pay for idling computing resources.

Note that E2G is flexible. It allows you to run your tests on your infrastructure or on Tricentis cloud resources. Team agents allow you to use your own infrastructure — whether that’s virtual, physical, or private cloud. In this article, however, I’m concerned only with the cloud agents that run on Tricentis resources. I want to be able to run my tests without providing my own hardware. In this article, I’ll explore these cloud agents, but don’t forget that E2G lets you choose to run on your own infrastructure as well.

E2G is framework-agnostic. You can use it with Tosca, but also with other frameworks like PowerShell. At its core, E2G is a control plane that:

Spins up short‑lived “agents” when a run is queued.
Routes each test to an agent that has the required tooling, then streams logs back in real-time.

I love this idea of zero-footprint testing. With the cloud agents, I can just define a few properties and E2G automatically provisions (and scales) the compute resources necessary to run my test suite.

How does the Elastic Execution Grid work?

Let’s look at the architecture to understand how E2G works. E2G consists of four components: agents, agent services, characteristics, and runners.

Agents are the machines where you run your tests. They host the Agent Service and the Runner.
Agent services receive the tests from the server and hand them to the Runner
Runners are the actual test frameworks that execute the tests.

Characteristics define what applications your tests can work with. For example, if your tests work with MS Excel, your agent would have an “Excel” characteristic.

Here’s how it all works together:

Push your tests to E2G - You design tests in your framework (Tosca, PowerShell, open‑source tools) and push them to E2G. The service stores your artifacts, queues and runs.
Characteristics - Each E2G Agent has characteristics as defined above (Excel, SAP, specific browser versions, etc). When you tag a test with its characteristics, E2G dispatches it only to agents that match. This guarantees the right tooling is present without over‑provisioning every box.
Execute agents - The Agent Service pulls the next test and hands it to the Runner, which pretends to be a user and executes the test. The Runner inherits the host machine’s permissions, so whatever apps or files your tests touch must already exist (for example, Excel must be installed if the test writes to a spreadsheet).
Collect results - When execution finishes, the agent sends back logs, screenshots, and pass/fail status for your review.

E2G in Action

Let’s try this all out. Once you have your free trial you’re ready. It’s a pretty simple process.

To run a test playlist on a cloud agent, open the Agent Characteristics tab of the Playlist details for the playlist you want to run and check the “Cloud-agent” box. Tosca will know that you need a cloud agent provisioned.

Click to start your tests and Tosa will schedule them in the Test Run tab of Tosca. You can track the progress of your test suite from here. E2G will scale the cloud resources as needed—I don’t have to worry about any bottlenecks.

The tests shown here are some of the samples that were provisioned for my trial account.

E2G can also split a test suite across multiple agents to speed up runs. You can indicate tests that can run in parallel on the playlist. You can also mark tests as dependent on each other to force them to run in a certain sequence.

What happens when things go wrong?

One concern I have with cloud-based testing is debugging. While ephemeral testing infrastructure is easier to manage than dedicated testing machines, using it also means that debugging can be more difficult.

In E2G, it’s just like debugging local tests. When a playlist is sent, whether through cloud agents or team agents, the outcome is reported in the test run interface. Here you can see pass/fail, progress, and eventual outcome of the playlist.

You can click in here on a specific test and see details of why your tests passed or failed, including any logs or screen recordings.

The ability to click straight into the failing test case makes remediation just about the same as it usually is. I can see situations where I might need more detail … but as a back-up I can always run the tests on my local machine using Tosca’s personal agent.

How secure is E2G?

Another concern I have with cloud-based testing infrastructure is regulatory or policy requirements. Here’s what I found for E2G:

Tricentis is SOC/ISO compatible.
The VMs used for cloud testing are temporary. As soon as your tests are over, they are terminated. Since they no longer exist, they don’t exist as attack vectors or as a gateway to your infrastructure.
All data is encrypted and transferred via HTTPS
Uploads (test artifacts, results) are stored for 28 days, then deleted

My remaining questions

There are a couple areas where I still had concerns:

You are default limited to 50 concurrent agents and 50MB artifacts. This could limit your ability to run a large number of tests in parallel or could limit the size of your data files. However, you can request a bump if you need more.
I feel like there are still situations where I will want (or need?) to run a test locally. Just to have that minute control and information. Of course, I can just choose the personal agent with E2G and do just that! So this really is just me getting comfortable with cloud testing. We’ll see if I get more comfortable as time goes on.

Give it a try!

Cloud-based testing is here and I’m a fan. I don’t expect a magic bullet for all my problems—but I’m excited to finally have a way to manage spikes and wasted resources. Renting 20 agents for 10 minutes seems better than owning two agents forever. And E2G feels like a solid solution. I like the framework flexibility and ease of switching between cloud and local tests in one place. I look forward to exploring it more.

Have a really great day!

The Missing Infrastructure Layer: Why AI's Next Evolution Requires Distributed Systems Thinking

John Vester — Fri, 13 Jun 2025 10:27:41 +0000

The recent announcement of KubeMQ-Aiway caught my attention not as another AI platform launch, but as validation of a trend I've been tracking across the industry. After spending the last two decades building distributed systems and the past three years deep in AI infrastructure consulting, the patterns are becoming unmistakable: we're at the same inflection point that microservices faced a decade ago.

The Distributed Systems Crisis in AI

We've been here before. In the early 2010s, as monolithic architectures crumbled under scale pressures, we frantically cobbled together microservices with HTTP calls and prayed our systems wouldn't collapse. It took years to develop proper service meshes, message brokers, and orchestration layers that made distributed systems reliable rather than just functional.

The same crisis is unfolding with AI systems, but the timeline is compressed. Organizations that started with single-purpose AI models are rapidly discovering they need multiple specialized agents working in concert—and their existing infrastructure simply wasn't designed for this level of coordination complexity.

Why Traditional Infrastructure Fails AI Agents

Across my consulting engagements, I'm seeing consistent patterns of infrastructure failure when organizations try to scale AI beyond proof-of-concepts:

HTTP Communication Breaks Down: Traditional request-response patterns work for stateless operations but fail when AI agents need to maintain context across extended workflows, coordinate parallel processing, or handle operations that take minutes rather than milliseconds. The synchronous nature of HTTP creates cascading failures that bring down entire AI workflows.

Context Fragmentation Destroys Intelligence: AI agents aren't just processing data—they're maintaining conversational state and building accumulated knowledge. When that context gets lost at service boundaries or fragmented across sessions, the system's collective intelligence degrades dramatically.

Security Models are Fundamentally Flawed: Most AI implementations share credentials through environment variables or configuration files. This creates lateral movement risks and privilege escalation vulnerabilities that traditional security models weren't designed to handle.

Architectural Constraints Force Bad Decisions: Tool limitations in current AI systems force teams into anti-patterns—building meta-tools, fragmenting capabilities, or implementing complex dynamic loading mechanisms. Each workaround introduces new failure modes and operational complexity.

Evaluating the KubeMQ-Aiway Technical Solution

KubeMQ-Aiway is “the industry’s first purpose-built connectivity hub for AI agents and Model-Context-Protocol (MCP) servers. It enables seamless routing, security, and scaling of all interactions—whether synchronous RPC calls or asynchronous streaming—through a unified, multi-tenant-ready infrastructure layer.” In other words, it’s the hub that manages and routes messages between systems, services, and AI agents.

Through their early access program, I recently explored KubeMQ-Aiway's architecture. Several aspects stood out as particularly well-designed for these challenges:

Unified Aggregation Layer: Rather than forcing point-to-point connections between agents, they've created a single integration hub that all agents and MCP servers connect through. This is architecturally sound—it eliminates the N-squared connection problem that kills system reliability at scale. More importantly, it provides a single point of control for monitoring, security, and operational management.
Multi-Pattern Communication Architecture: The platform supports both synchronous and asynchronous messaging natively, with pub/sub patterns and message queuing built-in. This is crucial because AI workflows aren't purely request-response—they're event-driven processes that need fire-and-forget capabilities, parallel processing, and long-running operations. The architecture includes automatic retry mechanisms, load balancing, and connection pooling that are essential for production reliability.
Virtual MCP Implementation: This is particularly clever—instead of trying to increase tool limits within existing LLM constraints, they've abstracted tool organization at the infrastructure layer. Virtual MCPs allow logical grouping of tools by domain or function while presenting a unified interface to the AI system. It's the same abstraction pattern that made container orchestration successful.
Role-Based Security Model: The built-in moderation system implements proper separation of concerns with consumer and administrator roles. More importantly, it handles credential management at the infrastructure level rather than forcing applications to manage secrets. This includes end-to-end encryption, certificate-based authentication, and comprehensive audit logging—security patterns that are proven in distributed systems but rarely implemented correctly in AI platforms.

Technical Architecture Deep Dive

What also impresses me is their attention to distributed systems fundamentals:

Event Sourcing and Message Durability: The platform maintains a complete audit trail of agent interactions, which is essential for debugging complex multi-agent workflows. Unlike HTTP-based systems where you lose interaction history, this enables replay and analysis capabilities that are crucial for production systems.

Circuit Breaker and Backpressure Patterns: Built-in failure isolation prevents cascade failures when individual agents malfunction or become overloaded. The backpressure mechanisms ensure that fast-producing agents don't overwhelm slower downstream systems—a critical capability when dealing with AI agents that can generate work at unpredictable rates.

Service Discovery and Health Checking: Agents can discover and connect to other agents dynamically without hardcoded endpoints. The health checking ensures that failed agents are automatically removed from routing tables, maintaining system reliability.

Context Preservation Architecture: Perhaps most importantly, they've solved the context management problem that plagues most AI orchestration attempts. The platform maintains conversational state and working memory across agent interactions, ensuring that the collective intelligence of the system doesn't degrade due to infrastructure limitations.

Production Readiness Indicators

From an operational perspective, KubeMQ-Aiway demonstrates several characteristics that distinguish production-ready infrastructure from experimental tooling:

Observability: Comprehensive monitoring, metrics, and distributed tracing for multi-agent workflows. This is essential for operating AI systems at scale where debugging requires understanding complex interaction patterns.
Scalability Design: The architecture supports horizontal scaling of both the infrastructure layer and individual agents without requiring system redesign. This is crucial as AI workloads are inherently unpredictable and bursty.
Operational Simplicity: Despite the sophisticated capabilities, the operational model is straightforward—agents connect to a single aggregation point rather than requiring complex service mesh configurations.

Market Timing and Competitive Analysis

The timing of this launch is significant. Most organizations are hitting the infrastructure wall with their AI implementations right now, but existing solutions are either too simplistic (basic HTTP APIs) or too complex (trying to adapt traditional service meshes for AI workloads).

KubeMQ-Aiway appears to have found the right abstraction level—sophisticated enough to handle complex AI orchestration requirements, but simple enough for development teams to adopt without becoming distributed systems experts.

Compared to building similar capabilities internally, the engineering effort would be substantial. The distributed systems expertise required, combined with AI-specific requirements, represents months or years of infrastructure engineering work that most organizations can't justify when production AI solutions are available.

Strategic Implications

For technology leaders, the emergence of production-ready AI infrastructure platforms changes the strategic calculation around AI implementation. The question shifts from "should we build AI infrastructure" to "which platform enables our AI strategy most effectively."

Early adopters of proper AI infrastructure are successfully running complex multi-agent systems at production scale while their competitors struggle with basic agent coordination. This gap will only widen as AI implementations become more sophisticated.

The distributed systems problems in AI won't solve themselves, and application-layer workarounds don't scale. Infrastructure solutions like KubeMQ-Aiway represent how AI transitions from experimental projects to production systems that deliver sustainable business value.

Organizations that recognize this pattern and invest in proven AI infrastructure will maintain competitive advantage over those that continue trying to solve infrastructure problems at the application layer.

Have a really great day!

How To Introduce a New API Quickly Using Micronaut

John Vester — Wed, 28 May 2025 13:27:42 +0000

In the first two articles of this series (part 1 and part 2), I demonstrated how quickly an idea can become a reality using Spring Boot, the framework I have used for over 10 years to establish new services. I stepped out of my comfort zone in the last article (part 3) when I used Quarkus for the first time, which offered a really nice CLI to assist with the development process.

I would like to close out this short series with another framework that’s new (to me), called Micronaut.

Micronaut is an open-source JDK-based framework focused on lightweight microservices. Under the hood, Micronaut does not rely on reflective programming, but emphasizes an inversion of control (IoC) design which results in less memory usage and a much faster start time. A robust CLI exists too.

While the service should start fast, the biggest question I have is: “How quickly can I transform my motivation quotes idea to a reality using Micronaut?”

Getting Started with Micronaut

As noted above, just like with Spring Boot and Quarkus, Micronaut also has a CLI (mn). There is also an initializer (called a launcher), which is very similar to what Spring Boot offers. For this article, we’ll use the CLI, and I’ll use Homebrew to perform the install:

$ brew install --cask micronaut-projects/tap/micronaut

Other installation options can be found here.

To get started, we’ll issue the mn command:

$ mn

For MacOS users, you will likely need to visit the Privacy & Security section in System Settings to allow the use of the mn command.

We’ll simply use create to interactively initialize a new service:

mn> create

Apr 01, 2025 2:52:20 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
What type of application do you want to create? (enter for default)
*1) Micronaut Application
 2) Micronaut CLI Application
 3) Micronaut Serverless Function
 4) Micronaut gRPC Application
 5) Micronaut Messaging Application

We’ll select the default option to create a new application.

Choose your preferred language. (enter for default)
*1) Java
 2) Groovy
 3) Kotlin

We’ll use Java for this exercise.

Choose your preferred test framework. (enter for default)
*1) JUnit
 2) Spock
 3) Kotest

We’ll use JUnit for our test framework.

Choose your preferred build tool. (enter for default)
*1) Gradle (Groovy)
 2) Gradle (Kotlin)
 3) Maven

We’ll plan to use Gradle (Groovy) this time.

Choose the target JDK. (enter for default)
*1) 17
 2) 21

We’ll stick with Java 17, since it matches what we’ve used for other articles in this series.

Enter any features to apply. Use tab for autocomplete and separate by a space.

For now, we’ll add support for OpenAPI and Swagger and press the return key:

openapi swagger-ui

Enter a name for the project.

We’ll use the name quotes-micronaut for our project.

Now let’s exit out of mn using Control-C and check out the base directory structure:

$ cd quotes-micronaut && ls -la
total 88
drwxr-xr-x@ 13 johnvester   416 Apr  1 14:58 .
drwxrwxrwx  93 root        2976 Apr  1 14:58 ..
-rw-r--r--@  1 johnvester   127 Apr  1 14:58 .gitignore
-rw-r--r--@  1 johnvester  1380 Apr  1 14:58 README.md
-rw-r--r--@  1 johnvester  1590 Apr  1 14:58 build.gradle
drwxr-xr-x@  3 johnvester    96 Apr  1 14:58 gradle
-rw-r--r--@  1 johnvester    23 Apr  1 14:58 gradle.properties
-rwxr--r--@  1 johnvester  8762 Apr  1 14:58 gradlew
-rw-r--r--@  1 johnvester  2966 Apr  1 14:58 gradlew.bat
-rw-r--r--@  1 johnvester   367 Apr  1 14:58 micronaut-cli.yml
-rw-r--r--@  1 johnvester   182 Apr  1 14:58 openapi.properties
-rw-r--r--@  1 johnvester    39 Apr  1 14:58 settings.gradle
drwxr-xr-x@  4 johnvester   128 Apr  1 14:58 src

We can open the project in IntelliJ and run the Application class:

 __  __ _                                  _   
|  \/  (_) ___ _ __ ___  _ __   __ _ _   _| |_ 
| |\/| | |/ __| '__/ _ \| '_ \ / _` | | | | __|
| |  | | | (__| | | (_) | | | | (_| | |_| | |_ 
|_|  |_|_|\___|_|  \___/|_| |_|\__,_|\__,_|\__|
15:01:56.083 [main] INFO  io.micronaut.runtime.Micronaut - 
Startup completed in 648ms. Server Running: http://localhost:8080

We can validate that the RESTful API is working, too, by calling the URI configured in the QuotesMicronautController class.

@Controller("/quotes-micronaut")
public class QuotesMicronautController {
    @Get(uri="/", produces="text/plain")
    public String index() {
        return "Example Response";
    }
}

We’ll use the following cURL command:

curl --location 'http://localhost:8080/quotes-micronaut'

This returns the following text:

Example Response

The only difference I saw with using the CLI over the launcher is that I wasn’t able to specify a base package. That’s okay, because we can use the CLI to establish the rest of our classes:

$ mn create-bean quotes.micronaut.repositories.QuotesRepository
$ mn create-bean quotes.micronaut.services.QuotesService
$ mn create-bean quotes.micronaut.controllers.QuotesController

You’ll notice we are creating our own controller class. This is simply to follow the same approach I’ve used in my earlier articles. The auto-generated QuotesMicronautController would have worked just fine.

To make things less complicated for the injection side of things, we can use Lombok, adding the following dependencies to the build.gradle file:

compileOnly("org.projectlombok:lombok")
annotationProcessor("org.projectlombok:lombok")

Minor Roadblock with OpenAPI Generation

When I looked up the server-side OpenAPI generators, I was excited to see java-micronaut-server as an option. Upon further review, the documentation indicated this has a stability level of “BETA.”

The beta version was able to generate the expected Quote model object, but I ran into issues trying to generate an interface or abstract class that my controllers could extend. So I decided to create an issue in the openapi-generator library (link for those who are interested in the details) and pivot toward another approach.

Using Cursor AI to Convert My Quarkus Service

While sharing this experience with Alvin Lee (a longtime colleague), he had an idea. Alvin asked, “What if we use Cursor AI to analyze your Quarkus repo and port it to Micronaut for us?”

I told Alvin to “go for it” and became excited, because this article really had not required the use of AI like the other articles in the series.

I gave Alvin access to fork my Quarkus repo and within a matter of minutes, the service was completely ported to Micronaut. Let’s quickly review the classes that were created automatically.

First, let’s review the repository layer:

@Singleton
public class QuotesRepository {
  private static final List<Quote> QUOTES = List.of(
    Quote.builder()
      .id(1)
      .quote("The greatest glory in living lies not in never falling, but in rising every time we fall.")
      .build(),
    Quote.builder()
      .id(2)
      .quote("The way to get started is to quit talking and begin doing.")
      .build(),
    Quote.builder()
      .id(3)
      .quote("Your time is limited, so don't waste it living someone else's life.")
      .build(),
    Quote.builder()
      .id(4)
      .quote("If life were predictable it would cease to be life, and be without flavor.")
      .build(),
    Quote.builder()
      .id(5)
      .quote("If you set your goals ridiculously high and it's a failure, you will fail above everyone else's success.")
      .build()
  );

  public List<Quote> getAllQuotes() {
    return QUOTES;
  }

  public Optional<Quote> getQuoteById(Integer id) {
    return QUOTES.stream().filter(quote -> 
      quote.getId().equals(id)).findFirst();
  }
}

Next, let’s take a look at the service layer:

@Singleton
public class QuotesService {
  private final QuotesRepository quotesRepository;

  @Inject
  public QuotesService(QuotesRepository quotesRepository) {
    this.quotesRepository = quotesRepository;
  }

  public List<Quote> getAllQuotes() {
    return quotesRepository.getAllQuotes();
  }

  public Optional<Quote> getQuoteById(Integer id) {
    return quotesRepository.getQuoteById(id);
  }

  public Quote getRandomQuote() {
    List<Quote> quotes = quotesRepository.getAllQuotes();
    return quotes.get(ThreadLocalRandom.current().nextInt(quotes.size()));
  }
}

Finally, we can examine the controller that will be the consumer-facing interface to our API:

@Controller("/quotes")
public class QuotesController {
  @Inject
  private QuotesService quotesService;

  @Get
  public List<Quote> getAllQuotes() {
    return quotesService.getAllQuotes();
  }

  @Get("/{id}")
  public Optional<Quote> getQuoteById(@PathVariable Integer id) {
    return quotesService.getQuoteById(id);
  }

  @Get("/random")
  public Quote getRandomQuote() {
    return quotesService.getRandomQuote();
  }
}

Validating Our Service Locally

To validate the service locally, we’ll start the service from IntelliJ like we did before:

 __  __ _                                  _   
|  \/  (_) ___ _ __ ___  _ __   __ _ _   _| |_ 
| |\/| | |/ __| '__/ _ \| '_ \ / _` | | | | __|
| |  | | | (__| | | (_) | | | | (_| | |_| | |_ 
|_|  |_|_|\___|_|  \___/|_| |_|\__,_|\__,_|\__|
21:18:54.740 [main] INFO  io.micronaut.runtime.Micronaut - 
Startup completed in 284ms. Server Running: http://localhost:8080

With all the code in place, the Micronaut service started in just 284 milliseconds.

We’ll use the following cURL command to retrieve a random motivational quote:

curl --location 'http://localhost:8080/quotes/random'

I received a 200 OK HTTP response and the following JSON payload:

{
  "id": 3,
  "quote": "Your time is limited, so don't waste it living someone else's life."
}

Looks like the port was quick and successful! Now it is time to deploy.

Leveraging Heroku to Deploy the Service

Since I used Heroku for my prior articles, I wondered if support existed for Micronaut services.

Although Heroku recently published some updated information regarding Micronaut support in its Java buildpack, I felt like I could use my existing experience to get things going. Selecting Heroku helps me deploy my services quickly, and I don’t lose time dealing with infrastructure concerns.

The first thing I needed to do was add the following line to the application.properties file to make sure the server’s port could be overridden by Heroku:

micronaut.server.port=${PORT:8080}

Next, I created a system.properties file to specify we are using Java version 17:

java.runtime.version = 17

Knowing that Heroku runs the “stage” Gradle task as part of the deployment, we can specify this in the manifest file we plan to use by adding the following lines to the build.gradle file:

jar {
  manifest {
    attributes(
      'Main-Class': 'quotes.micronaut.Application'
    )
  }
}

task stage(dependsOn: ['build', 'clean'])

build.mustRunAfter clean

Ordinarily, for running apps on Heroku, we would need to add a Procfile, where we specify the Heroku environment, reference the path to where the stage-based JARs will reside, and use the port set by Heroku. That file might look like this:

web: java $JAVA_OPTS -Dmicronaut.environments=heroku -Dserver.port=$PORT -jar build/libs/*.jar

However, on detecting a Micronaut app, the Heroku buildpack defaults to this:

java -Dmicronaut.server.port=$PORT $JAVA_OPTS -jar build/libs/*.jar

… and that's exactly what I need. No need for a Procfile after all! That's pretty slick.

Now we just need to login to Heroku and create a new application:

$ heroku login 
$ heroku create

The CLI responds with the following response:

Creating app... done, ⬢ aqueous-reef-26810
https://aqueous-reef-26810-4db1994daff4.herokuapp.com/ | 
https://git.heroku.com/aqueous-reef-26810.git

The Heroku app instance is named aqueous-reef-26810-4db1994daff4, so my service will run at https://aqueous-reef-26810-4db1994daff4.herokuapp.com/.

One last thing to do … push the code to Heroku, which deploys the service:

$ git push heroku main

Switching to Heroku dashboard, we see our service has deployed successfully:

We are now ready to give our service a try from the internet.

Motivational Quotes in Action

Using the Heroku app URL, https://aqueous-reef-26810-4db1994daff4.herokuapp.com/, we can now test our Motivational Quotes API using curl commands.

First, we retrieve the list of quotes:

curl --location 'https://aqueous-reef-26810-4db1994daff4.herokuapp.com/quotes'

[
    {
        "id": 1,
        "quote": "The greatest glory in living lies not in never falling, but in rising every time we fall."
    },
    {
        "id": 2,
        "quote": "The way to get started is to quit talking and begin doing."
    },
    {
        "id": 3,
        "quote": "Your time is limited, so don't waste it living someone else's life."
    },
    {
        "id": 4,
        "quote": "If life were predictable it would cease to be life, and be without flavor."
    },
    {
        "id": 5,
        "quote": "If you set your goals ridiculously high and it's a failure, you will fail above everyone else's success."
    }
]

We can retrieve a single quote by its ID:

curl --location 'https://aqueous-reef-26810-4db1994daff4.herokuapp.com/quotes/4'

{
    "id": 4,
    "quote": "If life were predictable it would cease to be life, and be without flavor."
}

We can retrieve a random motivational quote:

curl --location 'https://aqueous-reef-26810-4db1994daff4.herokuapp.com/quotes/random'

{
    "id": 3,
    "quote": "Your time is limited, so don't waste it living someone else's life."
}

We can even view the auto-generated Swagger UI via Heroku:

Conclusion

In this article, I had to step outside my comfort zone again—this time working with Micronaut for the very first time. Along the way, I ran into an unexpected issue which caused me to pivot my approach to leverage AI—more specifically: Cursor. Once ready, I was able to use my existing knowledge to deploy the service to Heroku and validate everything was working as expected.

My readers may recall my personal mission statement, which I feel can apply to any IT professional:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester

Micronaut offered a fully-functional CLI and a service which started the fastest of all the frameworks in the series. Cursor helped us stay on track by porting our Quarkus service to Micronaut. Like before, Heroku provided a fast and easy way to deploy the service without having to worry about any infrastructure concerns.

All three key solutions fully adhered to my mission statement, allowing me to not only be able to focus on my idea, but to make it an internet-accessible reality … quickly!

If you are interested in the source code for this article, it is available on GitLab.

Have a really great day!