Lightbend a récemment annoncé CloudState. Créé par l'équipe derrière Akka, Play et le mouvement Reactive, CloudState est le premier framework serverless open source conçu pour permettre une gestion dynamique sur la pile Knative/Kubernetes.
Selon Jonas Bonér:
CloudState est une initiative visant à définir ce qu'est "Serverless 2.0" - ou la prochaine génération de serverless - en ajoutant un concept, un modèle et une implémentation autour de la gestion de l'état. Quiconque a construit une application cloud, un système distribué, sait que cet état est en réalité la chose la plus difficile à gérer, alors que le serverless l'ignorait plus ou moins jusqu'à présent. Nous essayons donc d'ajouter cela au mélange avec essentiellement deux choses. Le premier est un effort de normalisation définissant une spécification, un protocole et un TCK pour implémenter ces choses. Deuxièmement, une implémentation de référence mettant en œuvre les spécifications.
CloudState consiste essentiellement en deux choses, un effort de normalisation pour définir une spécification, un protocole entre les fonctions utilisateur et le backend, et un TCK; et une implémentation de référence, qui implémente le backend et un ensemble de bibliothèques d'API client dans de nombreux langages.
CloudState est conçu pour l'architecture à base d'événements (event-driven), event sourcing, CQRS, cluster sharding, la co-localisation de données et traitement, et CRDTs, aux côtés d'autres patterns distribués courants. En outre, l'implémentation de référence de CloudState s'appuie sur Knative, gRPC, Akka Cluster et GraalVM s'exécute dans Kubernetes, ce qui permet aux applications non seulement de scaler efficacement, mais également de gérer de manière fiable l'état distribué, tout en maintenant son niveau de cohérence des données globales ou locales.
Examinons à quoi ressemble un service CloudState :
(Image tirée de https://github.com/cloudstateio)
- Ingress - Peut être Istio, Knative ou un service de communication standard ClusterIP dans Kubernetes
- Akka Sidecar - injecté par l'opérateur CloudState; chaque requête passe par là. Les sidecars d'un seul service CloudState forment un cluster, communiquant directement entre eux via Akka Remoting
- Code - La fonction implémentée par le développeur. Il peut être écrit dans n'importe quel langage prenant en charge gRPC. Les sidecars d'Akka communiquent avec les fonctions utilisateur via un protocole prédéfini gRPC
- Distributed Datastore - Utilisé lorsqu'un service doit conserver son état. Il est important de noter que le code utilisateur n'interagit pas directement avec le datastore - il interagit avec les sidecars Akka et que les sidecars Akka communiquent avec le datastore.
CloudState implémente son propre autoscaler, car certains ont eut des problèmes avec KNative autoscaler lors de la mise à l'échelle d'un cluster Akka, l'un des problèmes est que lorsqu'un nouveau nœud est ajouté, les shards sont rééquilibrés et que l'état est répliqué. Si vous démarrez trop de nœuds en même temps ou que vous ne démarrez que des nœuds pour les arrêter immédiatement, le débit et les performances en seront considérablement réduits.
Plus de détails sur CloudState sont disponibles sur le dépôt GitHub. Il existe également une application d'exemple qui implémente un chat simple, disponible en Java et JavaScript.
Les utilisateurs qui souhaitent contribuer peuvent s'inscrire sur la liste de diffusion, rejoindre la discussion sur le canal Gitter ou rester en contact via Twitter.