Categories
Cloud Python

pyAggr3g470r dans le cloud

pyAggr3g470r est dorénavant déployable sur Heroku. Évidemment, il est toujours possible de l’utiliser sur un serveur traditionnel.

Voici comment le déployer sur Heroku. Rien de plus simple. Si vous désirez le tester mais que vous n’avez pas de compte Heroku, je peux vous créer un compte ici. Et oui, pyAggr3g470r est également multi-utilisateur maintenant!

Categories
Cloud Programming

Heroku contre Google App Engine

Pour introduire ce billet j’annonce que l’application (tout à fait inutile) Cédric, on mange où à midi? peut maintenant être déployée sur Google App Engine (instance de test) et sur Heroku (instance de test). Ceci avec le même code source et sans configurations spécifiques requises. J’ai ainsi pu faire une petite comparaison des deux principales plateformes PaaS. Pour faire court, je préfère le service Heroku.

D’abord je trouve les plateformes PaaS plutôt pratiques pour déployer des applications Web rapidement et sans avoir à se soucier de l’infrastructure. Malheureusement ces services sont assez onéreux. Mais les offres de base (gratuites) permettent de faire des choses assez intéressantes (comme déployer un démonstrateur pour une conférence, une application débile «d’aide à la décision», etc.). Les plateformes IaaS comme Amazon EC2 et Google Compute Engine sont également exorbitantes. Je suis plus intéressé par les services PaaS car ils m’apportent une simplicité de déploiement et forcent à structurer correctement le projet (c’est quand même super de pouvoir déployer avec Git un projet sur différentes plateformes PaaS ainsi que sur son serveur privé, sans avoir à modifier une librairie tierce ou le code). Mettant de côté l’avantage des ressources «élastiques», une plateforme IaaS n’a à mes yeux pas de grands avantages par rapport à une solution classique (serveur privé ou mutualisé). Et finalement une application déployée sur Heroku est cloisonnée dans une stack AWS (Celadon) cedar de base (je ne pense pas que l’offre d’entrée permet d’avoir une instance en Europe).
À noter qu’AWS offre actuellement un service PaaS, Elastic Beanstalk, que je n’ai pas encore testé.

Pour en revenir aux plateformes PaaS, le service Heroku est à mon avis clairement plus simple à utiliser que Google App Engine. Il suffit de comparer les documentations de ces plateformes respectives pour déployer une application Flask. Avec Heroku il est essentiellement requis de connaitre Python (bien sûr si vous déployez une application Python) et Git (un minimum). Tandis que App Engine nécessite l’installation d’un framework (à importer dans le code car il propose un certain nombre de fonctionnalités, notamment pour le stockage de données car sur une plateforme PaaS on ne peut généralement pas écrire de fichiers. Ainsi le framework fournit le Datastore) et quelques fichiers de configurations à placer dans votre projet (c’est donc un peu plus invasif dans votre application et ça ne la concerne pas directement).

Une autre différence notable est la manière dont les librairies tierces de votre application sont gérées. Avec Heroku il faut spécifier les dépendances dans un fichier nommé requirements.txt (comme de coutume pour un projet Python) afin qu’elles soient automatiquement installées côté plateforme. Avec App Engine il faut installer les librairies localement (avec pip) puis les envoyer en même temps que votre application grâce à un script Python inclus dans le SDK. Je pense que cette différence est principalement dû au fait que Heroku est basé sur des conteneurs Linux (LinuX Containers), comme le service Docker. Cette approche me plait bien mais je ne sais pas si les problèmes de sécurité connus de LXC s’appliquent dans un contexte PaaS (l’accès à la console ne se fait que via le client Heroku en utilisateur normal).

Le Dashboard de Google App Engine est plus complet (et bien plus compliqué) que celui d’Heroku, il est possible de contrôler beaucoup de choses (logs, facture très détaillée, charge de l’application, etc.). Mais je pense qu’avec un compte payant des choses se débloquent sur Heroku.

D’un point de vue temps de réponse, Google App Engine semble faire un peu mieux que Heroku, surtout lorsqu’un nouveau processus doit être initié après une période de repos de l’application. Je n’ai pas de mesures précises sur ce point et ça ne me pose pas vraiment de problème. À noter aussi qu’avec Heroku HTTPS est utilisé par défaut.

Finalement, vous pouvez utiliser mon petit projet «d’aide à la décision» pour les indécis comme tutoriel. C’est toujours mieux que le Hello World du tutoriel de Google App Engine. Et vous pourrez ainsi vous faire votre propre idée.

Categories
Cloud

Article When EC2 Hardware Changes Underneath You…

Lorsque le cloud trouve ces limites dans l’abstraction du matériel. Un article fort intéressant.

Categories
Cloud

Au revoir EC2

Mon instance EC2 va fêter son premier anniversaire dans quelques jours. Ça devrait être la fête. Malheureusement je vais devoir la tuer (oui après il faut payer, rendez-vous compte). C’est dommage. D’autant plus que j’attends toujours mon invitation pour GCE! Merci de ne pas me signaler si vous avez déjà votre invitation.

Et dépêchez vous de profiter de près de deux années d’articles de L’essentiel.

Effet de pyAggr3g470r sur une instance EC2 de base.
Effet de pyAggr3g470r sur une instance EC2 de base.
Categories
Technology

Tomahawk

Tomahawk est un lecteur de musique sous license GPLv3 utilisant la librairie Qt. Il est disponible sous Linux, Windows et Mac OS X. Les sources se trouvent ici.

Il a la particularité d’être ultra connecté et social. Des resolvers permettent de trouver de la musique via de nombreuses sources. Voici la liste de resolvers officiels (on peut implémenter un resolver pour des besoins personnels). Il y a même un resolver pour votre cloud personnel, si vous utilisez ownCloud. Mais aussi pour SoundCloud et d’autres.

La capture en haut de ce billet montre la bibliothèque locale (stockée sur le NAS mais monté sur l’arborescence de mon système) de mon ordinateur sous Debian. Dans le menu de droite on peut voir le Thinkpad (Windows) de Carole, dans la section Friends. De même, Carole depuis son ordinateur peut accéder à ma musique avec son propre Tomahawk (mais aussi avec ownCloud).

La capture ci-dessus montre que Tomahawk a trouvé Discobitch sur mon compte SoundCloud. Je n’ai pas cette musique sur mon réseau local. En fait, il ne faut pas vraiment se soucier de l’origine de la source avec Tomahawk. Et grâce aux resolvers que l’on peut ajouter, on a l’impression d’avoir accès à toute la musique.

Bref, un lecteur de musique libre bien sympa!

P.S.: amaroK aussi est très bien 😉

Categories
FLOSS Réseau

“Who does that server really serve?”

Une lecture intéressante.

Categories
Cryptography Internet Security Technology

Quand le ciel se couvre

Dark clouds over How Tun Woods

Ces derniers temps avec la monté en puissance du cloud computing pour le grand public nos applications tendent à disparaîtres et nos PC se transforment en petit espace de stockage (quelques gigaoctets sur un SSD) connectés. Les serveurs d’avant deviennent intelligents et ne se content plus de stocker. Ils nous fournissent applications et données. Applications propriétaires. Données trop publiques.

Un récent billet de Joanna Rutkowska me fait penser à une vieille idée. Dans ces conditions je serai partant pour utiliser quelque chose comme un Chromebook. Mon problème principal de la perte du contrôle des données est presque résolu. La solution est le chiffrement. Le chiffrement protège nos données de toute une série d’acteurs dont nous sommes forcé d’accorder notre confiance.

Le problème: est-ce que les fournisseurs de services seraient prêts à héberger toutes nos données chiffrées (donc inintelligible)? En générant nos clés de chiffrement et en chiffrant côté client les données avant de les envoyer sur le cloud toute cette polémique autour de dropbox n’aurait pas eu lieu. En même temps on pouvait s’y attendre, franchement comment un service comme dropbox ou Google pourrait héberger nos données pour ne rien en faire? Absolument rien, mis à part les stocker. Il n’y aurait donc aucune exploitation possible de ces données, quasiment plus d’intelligences dans ce cloud, juste du stockage. Un service si gentil serait de toute manière sous une licence type AGPL. Sinon où est l’intérêt?
Et cette intelligence sur le cloud, qu’elle est son utilité? Généralement établir notre graphe social (comme le dit Éric Schmidt de manière décomplexée), découvrir nos centres d’intérêts. Ce serait un peu plus compliqué avec un carnet d’adresses chiffré.

Je serai vraiment surpris que dans un avenir plus ou moins proche il soit possible de faire cela avec un Chromebook. Nous avons toutes les technologies et l’expérience requise pour implémenter cette idée, ce n’est que de la cryptographie. Il faudrait adapter un peu quelques applications clientes (pensez au potentiel d’aKonadi). Avec différents couples de clés on pourrait choisir avec qu’elle personne ou groupe(s) de personnes on partage une information Il y a des protocoles cryptographiques spécifiques pour ça. La notion d’espace partagé et surtout public de dropbox est une hérésie. Pour de nombreux types de données (agenda, localisation, numéro de téléphone, etc.) l’utilisateur a un besoin presque naturel de partager à des groupes de différents niveaux de confiance. Confiance relative. Confiance absolue pour le partage public.

Il faut donc garder nos bonnes vieilles applications clientes. Mettre plus de données chiffrées dans ce cloud qui est en train de tous nous baiser. Cela n’exclue pas de garder des applications web-based comme Gmail. Avec la solution de Joanna Rutkowska une application comme Gmail pourrait aussi avoir accès à nos données chiffrées.
De plus conserver les applications clientes ne peut que favoriser les standards et l’interopérabilité. J’aime savoir que Kontact, Evolution et Thunderbird puissent exploiter les mêmes données sur mon cloud, ou alors LibreOffice et KOffice. Avec des applications uniquement en ligne comme Gmail ou Google Docs on risque de perdre en interopérabilité (on sera rattaché à un service) et en qualité. Je trouve surtout ça moins élégant d’un point de vue informatique.
Certaines personnes aiment écrire des logiciels amateurs (par plaisir de comprendre comment fonctionne un ordinateur ou pour un besoin particulier) ou aiment savoir si une mise à jour d’un programme utilisé courrament a changée son comportement. La culture du Do It Yourself a besoin de ça.

Par sécurité (cf. les problèmes d’Amazon, du PSN et bien d’autres) il serait bon de synchroniser par exemple un NAS personnel avec notre petit morceau de cloud. Ce support de stockage devrait disposer (tout comme notre smartphone, tablette et PC portable) des clés appropriées pour garder les données non chiffrées (sécurité oblige, mais si souhaitable à ce niveau on peut utiliser TPM ou TXT). Le PC de bureau peut être connecté localement au NAS. Je pense que sur un PC fixe il est idiot d’utiliser un service cloud alors qu’on a un support de stockage qui peut s’occuper de synchroniser les modifications effectuées depuis ce PC. Si je veux regarder Titanic dans mon salon et qu’il est sur mon NAS non chiffré, pourquoi aller le chercher sur Internet? De même pour un simple fichier (et oui, bientôt avec Google Music vous pourrez écouter dans votre salon de la musique en ligne. La même qui se trouve sur votre disque dur). Par contre si le fichier est modifié, le support de stockage peut s’occuper de faire le chiffrement et la synchronisation. Par la suite on pourra continuer à éditer ce fichier avec un smartphone ou appareil type Chromebook sur le cloud. Pourquoi faire confiance inutilement à toute une flopée de services et gâcher des ressources?
On peut citer la couche d’abstraction d’aKonadi qui est très intéressante pour interagir avec le cloud. aKonadi permet de synchroniser son calendrier ainsi que ces contacts (sur gmail ou serveur personnel de façon transparente). Lorsque j’édite mon calendrier en ligne avec ma tablette mon calendrier KOrganizer est mis à jour sur le PC de bureau. Connexions sécurisées et calendrier sur mon disque dur disponible en mode non connecté (malheureusement le calendrier en ligne est visible pour Google). C’est un peu ce fonctionnement qu’il faudrait généraliser à toutes nos données.

La cryptographie est une arme puissante et incontournable qui nous aidera à conserver notre vie privée.

On pourra lire également ceci.