Comme une centaine de personnes, je suis allé au cloud camp organisé hier, grace à une discussion que j’avais eu avec Eric Bezille de chez Sun (l’un des sponsors de l’évenement…merci pour l’accueil et le buffet Eric !). Ambiance détendue et pour une fois, ce qui est légerement contraires aux usages en vigueur dans les Camp, présentation plus formelle sous forme de slides powerpoint (ou keynote suivant les interlocuteurs). Pour des raisons diverses, je n’ai pu assister qu’à une partie de ces présentations avant de devoir m’absenter une heure.
Avant de partir j’ai écouté Eric présenter le travail et l’engagement de Sun dans le domain du cloud computing (cf son blogs, en ce qui me concerne je reviendrai surement dessus plus tard) puis l’intervention de Sam Johnston dont je lis régulièrement le blog et qui a présenté rapidement le cloud au travers de ses grandes caractéristiques (opex et non capex, commodity,virtualisation, admin automatique) et qui a présenté rapidement la carte mentale faite par Peter Laird concernant les principaux vendeur de services clouds.
J’ai ensuite participé au workshop sur l’architecture du cloud qui s’est révélé très intéressant tant par l’animation qui a été faite par Constantin Gonzalez Schmitz (sun) et Sébastien Pahl que par les contributions des participants. Les points suivants ont été évoqués :
Cloud Comuting Architecture workshop
but réutilisabilité du code entre les clouds et réversibilité
attention il faut vraiment séparer les chiottes différentes LB / Apache /DB … ça facilite le réversibilité
séparer également les service.
1/ Structured data SQL : les bases de données relationnelles ne sont pas toujours indispensable ni même adaptées au stockage de données structurées, il faut impérativement penser à utiliser Key/value stores ou les bases de données un peu plus évoluées telles que couchdb !! Par ailleurs, il a été évoqué dans ce cadre que MySQL (ainsi que bon nombre d’autre SGBDR classiques) pouvait devenir votre “pire ennemi” (dixit) dans le cadre de scabilité (attention a la réplication , aux incréments…)
2/ Introduire de l’asynchrone : tout n’est pas nécessairement synchrone, et l’utilisation de Message Queueing est sans aucun doute l’un des premiers pas à faire vers la scalabilité des applications
3/ Les applications doivent être pensée pour etre scalables sans que le développeurs ne doive se poser d’autre problèmes que les problèmes métiers. Les couches de scalabilité doivent introduire assez d’abstraction pour que cela soit pris en charge de manière transaprente. Quoi qu’il en soit le développeur doit penser REST.