Amazon vient de rendre disponible la béta publique de son offre VPC. Virtual Private Cloud, c'est un peu le meilleur des deux mondes. comme je l'avais déjà signalé précédement, le cloud computing dans sa formule de "Infrastructure As A Service" voit encore aujourd'hui de nombreuses réticences dans les entreprises, principalement sur l'aspect public de l'infrastructure. Amazon souhaite amener les entreprises vers ses services d'infrastructures en leur permettant d'y accéder de manière très sécurisée.  VPC est un pont entre le réseau de l'entreprise et une partie "privatisée" du réseau Amazon. Pour entrer un peu plus dans le détail sur l'architecture de VPC, on a un routage IP qui est réalisé de manière encryptée par un protocole IPSEC vers  un pool de ressources AWS dans les datacenter d'Amazon.  Le client dispose de la pleine maîtrise de l'adressage IP et des politiques de sécurités appliquées sur les ressources placées dans ce cloud.  Le client va disposer de la même sécurité que si il devait louer des unités dans un datacenter externe et y installer ses serveurs, mais avec l'avantage de la souplesse du cloud.  L'utilisation de l'architecture Elastique de Amazon permet de retailler très facilement les ressources affectées, et de n'utiliser que ce qui est vraiment nécessaire à un instant T. Les usages qu'on peut imaginer entre autres d'un telle infrastructure seraient :

• La mis en œuvre de plan de continuité d'activité à moindre coûts. Par essence les ressources affectées aux plan de continuité d'activité ne sont utilisée que lorsque celui-ci est actif. Le reste du temps ces ressources sont inutilisées ou alors le sont pour des tâches secondaires, qui peuvent être arrêtées à tout moment. Le concept de base d'Amazon WS et EC2 , consiste à n'utiliser que ce dont vous avez besoin à un instant T.  Pour résumer le client en temps normal ne paye que la consommation de ressources nécessaire à synchroniser son datacenter avec les machines en attentes d'être activées pour le plan de reprise, d'où une approche financière des plus favorables.
• La mise à disposition d'une réserve de ressources pour effectuer des traitements ponctuels et fournir une puissance de calcul instantiable immédiatement. Dans de nombreux business il y a des opérations qui ont une forte saisonnalité, comme par exemple la production de fiches de payes, la réalisation d'inventaires de fin d'année. Autant sur de très gros systèmes, on a une logique de puissance installée et d'activation de tranches à la demandes que sur des architectures ouvertes de type x86, on peine un peu plus à avoir ce type de granularité. Là aussi, il faut prévoir le cas le plus défavorable et acquérir les ressources nécessaires quand bien même celles-ci sont inutilisées pendant les périodes creuses.  De nouveau les concepts évoqués précédemment vont permettre de disposer d'une puissance de traitement qui soit dans un état d'attente donc ne coûtant quasi rien et de mettre celle-ci en route en quelques minutes.

Il convient de rapprocher cette architecture de la possibilité de nos jours d'utiliser les outils de cloud computing dans le datacenter de l'entreprise, et de pouvoir migrer les ressources chez des providers tels Amazon. On se trouve donc aujourd'hui en face de trois type de cloud, le "cloud privé" qui est hébergé chez le clients sur ses propres serveurs physiques, le "cloud privé virtuel" qui donc est hébergé chez le fournisseur, mais vu comme une extension du réseau de l'entreprise, et pour finir le cloud public. Le gros challenge à venir va être la capacité de management et d'interopérabilité entre ces différentes briques qui commencent à être bien abouties. Pour aller plus loin je vous invite à consulter la pasge de présentation Amazon Virtual Private Cloud.

Tranquillement installé cette après midi à regarder mes mails en retard et autres trucs moins sérieux, et d'un seul coup un mail arrive me sortant brutalement de ma torpeur. Un client dont l'application est en production depuis des semaines m'explique que plus rien ne fonctionne. Tout de suite échanges de mails, échanges divers pour creuser et tenter d'avoir un début d'explication. Evidemment tout ça commence par la classique action du saint esprit puisque personne n'a touché a rien, et rapidement des produits de protection systèmes ont été modifiés, bref finalement on se rend compte que l'application qu'on est en train d'essayer de débugger est parfaitement opérationnelle. Quel est l'intérêt de parler de ce type d'événement si ce n'est que ça amène toute la difficulté de l'exploitation d'applications par un client. Celui-ci doit maintenir un système en condition opérationnelle, en n'ayant -et c'est bien légitime- pas forcement la pleine mesure des effets de bords des opérations qui sont à réaliser sur les serveurs. Pourquoi pas lui proposer alors de passer en mode SaaS de type Cloud Computing, on externalise toute l'application et le client se connecte à ses données depuis Internet. Tout ça n'est pas si simple, il  y a d'abord la réticence évidente et paradoxale d'un client d'une petite structure à envoyer ses données sur internet, a ne plus les posséder en interne chez lui. A ce premier point s'ajoute parfois l'aspect technique, parfois des applications fonctionnement bien en local, mais pas évident que ce soit aussi efficace à distance. De ces différentes interrogations, et assertions me vient une reflexion qui consiterait à déployer des conteneurs d'applications chez les clients et à les gérer à distance. Ainsi on isole l'application pour être certain qu'elle continue à s'executer dans un environnement intègre, on en assure la maintenance et les évolutions, et on a la certitude qu'il n'y a pas de problèmes 'étranges'. Concrêtement cette logique peut s'envisager au travers d'une infrastructure de virtualisation chez le client et ainsi permettre de faire converger les deux préocupations, celle du client de propriété de ses données, et par ailleurs celle de robustesse et d'indépendance. On pourrait qualifier ça de 'in house cloud computing', l'application s'exécute dans un conteneur virtualisé, et à partir de là le client accède à un service sans plus de dicernement. Le concept reste à expérimenter, donc à suivre...

Aptana jusqu'alors connu pour ses outils de développement web javascript et rails, vient de lancer en beta sa plate-forme de déploiement de type Cloud Computing. Le principe est assez simple, après avoir créer localement votre application, l'avoir testée, etc on l'envoie directement depuis l'IDE vers le "Cloud". C'est là que cette notion de cloud est intéressante, puisque on va juste spécifier une quantité de ressources à allouer, un niveau de service, et quelques options de configuration. La tarification mensuelle est donc facteur de tous ces éléments, et on a globalement à peu près tout ce qu'il faut pour déployer une application. L'allocation d'une configuration minimale de 256 Mo de mémoire et de 5 Go de disque coûte à peu près 30$ par mois.   Dougal Matthews à testé la plate-forme en question, je vous invite à aller voir son post.