25 posts tagged with "Architecture"

STOA runs 9 parallel security jobs on every pull request — secret scanning, SAST for three languages, dependency audits, container scanning, license compliance, SBOM generation, and commit signature verification. This article breaks down each job, explains what it catches, and shows you how to adopt the same approach in your own projects. This is part of our open-source API gateway philosophy: security scanning should be built into CI, not bolted on after a breach.

Proxy throughput benchmarks tell you how fast a gateway can forward HTTP requests. They tell you nothing about whether that gateway can serve AI agents, enforce guardrails on tool calls, or govern autonomous sessions. We built a new benchmark that measures what actually matters.

A single developer shipping 72 story points per day across 7 components, 22 PRs per week, with zero regressions on main. This is not a theoretical exercise — it is the measured output of STOA Platform's AI Factory during Cycle 7 (February 9-15, 2026). This article explains the architecture, the coordination protocols, and the hard lessons that make it work.

If you are building an MCP gateway or any complex open-source platform, the patterns described here are directly reusable. They are not tied to STOA — we extracted them into a reusable pattern library (HEGEMON) that any project can adopt.

Kubernetes-native API gateway patterns have evolved from simple Ingress controllers to sophisticated multi-mode architectures that support AI agents, service mesh integration, and GitOps workflows. This guide covers the four essential patterns — Ingress Controller, Gateway API, sidecar gateway, and MCP gateway — with architecture diagrams, implementation examples, and a decision framework for choosing the right pattern for your use case.

GitOps means your infrastructure is defined in Git and automatically deployed from it. This guide explains what GitOps is, why it matters for solo devs and small teams, and how to start — from versioning config files to full ArgoCD automation.

You know how to git push your code. But what about your infrastructure?

Your Nginx config, your firewall rules, your database credentials, your Kubernetes manifests — where do they live? If the answer involves SSH, a shared Wiki page, or "ask Jean-Michel, he set it up" — you have a problem.

GitOps means treating infrastructure the same way you treat code: versioned, reviewed, auditable, and automatically deployed from a Git repo. No more SSH. No more "works on my machine." No more mystery configs.

GitOps is a core principle of open-source API management — and one of the reasons STOA was designed GitOps-first from day one.

The API gateway landscape has evolved rapidly with the rise of AI agents, zero-trust architectures, and hybrid deployments. This glossary defines 30 essential terms every developer should know when working with modern API gateways in 2026.

STOA Gateway adds less than 2 microseconds of total overhead per request with API key auth and rate limiting enabled. Every benchmark is reproducible with published scripts, and our Gateway Arena runs comparative tests every 30 minutes on identical infrastructure.

This post shares our benchmarking approach, key results, and how you can reproduce everything yourself.

The Model Context Protocol (MCP) is a JSON-RPC 2.0 based protocol that standardizes how AI agents discover, authenticate with, and invoke external tools. It defines four phases — initialization, discovery, invocation, and streaming — over pluggable transports including SSE, WebSocket, and stdio. This article covers the protocol internals that matter for production deployments.

Three approaches dominate how AI agents call external tools in 2026: the Model Context Protocol (MCP), OpenAI Function Calling, and LangChain Tools. MCP is an open protocol for runtime tool discovery across any AI provider. OpenAI Function Calling is a proprietary API feature tightly integrated with OpenAI models. LangChain Tools is a framework abstraction that wraps tool definitions for orchestration pipelines. They solve different problems, operate at different layers, and can coexist in the same architecture.

Migrating from IBM DataPower or TIBCO requires separating gateway routing from protocol-specific functions. This guide covers a sidecar approach: deploy STOA for REST/JSON traffic, federate identity via OIDC, and keep legacy systems for B2B protocols where they excel.

IBM DataPower and TIBCO BusinessWorks represent two of the most deeply embedded integration platforms in enterprise IT. Both handle critical workloads — security token services, multi-protocol mediation, B2B gateway functions — that organizations depend on daily.

This guide provides a practical assessment of migration approaches for organizations evaluating modernization paths from these platforms.