Compatible con S3, de verdad

«Compatible con S3» aparece impreso en todas las páginas de almacenamiento de objetos de internet. Y no te dice casi nada. La pregunta interesante no es si puedes hacer PutObject — es si algún día podrás sacar todos tus objetos y marcharte.

Esa es la parte que nadie pone en la página de marketing. Así que hablemos de ella.

La API de S3 es el estándar, y eso está bien

No existe un comité ISO para el almacenamiento de objetos. Lo que pasó, en cambio, es que Amazon lanzó una API HTTP en 2006, todo el mundo escribió clientes contra ella, y la API se convirtió en el estándar de facto por pura gravedad. aws s3, boto3, s3cmd, rclone, mc, los SDK de Go, Rust y JS — todos hablan el mismo dialecto. Apúntalos a otro endpoint y, en su mayoría, simplemente funcionan.

Ese es un resultado genuinamente bueno. Un protocolo de transporte estable al que apuntan una docena de implementaciones independientes es justo aquello sobre lo que se construye la portabilidad. Cuando alguien dice «compatible con S3», está prometiendo respetar ese contrato.

El problema es que el contrato es enorme, y «compatible» está cargando con mucho trabajo en silencio.

Qué significa la compatibilidad de verdad

Cualquiera puede implementar GET, PUT y DELETE sobre un bucket. Eso es lo mínimo indispensable, no compatibilidad. Las funciones que deciden si realmente puedes mudarte son las aburridas:

• Clientes y firmas. ¿Funciona la autenticación SigV4 con los SDK estándar, sin modificar, con solo cambiar la URL del endpoint? ¿O necesitas un fork especial del proveedor?
• URL firmadas. Las URL prefirmadas de GET/PUT son la forma en que media web sube archivos. Si no están implementadas igual, cada formulario de subida que escribiste se rompe en la migración.
• Versionado. Si tu aplicación depende de las versiones de los objetos y el nuevo sitio no las expone, no solo mueves datos — pierdes el historial.
• Reglas de ciclo de vida. Expiración, transiciones, abort-incomplete-multipart. Codifican lógica de negocio real. Si no se transfieren, vas a reescribir las políticas a mano.
• Subidas multiparte. Los objetos grandes dependen de ellas. Diferencias sutiles en los límites de tamaño de parte o en el comportamiento de los ETag aparecen como archivos corruptos a las 3 de la madrugada.

La compatibilidad es toda la superficie que tu código ya toca — no los tres verbos de la demo.

Cómo la portabilidad se convierte calladamente en un secuestro

Aquí está la jugada. Un proveedor habla S3 lo bastante bien como para que entres por la puerta. Luego le atornilla funciones propietarias de «valor añadido» — una capa de consultas a medida, un pipeline de eventos especial, una extensión del SDK, un chisme de ciclo de vida que solo existe en la consola — y te anima a construir sobre ellas. Cada una es genuinamente cómoda. Cada una es también un hilo que te cose a ese proveedor.

No te das cuenta hasta que intentas irte. Tus buckets siguen siendo «compatibles con S3», claro. Pero ahora tu aplicación depende de tres cosas que solo existen ahí.

Y luego está la trampa de verdad: las tarifas de egreso. Tus datos entraron baratos. Leerlos de vuelta hacia cualquier otro sitio cuesta dinero por gigabyte. Cuanto más creció tu conjunto de datos, más cara se vuelve la salida — que es exactamente al revés de cómo debería funcionar un trato justo. Una portabilidad que no te puedes permitir ejercer no es portabilidad. Es un secuestro con buenos modales.

Portabilidad que puedes probar, no solo creer

Construimos el almacenamiento de objetos de Kaligon Cloud para ser aburrido en lo que importa. Habla la API de S3. Apunta cualquier cliente de S3 al endpoint — aws-cli, rclone, boto3, lo que ya tengas — y funciona. El versionado, las reglas de ciclo de vida y las URL firmadas se comportan como dice el estándar que deberían, porque el estándar es el producto, no una casilla de marketing.

La parte que hace que la portabilidad sea real: sin tarifas de egreso entre recursos de Kaligon dentro de la misma región, y una única tarifa plana para el egreso saliente a internet. Mover datos entre tus propios buckets e instancias no cuesta nada. Irse no se vuelve más caro a medida que tus datos crecen. El precio es un único precio plano por recurso — sin tramos de uso comprometido que encarecen calladamente el cambio de opinión. Puedes verlo en la página de precios.

Así que no nos creas — pruébanos. Lanza rclone copy contra un bucket de Kaligon y contra el de un competidor, en ambas direcciones, y mira el contador. El sentido entero de un estándar es que no deberías tener que fiarte de la palabra de nadie.