Llegó a HackerNews esta semana y me llamó la atención porque toca un tema que cada vez veo más en la pega: cómo exponer object storage como filesystem POSIX sin morir en el intento. AWS lanzó hace poco S3 Files, que usa EFS por debajo para sincronizar con un bucket. Y al mismo tiempo hay un proyecto open source llamado ZeroFS que toma el camino contrario: trata al bucket como un detalle interno de implementación. Mismo problema, dos apuestas filosóficas distintas.
El punto de S3 Files: tus archivos siguen siendo objetos S3
Si subes imagenes/gato.jpg al mount, eventualmente ese mismo archivo aparece como un objeto normal en tu bucket. El mount usa NFS 4.1/4.2 y por debajo mantiene una capa de high-performance storage administrada por AWS. Los cambios se exportan al bucket después de unos 60 segundos sin escritura. Si necesitas visibilidad inmediata por la API de S3, S3 Files no te la da.
Eso tiene una ventaja concreta: si tienes un pipeline que ya consume objetos del bucket, no rompes nada. Sigues corriendo tu job de Athena, tu Lambda que lee directo, o tu CDN sirviendo los mismos archivos. El filesystem vive al lado del bucket, no en lugar del bucket.
ZeroFS toma el camino contrario
ZeroFS hace lo que yo llamaría la apuesta agresiva: el bucket deja de ser legible con la API estándar. Los datos van en segmentos inmutables, comprimidos y cifrados del lado del cliente, con la metadata en un LSM tree. Un objeto de S3 que contiene un segmento de ZeroFS es ciphertext opaco: no lo puedes bajar y hacer un aws s3 cp y pretender que el archivo salió. Necesitas ZeroFS y la contraseña de cifrado para montar el volumen.
A cambio te llevas tres cosas que importan cuando la pega se pone seria: archivos pequeños no gastan un PUT por cabeza, todo el contenido va cifrado antes de tocar object storage, y puedes usar cualquier backend S3-compatible, incluyendo Azure Blob o GCS. Si te gusta tener control del formato y no te importa cerrar el ecosistema, el trade-off te conviene.
El tema plata, donde se decide todo
El autor de ZeroFS hizo el ejercicio que todos deberíamos hacer antes de creerle a AWS: tomó 10.000 GiB, leyó una vez, y comparó. ZeroFS con compresión 2:1 te deja en alrededor de 115 dólares al mes solo por storage, más el costo de infraestructura del servidor. S3 Files con lecturas pequeñas residentes se dispara a 3.530 dólares en el mismo escenario, porque la capa de high-performance storage cobra 0,30 dólares por GB-mes más 0,06 por GB escrito y 0,03 por GB leído.
¿Eso significa que S3 Files es un robo? Para nada. Si tu caso de uso es streaming de archivos grandes desde un bucket existente, leer directo de S3 sin pasar por la capa de high-performance te deja en números parecidos a ZeroFS. El problema aparece cuando importas archivos a la capa rápida o los escribes a través del mount: ahí los cargos empiezan a sumar, y rápido. Mi lectura es que S3 Files está pensado para el caso feliz: archivos grandes, lecturas secuenciales, uso ocasional del filesystem. Si lo usas como si fuera EFS, te va a doler la factura.
Lo que yo haría en un proyecto real
Si me toca armar esto mañana, mi decisión pasa por una pregunta simple: ¿necesito que otros servicios lean los mismos objetos por la API de S3? Si la respuesta es sí, S3 Files me ahorra mantener una tubería de sincronización aparte, y acepto el costo extra como precio por la conveniencia. Si la respuesta es no, y el bucket es un backend privado para mi aplicación, ZeroFS me da mejor costo por gigabyte, cifrado de cliente, y la libertad de cambiar de proveedor sin reescribir nada.
Lo que no haría es montar ZeroFS sobre un bucket donde ya tengo un data lake. El día que alguien intente leer un archivo con Athena o con un script de Spark, va a descubrir que el objeto es ciphertext y se va a ganar un dolor de cabeza. La herramienta define la arquitectura, y esta define muy fuerte cómo se accede a los datos.
Es de esos casos donde la decisión técnica es también una decisión de dependencia del proveedor, aunque ninguna de las dos partes lo diga explícitamente. AWS te cobra más pero te deja salir por S3. ZeroFS te cobra menos pero te deja casado con el formato. Tú eliges cuál prefieres, pero hazlo sabiendo, no por default.
Fuente de inspiración: ZeroFS vs. Amazon S3 Files — ZeroFS
