AppScale 1.1 est sorti : où comment se créer son propre Google App Engine

Posté par  . Modéré par Nÿco.
Étiquettes :
18
18
juin
2009
Python
AppScale est une implémentation libre du Google AppEngine (GAE) de l'université de Santa Barbara, également à l'origine d'Eucalyptus, l'IaaS compatible Amazon EC2 à base de Xen/KVM. Le Google App Engine permet de développer des applications web hébergées par Google. AppScale permet de s'affranchir de l'hébergement Google.

AppScale permet l'exécution d'applications GAE au choix au sein :
  • D'une fabrique de cloud computing (EC2, Eucalyptus) ;
  • De VMs Xen/KVM/VMware/etc. ;
  • De serveurs physiques.

Composants d'AppScale :
  • Google App Engine SDK ;
  • Mongrel ;
  • Hadoop pour son FS clusterisé HDFS (remplaçant GFS) ;
  • Hbase ou hypertable ou MySQL pour le key/value datastore (remplaçant bigtable) ;
  • Un connecteur GAEbackend générique ouvrant la voie au support d'autres bases très tendance comme Cassandra, Voldermort ou encore MongoDB.
Dans un contexte où le cloud computing pose de réelles questions de sécurité et de contrôle des données hébergées au sein de ces clouds commerciaux, AppScale est une première étape vers la possibilité d'installer son propre cloud-computing compatible GAE.

Le sandboxing de GAE, les nombreux frameworks disponibles, l'intégration avec de plus en plus d'IDE sont autant d'atouts pour considérer cette initiative, tout comme celle d'Eucalyptus, comme une réponse libre crédible aux offres commerciales de Cloud-Computing et les questions que celles-ci soulèvent.

GAE ayant démontré son extraordinaire scalabilité - notamment lors de l'élection américaine où de nombreux services de la Maison Blanche étaient propulsées par GAE - il sera intéressant de voir comment AppScale se comporte en terme de performance.

À n'en pas douter, l'infrastructure Google a de l'avance. Le projet AppScale n'a d'ailleurs pas vocation à le concurrencer sur le terrain de la performance.
On y voit néanmoins un intérêt grandissant pour les entreprises désireuses de maitriser leurs données tout en suivant le standard de développement de plus en plus adopté qu'est GAE.

GAE devient un framework de frameworks lorsque l'on voit l'initiative d'IBM où une app GAE peut-être rapatriée sous leur infra Websphere (cf. Google Camp 2009) en ne touchant quasiment pas au code.

On peut également imaginer des entreprises lancer à tout hasard leurs services web sur l'App Engine de Google et si l'un d'entre-eux trouve une audience importante, le rapatrier dans leur App Engine privé afin d'en garder le contrôle.

Le support de Java est prévu dans la feuille de route (cf. les notes de version), il ouvrira la porte aux autres langages compilables en bytecode Java comme PHP, Ruby, etc.

Aller plus loin

  • # kezako

    Posté par  . Évalué à 10.

    Pour les gens qui connaissent le GAE, la news doit être claire. Pour moi non.

    J'ai chercher un peu (bon d'accord, pas beaucoup) sur le net une définition technique claire, mais sans succès.

    Quelle est donc la différence entre developper sur GAE et sur un hébergeur classique, par ex avec PHP, ou une plateforme complète virtualisée?
    Et c'est quoi l'interet de Appscalte, par rapport à des serveurs d'application privés classiques?

    J'ose à peine demander c'est quoi ce foutu "Cloud", mais là j'ai peur de declencher un troll pour marketeux...

    • [^] # Re: kezako

      Posté par  . Évalué à 5.

      alors qu'il te suffisait de gueuler "FOUTAISES !" pour scorer à +10 /o\

    • [^] # Re: kezako

      Posté par  (site web personnel) . Évalué à 6.

      J'ose à peine demander c'est quoi ce foutu "Cloud", mais là j'ai peur de declencher un troll pour marketeux...

      C'est un perso de final fantasy

      • [^] # Re: kezako

        Posté par  . Évalué à 2.

        effectivement... Mais je ne m'en rappelais plus, car je renomme toujours mes perso.
        Certains me diront "Mais pourquoi?", j'ai envie de leur dire "Parce que c'est possible".

      • [^] # Re: kezako

        Posté par  . Évalué à 3.

        Cloud François ?

    • [^] # Re: kezako

      Posté par  . Évalué à 6.

      C'est vrai que les définitions du Cloud Computing sont nombreuses et n'aident pas à la bonne compréhension de tout ce buzz autour de Google App Engine.

      J'aurais dû en effet éclaircir un peu le concept avant d'introduire le projet (my 2 cents).

      Tout d'abord, l'App Engine est l'infra d'hébergement de Google proposant un SDK (python ou java) pour développer des applications web.

      Cet hébergement est gratuit (en deçà de certains quotas relativement confortables) et payant au delà de ces quotas (le paiement se fait à la charge consommée: cpu, io, bande passante), on ne paye que ce que l'on utilise.

      La différence par rapport à un hébergement virtualisé type Amazon EC2 qui utilise du Xen, c'est que l'on n'a pas à gérer la plateforme (google s'en charge pour toi), ni à gérer la scalabilité, là encore l'infra google est prévue pour scaler potentiellement à l'infini. Ceci est possible car on sort du modèle traditionnel LAMP avec une base de donnée relationnelle réputée peu scalable.

      Tu développes en local avec le GAE SDK (python ou java) et tu déploies directement sur l'app engine d'un clic. Tu peux déployer plusieurs versions d'une même application en // et y accéder avec des sous-domaines du type dev.mydomain.com par exemple.

      Le plus simple est de regarder une vidéo d'introduction sur le site App Engine de Google [http://code.google.com/intl/fr-FR/appengine]

      L'intérêt de AppScale est de continuer d'utiliser ce standard de développement qu'est l'App Engine, tout en ayant la liberté de ne plus être dépendant de l'infrastructure Google. Par exemple, une entreprise qui souhaite déployer une application sensible sans exposer ses données à Google, pourra le faire à l'aide d'AppScale.

      • [^] # Re: kezako

        Posté par  . Évalué à -2.

        Si je devais faire une comparaison qui vaut ce qu'elle vaut:
        Appscale est à Google App Engine ce que identi.ca est à twitter.

      • [^] # Re: kezako

        Posté par  . Évalué à 3.

        Ceci est possible car on sort du modèle traditionnel LAMP avec une base de donnée relationnelle réputée peu scalable.

        Oui, en même temps il faut éviter la masturbation intellectuelle. Les bases de données relationnelles « réputées peu scalables » sont certainement suffisantes pour 99,99% des projets Web (y compris des sites très visités comme, tiens par exemple, Linuxfr)... Et les 0,01% restants méritent certainement mieux qu'une plateforme ultra-bridée et propriétaire telle que Google App Engine.

        En réalité, les mérites de GAE semblent bien limités mis à part le fait que c'est un hébergement Python prêt à l'emploi (mais bridé et utilisant une infrastructure non-standard). Si ce n'était pas Google (tm) qui l'avait fait et avait attiré de ses feux multicolores les geeks grégaires ébahis, personne ne s'intéresserait à ce bidule propriétaire.

        • [^] # Re: kezako

          Posté par  . Évalué à 1.

          Je te rejoins sur le 99,99% des projets web même si je dirais un chiffre moindre.

          Pour une bonne part des projets, tu ne sais pas à l'avance quel besoin de scalabilité tu auras. Le coût d'entrée (en terme de développement) est certes un peu élevé (perte des repères RDBMS, pas d'accès au FS, etc. ; les contraintes du sandboxing en somme) mais est compensé par rapport au gain que tu en tires en n'ayant pas à te préoccuper de la scalabilité de ta plate-forme (the 70/30 switch cf. [http://mashraqi.com/2008/06/werner-vogels-keynote-at-structu(...)] ).

          Bien sûr pour des projets existants gérant parfaitement les pics de charge, ça n'a pas grand sens de porter son application sur l'App Engine (par exemple linuxfr ;-).

          L'hébergement Google App Engine est en effet bridé et propriétaire. C'est justement pour cela qu'AppScale (open source) est intéressant; le GAE SDK (java ou python) que fournit Google est lui aussi open source. AppScale permet justement de s'affranchir du backend Google.

          Quant à la standardisation, elle évolue en permanence. LAMP est le standard le plus répandu, ça ne veux pas dire que c'est celui qui a le plus de potentiel d'avenir.

  • # Production ?

    Posté par  . Évalué à 4.

    Est ce fait pour la mise en production ou tout comme eucalyptus c'est avant tout une plateforme de tests et de recherches (voir la faq de ce dernier) ?

    • [^] # Re: Production ?

      Posté par  . Évalué à 3.

      très clairement, pour le moment c'est à l'instar d'eucalyptus pour du test et de la recherche. la dernière version d'eucalyptus est quand même très mature même si tout comme appscale, ça n'est pas forcément simple à déployer.
      voilà pourquoi j'ai parlé de première étape vers la possibilité d'installer son propre cloud-computing compatible GAE.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.