1 La réécriture en Go signifie-t-elle que tout le code backend actuel est jeté à la poubelle ?
Malheureusement, oui. Ceci dit, la grande majorité de notre code actuel est côté front et va pouvoir être gardé. Et pour le côté back, on a tiré des enseignements de la version actuelle qui vont bien nous aider pour la suite pour éviter de retomber dans les mêmes pièges (notamment, une bien meilleure connaissance de CouchDB).
2 Comment est-ce que seront écrites les applications de Cozy ?
Le but est d'avoir un maximum qui ne fonctionnent que côté client. La stack en Go va fournir un grand nombre de services communs aux applications pour ça.
Bien entendu, pour certaines applications, ça ne va pas être possible. Par exemple, The lounge, un client IRC, ne peut pas tourner côté client car il a besoin de se connecter à un serveur IRC (ce que les navigateurs web ne permettent pas). Dans ce cas, il est effectivement prévu de les faire tourner à côté et de les laisser discuter avec le core via l'API Rest.
3 Est-ce que le départ de Frank est lié à ce changement d'architecture ?
Les discussions ont commencé avant le départ de Frank et il a participé à celles-ci.
Une des raisons qui nous motive à changer d'architecture est le coût d'une instance Cozy. La version actuelle en nodejs est gourmande en RAM et ça coûte donc des sous pour héberger un Cozy (l'achat d'un RPi + électricité qui va avec, ou louer un serveur assez puissant chez un hébergeur, ou les sous de Cozy pour l'offre beta gratuite). On parle de quelques euros par mois (à multiplier par le nombre de personnes pour une famille si chacun veut son cozy). C'est un gros frein pour avoir beaucoup plus d'utilisateurs. Tout le monde est d'accord sur ce point.
Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).
À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.
Le Concours d'Innovation Numérique a fait pencher la balance pour cette seconde option (et la levée de fonds auprès de la MAIF quelques mois plus tard a renforcé cela).
4 Comment est-ce que vous allez gérer la transition au sein de l'équipe de Cozy Cloud ?
Il est prévu que l'on soit 3 développeurs back :
un développeur recruté pour l'occasion
un développeur nodejs, qui a déjà regardé Go mais n'en a quasiment pas fait, et va donc se reconvertir
Mais nos développeurs JS ne vont pas chômer pour autant. Comme je l'expliquais plus haut, la majorité du code de Cozy est côté front. Actuellement, ils travaillent sur le client emails. Et il y a beaucoup d'autres choses qui les attendent ensuite.
5 Néanmoins, j'ai l'impression qu'il n'y a toujours pas de vision claire du modèle économique. Est-ce qu'il y a eu des évolutions à ce sujet ?
On souhaite que ce soient les entreprises qui nous payent, pas les particuliers. Ça peut-être des grands groupes comme EDF qui souhaitent expérimenter autour de Cozy ou qui veulent développer une application pour Cozy (même si tout le monde peut le faire, les grands groupes sont souvent rassurés si c'est nous qui le faisons). On souhaite également renforcer nos partenariats avec des hébergeurs comme Gandi et OVH. Et enfin, si MAIF et d'autres ensuite vont proposer des instances Cozy à leurs clients, nous seront forcément sur le chemin pour les accompagner.
6 Est-ce pour pouvoir s'intégrer dans un environnement comme celui de la MAIF qu'il a été envisagé de réécrire CozyCloud et d'en changer son architecture ?
On en revient à la question des coûts. La MAIF a des millions de sociétaires et si elle veut proposer une instance Cozy à chacun d'eux, c'est sûr que quelques euros par instance chaque mois, ça va être trop cher.
Est-ce que vous avez eu des discussions avec des architectes à cravate de chez eux à ce sujet ?
Non, il n'y a eu aucune discussion de ce type. Je pense que la MAIF nous fait entièrement confiance pour ça.
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 10.
Malheureusement, oui. Ceci dit, la grande majorité de notre code actuel est côté front et va pouvoir être gardé. Et pour le côté back, on a tiré des enseignements de la version actuelle qui vont bien nous aider pour la suite pour éviter de retomber dans les mêmes pièges (notamment, une bien meilleure connaissance de CouchDB).
Le but est d'avoir un maximum qui ne fonctionnent que côté client. La stack en Go va fournir un grand nombre de services communs aux applications pour ça.
Bien entendu, pour certaines applications, ça ne va pas être possible. Par exemple, The lounge, un client IRC, ne peut pas tourner côté client car il a besoin de se connecter à un serveur IRC (ce que les navigateurs web ne permettent pas). Dans ce cas, il est effectivement prévu de les faire tourner à côté et de les laisser discuter avec le core via l'API Rest.
Les discussions ont commencé avant le départ de Frank et il a participé à celles-ci.
Une des raisons qui nous motive à changer d'architecture est le coût d'une instance Cozy. La version actuelle en nodejs est gourmande en RAM et ça coûte donc des sous pour héberger un Cozy (l'achat d'un RPi + électricité qui va avec, ou louer un serveur assez puissant chez un hébergeur, ou les sous de Cozy pour l'offre beta gratuite). On parle de quelques euros par mois (à multiplier par le nombre de personnes pour une famille si chacun veut son cozy). C'est un gros frein pour avoir beaucoup plus d'utilisateurs. Tout le monde est d'accord sur ce point.
Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).
À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.
Le Concours d'Innovation Numérique a fait pencher la balance pour cette seconde option (et la levée de fonds auprès de la MAIF quelques mois plus tard a renforcé cela).
Il est prévu que l'on soit 3 développeurs back :
Mais nos développeurs JS ne vont pas chômer pour autant. Comme je l'expliquais plus haut, la majorité du code de Cozy est côté front. Actuellement, ils travaillent sur le client emails. Et il y a beaucoup d'autres choses qui les attendent ensuite.
On souhaite que ce soient les entreprises qui nous payent, pas les particuliers. Ça peut-être des grands groupes comme EDF qui souhaitent expérimenter autour de Cozy ou qui veulent développer une application pour Cozy (même si tout le monde peut le faire, les grands groupes sont souvent rassurés si c'est nous qui le faisons). On souhaite également renforcer nos partenariats avec des hébergeurs comme Gandi et OVH. Et enfin, si MAIF et d'autres ensuite vont proposer des instances Cozy à leurs clients, nous seront forcément sur le chemin pour les accompagner.
On en revient à la question des coûts. La MAIF a des millions de sociétaires et si elle veut proposer une instance Cozy à chacun d'eux, c'est sûr que quelques euros par instance chaque mois, ça va être trop cher.
Non, il n'y a eu aucune discussion de ce type. Je pense que la MAIF nous fait entièrement confiance pour ça.