@sdelbecque: I'll be at the office around 2:30PM : feel free to join before 3PM, and we'll drive you to Orange as well ;-)

Google App Engine

App Engine, c’est le nouveau produit de Google qui vient directement marcher sur les plate-bandes d’Amazon EC2. Sans être un service de virtualisation, Google met à la disposition des developpeurs d’application web une “stack” qui va leur permettre de ne soucier plus que du developpement de leur code et plus de l’infrastructure qu’elle soit logicielle ou matérielle (celle à laquelle s’est déjà attaqué Amazon avec EC2 en particulier).

App Engine sera gratuit pour les 10,000 premiers utilisateurs en béta : dépechez-vous! Google App Engine est en fait une boite à outils contenant d’autres produits de Google, tels que BigTable -un système de base de données interne à Google-, ou même l’authentification Google (valable sur toutes les applications). D’ailleurs Google, à l’inverse d’Amazon exige l’utilisation de toute sa stack pour les applications App Engine (vous pouvez utiliser EC2 et S3 indépendamment chez Amazon!)

Gros point noir pour moi : le fait que cela soit Python only pour l’instant, même si ils annoncent une ouverture sur d’autres langages plus tard. Le pricing se fait comme chez Amazon : à l’usage… par contre, on descend encore d’un niveau puisque ce sont les cycles CPU et non le temps qui sert d’unité de mesure de base!

Plus d’infos par .

 

 

 

Related Articles

Trackbacks & Pingbacks

[…] supplémentaire au dessus de l’existant, pour se rapprocher du client. Pour moi, Google App Engine, c’est une nouvelle couche posée sur une pile qui a commence a […]


Comments

Un peu incohérent de la part de Google de ne proposer que Python côté serveur sachant qu’ils proposent à côté le framework Web GWT (que j’utilise) et qui nécessite un conteneur de Servlet (Tomcat par exemple) pour pouvoir faire du RPC async. Au final, cela limite beaucoup son utilisation dans ce contexte.

Sinon, c’est bien sympa mais l’idée d’être si fortement couplé à Google me fait froid dans le dos.
Moi, je passe.

@Thomas : tu as tout a fait raison… ce qui fait le plus peut ce sont les conditions generales d’utilisation qui sont tres “libres” pour Google!

Je pense que l’avantage de Python ici est d’utiliser des CGI et donc d’avoir un fonctionnement “par requête”, ce qui est beaucoup plus facilement parallélisable que un servlet Java.

J’avoue que je me vois mal apprendre le Python pour exploiter ce service. J’ai déjà appris des langages tels que :

- l’assembleur MIPS,
- l’assembleur x86,
- l’assembleur Z80,
- le BASIC,
- le C,
- le C++,
- le C#,
- le COBOL,
- le GFA Basic,
- le HTML,
- le J++,
- le Java,
- le JavaScript,
- le Pascal,
- le PHP,
- le Qbasic,
- le SQL,
- le Turbo Basic,
- le Turbo Pascal,
- le Visual Basic,
- le XHTML,
- le XML,
- etc.

Il est clair que je ne maîtrise pas parfaitement bien chacun de ces langages, mais je commence à me demander combien d’autres langages il faudra apprendre pour travailler efficacement ? est-il efficace de passer son temps à apprendre et non pas à produire ?

D’ailleurs, je me demande bien où est-ce que l’on apprend le Python, à part quelques universités américaines ? Durant mon relativement court passage au Royaume Uni, le responsable de mon stage s’émerveillait devant Awk que j’ai heureusement évité d’apprendre, vu que je n’ai jamais encore rencontré ce langage dans l’industrie.

Ceci dit, Google a une large culture de la diversité, n’imposant jusqu’à présent aucun langage en particulier, contrairement à Microsoft, par exemple, qui met systématiquement en avant ses propres solutions, au point que développer des services web dans d’autres langages que les langages .Net devient difficile.

Yahoo!, de son côté, semble préférer le PHP, en interne, mais fournit une large gamme d’API pour ses services, ainsi qu’une documentation relativement claire pour les exploiter dans diverses situations.

Gageons donc que de nouveaux langages et API soient rapidement mis à disposition des développeurs pour exploiter les centres de données de Google. En attendant, je continue mes applications LAMP classiques qui tournent très bien sur mes serveurs bon marché et répondent parfaitement à l’ensemble de mes besoins actuels.

D’ailleurs, si l’on s’y prend correctement, il est rare que l’on ne puisse pas intégrer la notion d’échelle horizontale et verticale dans une application web dès sa conception, ou du moins pouvoir étendre assez rapidement une application existante correctement écrite pour répondre à des besoins d’échelle. De plus, avec des services de virtualisation tels qu’Amazon EC2, Amazon S3 et autres Gandi Hébergement qui permettent de louer des serveurs de l’heure, à la journée, ou de l’espace de stockage facturés au Go, ce marché ne comporte pas énormément de concurrents, mais si chacun propose ses propres API ou langages incompatibles avec le reste du monde, cela ne va pas aider ces services à se déveloepper…

@Ralphy, oui, c’est certain, Google va ouvrir verticalement son service App Engine.

Tous les services informatiques qui se lancent ont la même problématique : faut-il rester fermer pour être le seul gros et devenir énorme, ou faut-il s’ouvrir au maximum aux autres pour faire grossir le marché et n’en prendre qu’un morceau raisonnable?

L’utilisateur/client préfère clairement la seconde solution, l’entrepreneur, l’investisseur y voient malgré tout un risque de se faire doubler!

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

(required)

(required)