AI agents are getting good at browsing the web. But they still interact with most sites by scraping HTML and guessing at structure. That is not great for anyone. WebMCP changes that. It lets websites register tools that AI agents can call directly, the same way MCP works with Claude or other AI tools, except it runs in the browser instead of a local server. ...
Most networking issues in Azure are actually DNS issues. Here is why DNS is hard in Azure, and how we handle it. Public and Private DNS Do Not Play Well Together Azure resources have public endpoints by default. They resolve via public DNS. When you add a private endpoint, the resource gets a private IP. Now you have two IPs for the same resource: public IP (internet-facing) private IP (VNET-only) DNS must resolve to the private IP from within your VNET, and the public IP from outside. ...
At first, Terraform was just a way to create resources. It lived next to the platform. It supported it. It automated it. Then, quietly, Terraform became the platform. The Shift Was Subtle There was no announcement. No rewrite. No big migration moment. It happened when: new environments required Terraform first access flowed through Terraform definitions changes without Terraform felt unsafe platform discussions started with code Terraform stopped being an implementation detail. It became the source of truth. ...
Terraform does something uncomfortable very well. It preserves mistakes. At first, that feels like a problem. Over time, it becomes one of its biggest strengths. Before Terraform, Mistakes Were Ephemeral Before infrastructure lived in code, mistakes were scattered. Someone changed a setting in the portal. Someone applied a hotfix directly. Someone clicked a checkbox to make something work. Those mistakes disappeared into history. They could not be explained. They could not be repeated. They could not be intentionally fixed. ...
The first Terraform refactor is never about improvement. It is about reckoning. You usually start with good intentions. Clean things up. Add structure. Maybe extract a module or two. Then you run plan. And suddenly you are staring at changes you do not remember making, resources you did not know were connected, and behaviors you cannot confidently explain. That is the real start of Terraform. The Moment Reality Shows Up Early Terraform setups tend to grow organically. ...
Retries feel comforting. Something failed. The system tried again. Eventually it worked. That story sounds reassuring, but it hides a lot of risk. Retries are not a safety net. They are a design decision. Why Retries Feel Harmless Most platforms make retries easy. Azure Functions retry automatically. Azure Storage Queues redeliver messages. HTTP clients retry transient failures. Early on, this feels like free resilience. You do not have to think deeply about failure. The platform will “handle it.” ...
Container Apps are great for compute. But the observability story is rough. Here is what works, what does not, and what we did instead. The Logs Exist, But Finding Them Is Hard Container Apps send logs to Log Analytics. That sounds good. Until you try to use it. The logs are scattered across multiple tables: ContainerAppConsoleLogs for stdout/stderr ContainerAppSystemLogs for platform events AppEnvSpringCloudGatewayLogs if you use specific add-ons We spent time writing Kusto queries just to see what our application logged. ...
We thought Container Apps networking would be simple. We were wrong. Here is what we learned after hours of troubleshooting. Internal vs External Environments Are Not What You Think Container Apps have two environment types: internal and external. We assumed: external means public internet internal means private network That is partially true, but incomplete. External environments get a public IP and can accept traffic from the internet. They can also be restricted to your VNET. ...
Functions seemed like the obvious choice. Until we hit the constraints that Container App Jobs do not have. Functions Work Until They Do Not We started with Azure Functions for our batch workloads. The model is simple: write code deploy it trigger it on a schedule or event It worked well for small jobs. Then we needed longer execution times. Functions have limits. We needed custom dependencies. The runtime felt restrictive. ...
Hard-earned hindsight. If we rebuilt our pipelines today, we would not start with tools. We would start with principles. What We Would Do Differently We would: standardize earlier automate more validation avoid manual gates by default version pipelines intentionally design for change, not perfection Most importantly, we would assume growth. Standardize earlier. We let teams build custom pipelines for too long. The cost of standardization increases with every unique pipeline. If we started over, we would establish standard templates from day one. Customization would be the exception, not the norm. ...