Les avantages du cloud computing

J’ignore si vous êtes familiés avec le terme « cloud computing » ou pour les amis à l’OLF l’informatique dans les nuages (c’est vraiment le terme, sans farces). Ceci consiste à impartir une portion de vos besoins en logiciels vers des compagnies qui offrent gratuitement or à faible coût l’utilisation de leurs applications (SaaS – Software as a service) ou leur plateforme d’hébergement d’applications sur mesure.

J’ai tombé sur cet article très simple qui explique les avantages pour une entreprise d’opter pour ce genre d’architecture de systèmes. Voici quelques points que j’ai cru bon reprendre:

  • Besoins de super-machines ayant de gros CPU pour des calculs complexes.
  • Le CPU, le stockage et la bande passante sont sur demande, donc ils deviennent des frais variables en fonction de vos besoins/chiffre d’affaires (vous allez avoir le comptable de votre poche!).
  • Vos applications et vos données seront accessibles dans une salle de serveur très bien déservie par de multiples liens data qui faciliteront l’intégration avec des tiers (applications ou partenaires).
  • Le nuage est collaboratif et intégrant, vous pouvez amalgamer des nouvelles technologies et vous intégrez plus facilement avec vos clients, vos fournisseur et d’autres groupes.
  • Le Cloud Computing est moins couteux et a une meilleur structure de coût.
  • Le support et la gestion du cycle de vie des applications que vous louez est compris et assuré par votre fournisseur.
  • La sécurité est augmentée car les données sont centralisées dans un datacenter de classe mondiale que vous pourriez jamais vous payer.

Et voici quelques points que j’ajouterais:

  • Le développement et le déploiement d’applications se fait plus rapidement, car on ne se soucie pas de la mise en place et du support de l’infrastructure technologique.
  • Vous vous concentrez sur votre mission première d’entreprise au lieu de vous lancer dans l’hébergement de serveurs (salle de serveurs, etc.), le développement de logiciel maison et le support informatique.

Promotion d'événements par la technologie

Plusieurs organisations offrent des événements de réseautage et d’échange à leur communauté de membres. J’inclus ici les associations professionnelles, les chambres de commerce, les groupes d’intérêts, les syndicats et les club sociaux. Ces organisation pour la plupart n’ont toujours pas rejoint l’ère du Web 2.0. Pourtant leur raison d’être correspond exactement à la philosophie qui est derrière le renouveau du WWW.

Qu’est-ce que le Web 2.0 ? Il y a malheureusement autant de définitions que de spécialistes en la matière. Toutefois, la concept de partager facilement l’information du web fait consensus.

Les sites web qui diffusent de l’information et la seule rétroaction qui est permise aux internautes c’est d’écrire un courriel dans la page contactez-nous, sont certainement des sites du Web 1.0. Alors que dans le Web 2.0, le partage signifie que le contenu du site est prise en charge partiellement ou entièrement par les internautes et que le contenu peut être facilement envoyé à un tiers.

Partage des événements

Est-ce que votre organisation partage ses événements? Est-il facile pour vos membres de découvrir et d’être renseigné sur événements à venir? Pourtant, il existe des technologies relativement anciennes qui se popularisent ces jours-ci pour permettre le partage de votre calendrier d’événements.

Le format iCalendar est un format très répandu qui permet l’échange de données d’un calendrier électronique vers un autre. C’est un fichier en format texte très facile à produire et à lire. Si vous offriez à vos membres un abonnement à un fils iCalendar par lien HTTP à jour de vos événements, ils pourront le visionner dans leur propre logiciel de Calendrier tel que Outlook ou Google Calendar. Au lieu que vos membres viennent vérifier sur votre site les nouveautés, vos nouveautés s’intégreront dans leurs outils quotidien.

lls pourraient alors voir la liste de vos activités à venir à jour. Si un événement est ajouté, il sera ajouté dans leur calendrier. Si un événement est déplacé ou supprimé, ils verront le changement aussi.

Comment puis-je offrir un fils iCalendar?

Si vous avez déjà un site web avec un calendrier des événements informatisé (géré par un CMS), vous n’avez qu’à créer un simple script dans un language supporté par votre serveur HTTP (.NET, PHP, ASP, etc.). Le script n’a qu’à produire un fichier texte ayant « Content-Type: text/calendar » dans l’entête et encodé en UTF-8. Chaque événement devra être écrit dans un bloc VEVENT avec les infos que vous avez à votre disposition dans votre système actuel. Si vous ne voulez pas le modifier votre CMS ou vous ne pouvez pas, vérifier si vous avez accès en lecture à sa base de données. Le script pourrait lire la base de données directement en outrepassant l’outil de publication que vous avez en place.

Dans le cas que vous n’offrez pas encore un calendrier informatisé, et les dates et description de vos activités sont simplement inscrites dans une page web en texte libre, je vous conseillerais alors de créer un agenda publique sur un site reconnu et gratuit.

Par exemple, vous pourriez créer et maintenir un agenda publique sur Google Agenda. Dans les propritétés du calendrier, vous pouvez le rendre publique et obtenir ainsi le lien URL vers son fils iCalendar. De plus, Google vous offre la possibilité de l’afficher et l’intégrer dans une page de votre site actuel sans avoir recours à la programmation.

Une autre option, c’est de créer chaque événement dans un site tel que Upcoming. Une fois que vos événements sont saisis, il est facile de généré un fils iCalendar basé sur des critères de recherche. Vous n’avez qu’à communiquer l’URL à vos membres (il est disponible sur la page My Events). Aussi, le site d’Upcoming vous offre des « badges » qui s’insère dans l’une de vos pages pour afficher les événements à venir.

En conclusion, les gains promotionnels de vos événements justifient clairement le support à ce format très répandu sur la toile. Il est faux de croire que vos membres visiteront régulièrement votre site pour s’informer. Il faut plutôt ajouter des facilités d’abonnement et de partage d’information sur votre site pour augmenter le rayonnement.

Mon expérience avec le Wi-Fi à bord de Via Rail

En novembre, j’ai fait l’essai du service Internet sans fil à bord d’un voyage Québec-Montréal à bord d’un train Via Rail. J’avais de basses attentes puisque j’avais lu au préalable que le service est supposément lent et sensible au mauvais temps.

Dans la gare, la connexion du train était assez performante et fonctionnelle. Une fois qu’on est connecté à leur réseau publique non sécurisé, on est redirigé sur une page de connexion lors de notre première visite de page web. Je m’inscris avec enthousiasme. L’heure de départ est arrivée, le train quitte la station.

Lors de mon voyage, le ciel était couvert et nuageux. Il ne pleuvait pas. Aussitôt que le train s’est retrouvé à l’extérieur plus aucune page m’a été servi. J’ai tenté par tous les moyens et rien ne fonctionnait. J’ai voulu utiliser MSN, Google Talk ou même allez voir mon Gmail par Firefox et rien n’aboutissait.

Je demande à l’agent de bord, si c’est normal que ça ne fonctionne pas, il regarde dehors et il me répond tout bonnement, c’est trop couvert pour fonctionner. Parfait, j’arrête de m’en faire et j’attends tout au long du voyage que la connexion s’améliore.

Rendu à mi-chemin, le ciel est partiellement couvert, on voit des percés de soleil. Je tente de faire un « Refresh » sur mon Gmail, mais l’application me sort le message qu’on voit rarement « This seems to be taking longer than usual« . J’essaie alors la version standard HTML qui est conçu pour les connections lente: aucun succès.

J’arrive plus tard à la gare de Montréal ayant profité d’au plus 10 pages vues de sites internet pendant tout le voyage. Mon MSN a réussi à se connecter, mais lorsque j’envoyais un IM à quelqu’un, la majorité des étaient perdus et ne se rendait pas.

Pour les plus techniques, voici une trace de ping que j’ai fait à bord du train lors des meilleures conditions météo que j’ai eues.

Envoi d'une requête 'ping' sur www.l.google.com [64.233.169.104] avec 32 octets de données :
Réponse de 64.233.169.104 : octets=32 temps=555 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=495 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=495 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=522 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=500 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=506 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=707 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=527 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=471 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=502 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=613 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=515 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=846 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=518 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=684 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=524 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=548 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=469 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=515 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=481 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=521 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=563 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=651 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=3831 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=438 ms TTL=240
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 64.233.169.104 : octets=32 temps=1831 ms TTL=240
Réponse de 64.233.169.104 : octets=32 temps=318 ms TTL=240
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.

Statistiques Ping pour 64.233.169.104:
    Paquets : envoyés = 34é re‡us = 27é perdus = 7 (perte 20%)é
Durée approximative des boucles en millisecondes :
    Minimum = 318msé Maximum = 3831msé Moyenne = 709ms

On voit dans ma trace que la connexion est très lente, mais elle tient le coup jusqu’à une interruption à la fin. La trace s’est effectué sur cinq minutes. L’architecture du réseau est basée par des routeurs wi-fi dans chaque wagon qui sont reliés à un backbone pour tout le train. Il y a un récepteur satellite qui reçoit des données d’internet et l’envoi est assuré par le réseau de Bell Mobilité (cellulaire).

J’ai demandé d’être compensé puisqu’ils n’ont pas été en mesure de fournir le service. J’ai eu aucune réponse à mon courriel envoyé le 11 novembre 2008 (ça fait 20 jours!). Je suis déçu que le service à la clientèle du service Internet n’égale pas du tout le service qu’on a en personne à bord du train. En faisait quelques recherches, il a plusieurs personnes qui ont vécu des expériences semblables. Ici, ici et ici. Disons qu’à l’avenir je vais surement m’abstenir de débourser 8,95$ par jour pour ce service qui en est pas un.