BRIEF DELIGHTS

Hugging Face and Google partner for open AI collaboration

Analyzes key technical developments and market implications surrounding Hugging Face and Google partner for open AI collaboration. Provides essential context for enterprise engineering teams.

Amazon DynamoDB now supports real-time vector search at any scale

DynamoDB now supports native vector search with single-digit millisecond latency at 99%+ recall. It is designed for any scale, even trillions of vectors and requires zero infrastructure management.

Vercel Services: Run full stack on Vercel

To a user, an app with a Next.js frontend and a FastAPI backend feels like one product, and the same should be true for the engineers who build it. Instead, the two pieces are often deployed across different clouds with different development and deployment workflows.Today we're introducing Vercel Services in public beta, which lets you run multiple frameworks in one Vercel Project. This unlocks:Atomic deployments: Your frontend, backend, and other services stay in sync and deploy or roll back togetherShared preview deployments: See how any change affects all your servicesInternal service communication: Services can talk to each other without routing through the public InternetVercel handles the rest: routing, builds, deployments, and auto-scaling in production. The developer experience you already know from Vercel now covers your entire application.Compose applications with Vercel ServicesDeclare your services under the services key in vercel.json keeping the routing configuration explicit:Services can be mounted to a shared routing table without the need for a reverse proxy or CORS.The services configuration is recognized at multiple levels of the Vercel platform:The Deployments panel shows a visualization of services graphThe Logs UI allows filtering by individual serviceThe vercel dev CLI automatically runs all services giving you a production-like environment locallyService bindingsServices can talk to other services internally, without routing through the public Internet. Here's an example how the new bindings configuration key enables that:Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:Service-to-service traffic stays on the Vercel network rather than egressing to the public internet. Many independent services can become one application connected by the same wiring, rather than separate deployments that you stitch together across hosts.Framework-defined infrastructureMost frameworks run on Vercel with zero configuration. Framework-defined infrastructure means that each service's framework is auto-detected and auto-provisioned, from FastAPI and Flask for Python to Express and Hono for TypeScript, with first-class support for Go and Rust servers.Services run on Fluid compute, autoscaling with traffic, while you pay only for active CPU time. But framework-defined optimizations go even deeper. With Django, for example, we automatically detect where static assets live and serve them from the CDN.The full stack platformVercel Services gives Vercel a structured way to build and run your application.Those services run on a platform that includes everything any backend could need, whether you're building APIs, agents, or background workers: compute, data, networking, background work, and secure connections to external services.Isolated compute for agent servicesAgents can read files, run commands, and write code. But that capability needs to be secure. Vercel Sandbox gives each agent its own Linux computer: a filesystem, a shell, Docker support, and its own kernel, completely isolated from your deployments. Agents can execute code, grep files, and spin up Redis or Postgres as dependencies. Nothing inside the sandbox can touch your production environment.With automatic persistence, state carries between sessions, and on Pro, sandboxes can run for up to 24 hours.Real-time backends with WebSocket supportVercel Functions handle persistent WebSocket connections in every Vercel runtime, whether your backend is written in Node.js, Python, or Go. They work with standard WebSocket libraries like Socket.IO, and because connections run on Fluid compute with Active CPU pricing, you only pay for the time spent processing messages, not the time a connection sits idle.Reach external services with Vercel ConnectAgents and backends need to reach services outside your project (Slack, GitHub, managed databases), which usually means storing a long-lived secret in your environment. Vercel Connect replaces that with a short-lived credential your app requests at runtime, scoped to the task in front of it. There is no long-lived secret left to leak.Databases and storage for your servicesYou can provision a database from the Vercel Marketplace in a few clicks, with credentials injected for you, from providers like Neon, Supabase, and from AWS with Aurora PostgreSQL, Aurora DSQL, and DynamoDB. Amazon OpenSearch Serverless adds full-text and vector search, and Vercel Blob handles object storage. You can query and manage any of it without leaving Vercel, and both Blob and the AWS integrations authenticate with short-lived OIDC tokens rather than stored secrets.Run durable workflows and background jobsVercel Queues processes background jobs off the request path. Vercel Workflow handles durable multi-step processes that survive crashes and redeploys. And Vercel Cron runs work on a schedule. This is the part of a backend that outlives a request, and it runs on the same platform as everything else, so the long-running side of your backend needs no separate infrastructure.Connect privately and run on the right computeWhen a backend needs to reach a private database or an internal network instead of a public service, Secure Compute, static IPs, and VPC peering open that path.Functions run for up to 30 minutes on Pro and Enterprise, and Python backends deploy with up to 500mb of dependencies.Underneath all of it, Fluid compute is the default for new projects, and Active CPU pricing bills for the time your code is actually running rather than the time it waits, the right shape for idle-heavy backend and AI work.A single platform for everything you shipVercel Services brings your frontend, backend, and supporting services into one project. They build together, preview together, deploy together, and communicate internally by default.Combined with Vercel's built-in primitives for compute, data, queues, workflows, cron, secure networking, and sandboxed agent environments, you can run the full stack without stitching together separate platforms.To start composing services, read the Vercel Services documentation and the routing and communication guide. If you are new to running a backend on Vercel, the zero-config backends post is the place to begin. Read more

Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 processors are now generally available

Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 are now generally available, delivering up to 25% better compute performance than R8g, ideal for databases, in-memory caches, and real-time analytics.

What are MCP Servers?

With Fly.io, you can get your app running globally in a matter of minutes, and with MCP servers you can integrate with Claude, VSCode, Cursor and many more AI clients. Try it out for yourself! The introduction to Model Context Protocol starts out with:

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

That paragraph, to me, is both comforting (“USB for LLM”? Cool! Got it!), and simultaneously vacuous (Um, but what do I actually do with this?).

I’ve been digging deeper and have come up with a few more analogies and observations that make sense to me. Perhaps one or more of these will help you. MCPs are Alexa Skills You buy an Echo Dot and a Hue light. You plug them both in and connect them to your Wi-Fi. There is one more step you need to do: you need to install and enable the Philips Hue skill to connect the two.

Now you might be using Siri or Google Assistant. Or you may want to connect a Ring Doorbell camera or Google Nest Thermostat. But the principle is the same, though the analogy is slightly stronger with a skill (which is a noun) as opposed to the action of pairing your Hue Bridge with Apple HomeKit (a verb). MCPs are API 2.0 HTTP 1.1 is simple. You send a request, you get a response. While there are cookies and sessions, it is pretty much stateless and therefore inefficient, as each request needs to establish a new connection. WebSockets and Server-Sent Events (SSE) mitigate this a bit.

HTTP 2.0 introduces features like multiplexing and server push. When you visit a web page for the first time, your browser can now request all of the associated JavaScript, CSS, and images at once, and the server can respond in any order.

APIs today are typically request/response. MCPs support multiplexing and server push. MCPs are APIs with Introspection/Reflection With OpenAPI, requests are typically JSON, and responses are too. Many OpenAPI providers publish a separate OpenAPI Description (OAD), which contains a schema describing what requests are supported by that API.

With MCP, requests are also JSON and responses are also JSON, but in addition, there are standard requests built into the protocol to obtain useful information, including what tools are provided, what arguments each tool expects, and a prose description of how each tool is expected to be used.

As an aside, don’t automatically assume that you will get good results from auto-generating MCP Servers from OpenAPI schemas:

Effective MCP design means thinking about the workflows you want the agent to perform and potentially creating higher-level tools that encapsulate multiple API calls, rather than just exposing the raw building blocks of your entire API spec.

MCP vs API goes into this topic at greater depth.

In many cases you will get better results treating LLMs as humans. If you have a CLI, consider using that as the starting point instead. MCPs are not serverless Serverless, sometimes known as FaaS, is a popular cloud computing model, where AWS Lambda is widely recognized as the archetype.

MCP servers are not serverless; they have a well-defined and long-lived lifecycle:

MCPs are not Inherently Secure or Private Here I am not talking about prompt injection or exploitable abilities, though those are real problems too.

I’m talking about something more fundamental and basic. Let’s take a look at the very same GitHub MCP featured in the above two descriptions of an exploitable exposure. The current process for installing a stdio MCP into Claude involves placing secrets in plain text in a well-defined location. And the process for installing the next MCP server is to download a program from a third party and run that tool in a way that has access to this very file.

Addressing MCP security requires a holistic approach, but one key strategy component is the ability to run an MCP server on a remote machine which can only be accessed by you, and only after you present a revocable bearer token. That remote machine may require access to secrets (like your GitHub token), but those secrets are not something either your LLM client or other MCP servers will be able to access directly. MCPs should be considered family Recapping: Philips has an API and SDK for Hue that is used by perhaps thousands, and has an Alexa Skill that is used by untold millions. Of course, somebody already built a Philips Hue MCP Server.

LLMs are brains. MCPs give LLMs eyes, hands, and legs. The end result is a robot. Most MCPs today are brainless—they merely are eyes, hands, and legs. The results are appliances. I buy and install a dishwasher. You do too. Both of our dishwashers perform the same basic function. As do any Hue lights we may buy.

In The Jetsons, Rosie is a maid and housekeeper who is also a member of the family. She is good friends with Jane and takes the role of a surrogate aunt towards Elroy and Judy. Let’s start there and go further.

A person with an LLM can build things. Imagine having a 3D printer that makes robots or agents that act on your behalf. You may want an agent to watch for trends in your business, keep track of what events are happening in your area, screen your text messages, or act as a DJ when you get together with friends.

You may share the MCP servers you create with others to use as starting points, but they undoubtedly will adapt them and make them their own. Closing Thoughts Don’t get me wrong. I am not saying there won’t be MCPs that are mere appliances—there undoubtedly will be plenty of those. But not all MCPs will be appliances; many will be agents.

Today, most people exploring LLMs are trying to add LLMs to things they already have—for example, IDEs. MCPs flip this. Instead of adding LLMs to something you already have, you add something you already have to an LLM.

Desktop Commander MCP is an example I’m particularly fond of that does exactly this. It also happens to be a prime example of a tool you want to give root access to, then lock it in a secure box and run someplace other than your laptop. Give it a try.

Microsoft is actively working on Agentic Windows. Your smartphone is the obvious next frontier. Today, you have an app store and a web browser. MCP servers have the potential to make both obsolete—and this could happen sooner than you think.

A deep dive into Vercel’s build infrastructure

Vercel has a new low-level untrusted and ephemeral compute platform—designed to give us the control needed to securely and efficiently manage and run builds. Since November 2023, this compute platform, internally codenamed "Hive", has powered Vercel’s builds, enabling key improvements like enhanced build machines and a 30% improvement in build performance.The platform operates on the fundamental assumption that we’re executing potentially malicious code on multi-tenant machines, requiring it to be safe, reliable, performant, and cost-effective. It’s architected to handle multiple use cases and can be composed in different ways depending on what’s needed. Most recently, Hive allowed us to reduce provisioning times for Secure Compute customers from 90 seconds to 5 seconds, while also improving their build speeds.We built Hive because we needed finer control and more granular management to continuously improve Vercel’s infrastructure, to meet the growing demands of our customers and to fulfill our vision of delivering the best development experience in the world. Read more

Vercel Services: Run full stack on Vercel

To a user, an app with a Next.js frontend and a FastAPI backend feels like one product, and the same should be true for the engineers who build it. Instead, the two pieces are often deployed across different clouds with different development and deployment workflows.Today we're introducing Vercel Services in public beta, which lets you run multiple frameworks in one Vercel Project. This unlocks:Atomic deployments: Your frontend, backend, and other services stay in sync and deploy or roll back togetherShared preview deployments: See how any change affects all your servicesInternal service communication: Services can talk to each other without routing through the public InternetVercel handles the rest: routing, builds, deployments, and auto-scaling in production. The developer experience you already know from Vercel now covers your entire application.Compose applications with Vercel ServicesDeclare your services under the services key in vercel.json keeping the routing configuration explicit:Services can be mounted to a shared routing table without the need for a reverse proxy or CORS.The services configuration is recognized at multiple levels of the Vercel platform:The Deployments panel shows a visualization of services graphThe Logs UI allows filtering by individual serviceThe vercel dev CLI automatically runs all services giving you a production-like environment locallyService bindingsServices can talk to other services internally, without routing through the public Internet. Here's an example how the new bindings configuration key enables that:Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:Service-to-service traffic stays on the Vercel network rather than egressing to the public internet. Many independent services can become one application connected by the same wiring, rather than separate deployments that you stitch together across hosts.Framework-defined infrastructureMost frameworks run on Vercel with zero configuration. Framework-defined infrastructure means that each service's framework is auto-detected and auto-provisioned, from FastAPI and Flask for Python to Express and Hono for TypeScript, with first-class support for Go and Rust servers.Services run on Fluid compute, autoscaling with traffic, while you pay only for active CPU time. But framework-defined optimizations go even deeper. With Django, for example, we automatically detect where static assets live and serve them from the CDN.The full stack platformVercel Services gives Vercel a structured way to build and run your application.Those services run on a platform that includes everything any backend could need, whether you're building APIs, agents, or background workers: compute, data, networking, background work, and secure connections to external services.Isolated compute for agent servicesAgents can read files, run commands, and write code. But that capability needs to be secure. Vercel Sandbox gives each agent its own Linux computer: a filesystem, a shell, Docker support, and its own kernel, completely isolated from your deployments. Agents can execute code, grep files, and spin up Redis or Postgres as dependencies. Nothing inside the sandbox can touch your production environment.With automatic persistence, state carries between sessions, and on Pro, sandboxes can run for up to 24 hours.Real-time backends with WebSocket supportVercel Functions handle persistent WebSocket connections in every Vercel runtime, whether your backend is written in Node.js, Python, or Go. They work with standard WebSocket libraries like Socket.IO, and because connections run on Fluid compute with Active CPU pricing, you only pay for the time spent processing messages, not the time a connection sits idle.Reach external services with Vercel ConnectAgents and backends need to reach services outside your project (Slack, GitHub, managed databases), which usually means storing a long-lived secret in your environment. Vercel Connect replaces that with a short-lived credential your app requests at runtime, scoped to the task in front of it. There is no long-lived secret left to leak.Databases and storage for your servicesYou can provision a database from the Vercel Marketplace in a few clicks, with credentials injected for you, from providers like Neon, Supabase, and from AWS with Aurora PostgreSQL, Aurora DSQL, and DynamoDB. Amazon OpenSearch Serverless adds full-text and vector search, and Vercel Blob handles object storage. You can query and manage any of it without leaving Vercel, and both Blob and the AWS integrations authenticate with short-lived OIDC tokens rather than stored secrets.Run durable workflows and background jobsVercel Queues processes background jobs off the request path. Vercel Workflow handles durable multi-step processes that survive crashes and redeploys. And Vercel Cron runs work on a schedule. This is the part of a backend that outlives a request, and it runs on the same platform as everything else, so the long-running side of your backend needs no separate infrastructure.Connect privately and run on the right computeWhen a backend needs to reach a private database or an internal network instead of a public service, Secure Compute, static IPs, and VPC peering open that path.Functions run for up to 30 minutes on Pro and Enterprise, and Python backends deploy with up to 500mb of dependencies.Underneath all of it, Fluid compute is the default for new projects, and Active CPU pricing bills for the time your code is actually running rather than the time it waits, the right shape for idle-heavy backend and AI work.A single platform for everything you shipVercel Services brings your frontend, backend, and supporting services into one project. They build together, preview together, deploy together, and communicate internally by default.Combined with Vercel's built-in primitives for compute, data, queues, workflows, cron, secure networking, and sandboxed agent environments, you can run the full stack without stitching together separate platforms.To start composing services, read the Vercel Services documentation and the routing and communication guide. If you are new to running a backend on Vercel, the zero-config backends post is the place to begin. Read more