# Why WebSocket Infrastructure Gets Cloud-Specific Fast

Serverless is often sold around flexibility.

You write a function, deploy it, and let the platform handle the infrastructure.

But once WebSockets enter the picture, things can become surprisingly provider-specific.

The application may still be written in familiar JavaScript, Python, Go, or another language.

The realtime infrastructure around it often is not.

## WebSockets need more than compute

A normal serverless HTTP endpoint can usually stay fairly portable.

Conceptually, the application receives:

`HTTP Request → Function → HTTP Response`

Move that function from one provider to another and the surrounding code may need changes, but the basic programming model is still familiar.

WebSockets introduce another layer.

Something has to:

*   keep connections alive
    
*   assign connection identities
    
*   route incoming messages
    
*   track connection lifecycle events
    
*   send outbound messages back to active clients
    
*   handle authentication and permissions
    

Cloud providers solve those problems differently.

That is where portability starts to disappear.

## The gateway becomes part of the application architecture

Imagine a backend running on a serverless platform.

To add WebSockets, the developer may introduce a managed gateway.

Now the application no longer talks directly to a socket.

Instead, it talks through provider-specific concepts such as:

*   connection IDs
    
*   route keys
    
*   gateway management APIs
    
*   IAM permissions
    
*   provider-specific event payloads
    
*   deployment configuration
    
*   infrastructure templates
    

Those concepts can slowly spread into application code.

The realtime layer stops being just infrastructure.

It becomes part of how the application itself is designed.

## Sending a message back can become provider-specific

A traditional WebSocket server owns the connection directly.

The application can conceptually do:

`socket.send(message)`

With a managed serverless gateway, the backend may instead need to call a provider-specific API.

The application now needs to know:

*   which connection ID to target
    
*   which gateway endpoint to call
    
*   which SDK or HTTP API to use
    
*   which credentials are required
    
*   how that provider represents disconnected clients
    

That is manageable when the application stays on one platform.

But it makes migration harder.

## Moving clouds can mean redesigning realtime

Suppose an application begins on one cloud provider.

Later, the team wants to move some workloads elsewhere.

The HTTP business logic may be relatively portable.

The WebSocket layer can be much harder.

A realtime architecture designed around one provider’s gateway, permissions, connection store, routing system, and callback API may not have a direct equivalent somewhere else.

So migration can become more than:

> “Deploy the functions somewhere new.”

It can become:

> “Redesign how realtime communication works.”

That is a much larger decision.

## Third-party platforms can introduce a different kind of lock-in

Cloud providers are not the only source of platform-specific architecture.

Realtime services can simplify WebSockets significantly, but they may introduce their own SDKs, channel models, presence systems, event formats, and client libraries.

Those abstractions are often useful.

But the more application code depends on them, the more expensive it becomes to leave later.

A developer may start with:

> “We just need realtime.”

and eventually have application logic tightly coupled to one realtime provider.

## What would a more neutral layer look like?

One alternative is to keep the interface between the realtime layer and the application extremely ordinary.

For example:

`Client → WebSocket Gateway → HTTP Webhook → Backend`

The client speaks standard WebSocket.

The backend speaks standard HTTP.

The gateway handles the translation.

That reduces the amount of provider-specific logic that has to leak into the application.

The backend does not need to know whether the persistent connection layer is running on AWS, Azure, another cloud, or dedicated infrastructure.

It only needs an HTTP endpoint.

## HTTP is a useful boundary

HTTP is not exciting.

That is part of why it works so well as an interface.

Almost every backend platform understands it.

Almost every serverless provider supports it.

Local development tools understand it.

Testing tools understand it.

If the WebSocket layer can communicate with the application through ordinary HTTP, then the boundary between the two becomes much easier to move.

The application depends on a protocol instead of a cloud-specific architecture.

## This is part of what we are exploring with Cortlet

With **Cortlet**, we are exploring a WebSocket gateway whose job is deliberately narrow.

The client uses a normal WebSocket connection.

Cortlet owns the persistent connection.

The application receives normal HTTP webhooks.

The goal is to avoid forcing the application itself to understand the infrastructure that keeps those connections alive.

That could make it easier to keep the realtime layer separate from the rest of the backend.

## Portability is really about boundaries

No infrastructure is completely vendor-independent.

Something always has to run somewhere.

But applications become easier to move when the boundaries between systems use familiar, open interfaces.

For serverless WebSockets, the important question may not be:

**Which cloud has the best WebSocket product?**

It may be:

**How much cloud-specific WebSocket infrastructure should application code need to know about at all?**