Annonce de l’introduction de S2

• S2 est une preview d’un Stream Store serverless qui vise à gérer des flux temps réel durables aussi simplement que du stockage objet, en faisant des logs et des streams des primitives du stockage cloud
• Les enregistrements sont ajoutés au tail du stream, et même lorsque plusieurs writers écrivent simultanément, S2 se charge de l’ordonnancement durable, avec prise en charge à la fois de la lecture historique et du tailing en temps réel
• Le basin de S2 joue, comme un bucket, le rôle d’espace de noms pour les streams, permettant des modèles comme un stream par utilisateur, sans limite sur le nombre de streams ni sur la durée de rétention
• Les classes de stockage démarrent avec Standard et Express, visant respectivement des latences p99 inférieures à 500 ms et inférieures à 50 ms, afin de proposer des arbitrages entre latence et coût
• S2 propose actuellement une API gRPC, un SDK Rust et une CLI, avec comme prochaines étapes une API REST, la compatibilité avec le protocole Kafka, des basins multi-régions et une latence inférieure à 5 ms

---

Le modèle de stockage de streams proposé par S2

• S2 se veut un Stream Store serverless pour les données de streaming à l’ère du cloud
• L’idée centrale est que les logs, ou streams, peuvent eux aussi devenir des primitives du stockage cloud, au même titre que les objets
• Le stockage objet se concentre sur PUT / GET / DELETE pour des objets nommés, ainsi que sur les blobs et les byte ranges, et convient aux données au repos
• Le stockage de streams de S2 fournit APPEND / READ / TRIM pour des Stream nommés, avec les enregistrements et les numéros de séquence comme unités de base
• Les écritures sont ajoutées au tail du stream, et même si plusieurs writers écrivent simultanément, S2 ordonne tous les enregistrements et garantit leur durabilité
• Les lectures peuvent commencer de quelques secondes en arrière jusqu’à plusieurs années, et permettent aussi le tailing en temps réel, difficile à faire avec des blobs S3
• Un basin joue le rôle d’espace de noms pour les streams, comme un bucket le fait pour les objets
  • Les basins et les streams peuvent être utilisés sans limite de nombre
  • Il n’y a pas non plus de limite de durée de rétention des données
  • Il est possible de modéliser un stream par utilisateur, sans devoir gérer des limites de cluster ou du tuning d’infrastructure comme avec Kafka
• Les opérations permettant de consulter le tail d’un stream avec une cohérence forte, ainsi que le contrôle de concurrence à l’écriture, sont également pris en charge
  • Une approche pessimiste utilisant un fencing token est possible
  • Une approche optimiste fournissant un numéro de séquence attendu est possible
  • Cette conception vise l’externalisation de la durabilité ainsi que la séparation compute/stockage, utilisées par des bases de données comme MemoryDB et Neon

Performances, prix, fonctionnalités actuelles et feuille de route

• S2 fournit une API serverless sous forme de service multitenant, en s’appuyant sur la scalabilité et la durabilité du stockage objet
• La durabilité est considérée comme non négociable, tandis que le choix entre latence et coût se règle par storage class au niveau de chaque stream
  • Standard : basé sur AWS S3 Standard ; tous les fournisseurs de cloud public disposent d’un produit équivalent, ce qui laisse penser qu’il pourra être proposé dans toutes les régions cloud à mesure de la croissance
  • Express : basé sur un quorum de trois buckets AWS S3 Express One Zone ; Azure dispose d’un équivalent régional, et GCP pourrait également le permettre
• Les objectifs de performance et les limites initiales sont les suivants
  • Standard fournit une latence p99 de bout en bout inférieure à 500 ms
  • Express peut offrir une latence inférieure à 50 ms
  • Toutes les écritures sont stockées en sécurité dans S3 avec une durabilité régionale avant acknowledgement
  • Le débit pris en charge est de l’ordre de plusieurs centaines de Mo par seconde par stream
  • La lecture des données récemment écrites a un faible overhead grâce à la mise en cache en mémoire
  • Les readers en retard sont servis directement depuis l’object storage, sans plafond
  • Au départ, les écritures sont limitées à 125 MiBps par stream, et les lectures des écritures récentes à 500 MiBps par stream
• Pendant la période de preview, le service est gratuit, et les prix envisagés sont publiés avec l’objectif d’être significativement moins chers que les niveaux habituels des systèmes de streaming cloud
• Il n’y a pas de coûts fixes comme des instances ou des unités de cluster
• Les interfaces développeur actuellement disponibles sont les suivantes
  • API gRPC
  • SDK Rust
  • CLI
  • API REST, prévue ultérieurement
• Le système repose sur une infrastructure cloud éprouvée, et la base de code Rust passe par des tests par simulation déterministe
  • Le système est encore jeune et des problèmes peuvent subsister
  • Il est en cours de maturation vers la disponibilité générale et des SLA fiables en production
• La prochaine feuille de route se structure autour de trois axes
  • Compatibilité avec le protocole Kafka : fournie sous forme de couche open source, avec certaines fonctionnalités comme la compaction basée sur les clés prévues pour être intégrées directement à S2
  • Basins multi-régions : après une extension à davantage de régions cloud, l’équipe envisage des basins couvrant régions et clouds
  • Latences inférieures à 5 millisecondes : la flexibilité structurelle des storage classes permettrait une nouvelle amélioration de 10× par rapport à Express
• Pour les cas utilisant principalement les API « low-level » de Kafka ou Kinesis, S2 cible directement des besoins comme l’absence de limite sur le nombre de streams, un ordered throughput 10 à 100 fois plus élevé et le contrôle de concurrence

[GN⁺]

Avis de Hacker News

• Je ne suis pas juriste, mais appeler le produit S2 et dire dans la présentation qu’il s’agit d’une technologie qui améliore AWS S3 semble très susceptible de déclencher des réclamations de marque/copyright de la part d’Amazon.
  Comme c’est le même domaine, il peut clairement y avoir confusion chez les consommateurs. Ils ont évidemment dû vérifier l’existence de marques déposées, mais : https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

  • Fait amusant : en espagnol, S2 et EC2 se prononcent tous les deux « ese dos »
    EC2 et S3 sont déjà faciles à confondre à l’oreille, et cela en ajoute encore un.
  • Pour être juste, si l’objectif est d’améliorer S3, il faudrait sans doute l’appeler S4.
  • Au moins, R2 de Cloudflare a une justification pour son nom.
    IBM contre HAL, autrement dit une logique de nommage façon « 2001: A Space Odyssey ».
  • Je ne sais pas s’ils ont consulté un mauvais avocat en marques, ou s’ils n’en ont pas consulté du tout, mais cela n’aurait probablement pas coûté si cher.
    J’ai récemment entamé une procédure de dépôt de marque, et d’après le site d’un bureau d’enregistrement de domaines, le coût était similaire à celui d’un domaine comme s4.dev. Rebrander après le lancement est bien plus douloureux que changer avant le lancement.
  • Amazon pourrait simplement créer la même chose, l’appeler S3 Streams et ne pas se préoccuper de S2.
    Ils pourraient même faire une offre d’acquisition ; une action en justice me paraît très peu probable.

• L’idée est vraiment excellente et l’API est élégante, et j’aimerais l’utiliser dans mes projets, mais je n’ai absolument aucune certitude que cette startup survive longtemps sous sa forme actuelle.
  Si elle réussit, AWS construira une version interne meilleure et moins chère ; à l’inverse, il est aussi très possible qu’elle n’obtienne pas de traction sur le marché. Cela aurait beaucoup plus de sens comme produit final pour utilisateurs, avec un tableau de bord à la Papertrail, plutôt que comme API de « brique de base cloud » étroitement liée à AWS. Si l’on pouvait y apporter directement des backends compatibles S3 comme Digital Ocean Spaces, cela deviendrait un excellent produit cloud-neutral durable.

  • Du point de vue du fondateur, ils prévoient du multicloud, et commencent simplement par AWS pour l’instant.
    L’architecture interne n’est pas liée à AWS ; elle repose sur une interface qui peut être implémentée pour d’autres systèmes cloud.
  • Ce serait assez ironique si tout cela tournait déjà sur AWS.
    Il n’y a pas de fin aux startups qui emballent du logiciel open source existant sous forme de service, le marketent comme moins cher que les produits AWS, tout en tournant elles-mêmes sur AWS.
  • On a constamment opposé le même argument à Aptible(https://aptible.com), mais plus de 10 ans plus tard, cela reste un PaaS très réussi.
  • Quand on fait de l’infrastructure cloud, AWS essaiera de casser les prix, mais ne fera jamais mieux en matière d’expérience développeur/expérience utilisateur.
    Donc je ne pense pas qu’il faille s’arrêter à cause de Beezus.
  • AWS a déjà fait quelque chose de similaire : https://news.ycombinator.com/item?id=42211280
    « Amazon S3 now supports the ability to append data to an object » a été annoncé il y a 30 jours, et Azure propose depuis longtemps la même fonction avec append blob. C’est encore plus brut que S2 et il n’y a pas de notion de record, mais le pas pour qu’un fournisseur cloud l’offre nativement est très petit. En ajoutant la notion de record, on se rapproche en fait d’une file de messages, et cet espace concurrentiel est lui aussi vaste, tout comme celui des solutions de stockage de logs.

• J’aimerais comprendre. Si c’est construit sur AWS, AWS facture la sortie Internet 0,09 $ par Go, mais ici ils facturent la sortie Internet 0,05 $ par Go ?
  On dirait qu’ils subventionnent les coûts de sortie AWS. Ou alors ils ont accès à des tarifs de sortie non publics ?

  • Du point de vue du fondateur, ils ne facturent pas pendant la preview.
    Ils régleront cela lorsqu’ils atteindront une échelle significative, et il y a clairement plusieurs hypothèses derrière.
  • Même au tarif public, après 150 To, c’est 0,05 $ par Go, et c’est encore moins cher pour de gros volumes.
  • Ils semblent parier que la plupart des utilisateurs seront dans AWS et ne paieront que 1 à 2 cents de frais de transfert.
  • Les acteurs qui ont suffisamment d’échelle ne paient pas les transferts de données au prix de détail.
  • On dirait qu’ils sont maintenant passés à 0,08 $ par Go.
    Dans ce cas, à 50 To, la perte maximale est de 300 $ par mois, et au-delà ils commencent à gagner de l’argent.

• C’est essentiellement WarpStream, mais au lieu d’aller directement vers la compatibilité Kafka, ils fournissent une API de plus bas niveau ?
  À long terme, si cela est adopté, une API de base au niveau de S3 pour le streaming semble vraiment précieuse.

  • Du point de vue du fondateur, c’est un résumé assez juste.
    Cela dit, leur approche architecturale est différente de celle de WarpStream, ce qui leur permet d’offrir une latence bien plus faible. Le système n’a pas non plus de disque.

• Ces personnes ont donc consciemment choisi de passer toute leur carrière à expliquer : « en fait, nous ne sommes pas S3 ».

  • Du point de vue du fondateur, on peut dire que 50 % du nom est différent.
  • Combien de ces services de stockage lettre+chiffre existe-t-il désormais ? S3, B2, R2, S2...
  • Ou encore celui-ci : https://github.com/google/s2geometry
  • Cela dit, cela paraît quand même préférable à devoir expliquer qu’on n’est pas une organisation paramilitaire ayant commis des crimes de guerre innommables.
    Ce n’est pas un sujet de plaisanterie.
  • Ne risquent-ils pas aussi de devoir l’expliquer au tribunal ou devant des avocats ? Je ne suis pas juriste, mais cela ressemble à une invitation faite à Amazon d’affirmer qu’ils ont intentionnellement exploité la marque « S3 » et créé de la confusion pour développer leur propre marque.
    Personnellement, je pense que cet argument se tient, et que c’est assez clairement visible dans le texte.

• Ça a l’air bien, mais il n’y a pas de Java SDK ?
  Dans les entreprises où j’ai travaillé, dans 90 % des cas, la production/consommation Kafka dépendait fortement de Spring ou du client de base. Dans ces conditions, même une preuve de concept légère devient pratiquement impossible

  • Du point de vue de l’équipe S2, un SDK Java/Kotlin et un SDK Python sont prévus
    Pour l’instant, il y a un SDK Rust et une CLI (https://s2.dev/docs/quickstart). Le service cœur est lui aussi écrit en Rust, donc Rust semblait être un bon point de départ

• Ça me plaît. Ce que j’aimerais que quelqu’un construise ensuite par-dessus, c’est la partie qui applique les « événements » de flux sous forme de représentation interrogeable à un instant donné
  C’est en gros l’autre moitié nécessaire pour faire quelque chose de similaire à Datomic. Plutôt qu’une base de données précise, un pattern ou un framework pour produire des données en mémoire interrogeables de manière concrète serait probablement mieux. On peut imaginer plusieurs approches : l’appliquer à un SQLite local, l’appliquer à une instance locale interrogeable à partir du binlog MySQL et permettre un retour à un instant donné, ou encore appliquer des événements apply/undo propres à l’application sur un état local

• J’ai lancé Gazette il y a environ 10 ans [0]
  Gazette se situe architecturalement à mi-chemin entre Kafka et WarpStream/S2. Il fournit des flux de logs infinis orientés octets, avec S3 comme backend, mais les brokers utilisent un disque local de travail pour la réplication initiale, les garanties de durabilité et la réduction de la latence des append/read. Résultat : le p99 est inférieur à 5 ms plutôt que supérieur à 500 ms, et il garantit que tous les fichiers atteignent S3, avec des fonctionnalités pratiques comme une taille cible, une compression et des limites de latence configurables. Les clients qui lisent des données anciennes récupèrent le contenu directement depuis S3, puis basculent ensuite vers le live tailing des append très récents
  Gazette a démarré comme outil interne dans une startup précédente et, au moment de créer l’entreprise actuelle, nous avons très brièvement envisagé de le proposer comme service brut [1], avant de nous réorienter vers une plateforme complète de déplacement de données [2] qui utilise Gazette comme détail d’implémentation interne. Le positionnement marché de ce type de service est extrêmement étroit. Il faut soit le rendre compatible au niveau API avec ce que les clients cibles utilisent déjà afin de ramener le coût d’essai à zéro — ce que WarpStream a bien réussi —, soit remonter plus haut dans la stack applicative et résoudre plus directement le problème que les clients cherchent réellement à résoudre
  [0]: https://gazette.readthedocs.io/en/latest/
  [1]: https://news.ycombinator.com/item?id=21464300
  [2]: https://estuary.dev

  • Du point de vue du fondateur de S2, félicitations pour le succès d’Estuary
    Vous n’êtes pas le premier à dire que ce marché n’existe pas, ou qu’il est très petit. Mais quand vous cherchiez une validation sur HN, vous pensiez probablement vous aussi qu’il y avait quelque chose. On pourrait fournir beaucoup plus de choses au-dessus de S2, comme de la compatibilité Kafka, mais le composant fondamental cœur est important. Personnellement, j’en avais aussi envie, et je l’ai vu recréé dans toutes sortes de contextes puis réutilisé inefficacement sous forme de systèmes ayant perdu leur nature initiale ; cette conviction suffisait à elle seule pour devenir fondateur. Je comprends le contexte de votre conseil, je sais les difficultés à venir, et je vous remercie pour ce conseil

• C’est un modèle de service très utile, mais si toutes les écritures sont persistées dans S3 avant l’acquittement, la proposition de valeur devient confuse
  L’auteur peut bien batcher des groupes de records avant de les écrire dans un blob plus grand, et un processus en arrière-plan peut effectuer de la compaction, mais cela reste un service de streaming basé sur du stockage objet, non ? AWS a montré, avec le passage de RDS à Aurora, qu’il était généralement prêt à implémenter des services compatibles au niveau protocole, et il semble pouvoir faire la même chose avec une réimplémentation de Kafka

  • Du point de vue de l’équipe S2, c’est effectivement l’idée sur le fond
    Si l’on conçoit de manière multitenant les chunks écrits dans le stockage objet avant d’acquitter les écritures, et qu’on y place ensemble les records de différents streams, on peut écrire fréquemment tout en visant une taille de blob idéale en prix/performance pour les PUT S3 standard comme express

• La technologie a l’air vraiment impressionnante. Dommage toutefois que ce ne soit pas source-available
  C’est peut-être une opinion minoritaire, mais si la technologie cœur était publiée sous une licence comme FSL et qu’un self-hosting entièrement pris en charge était possible, j’envisagerais tout à fait le service commercial. Sinon, il est difficile de justifier l’enfermement par rapport à quelque chose comme Kafka

  • Du point de vue du fondateur, les implémentations alternatives de l’API S2 sont les bienvenues
    Nous envisageons aussi de publier en open source un émulateur en mémoire. L’API elle-même n’est pas très complexe. Si vous voulez conserver l’API Kafka tout en bénéficiant de fonctionnalités de S2 comme les classes de stockage, un très grand nombre de topics/partitions et un débit élevé par partition, nous prévoyons une couche compatible Kafka open source et self-hostable. Nous ajouterons aussi des fonctionnalités comme le chiffrement côté client pour renforcer la confiance