Cedric SADAI - Consulting en strat?gie Internet

Depuis hier, et la tenue à San Francisco du WWDC, tout l’écosystème Internet n’a d’yeux que pour le nouvel iPhone. Je ne pense pas que cette version soit une étape révolutionnaire pour l’évolution du téléphone, mais plutôt un palier nécessaire. En effet, les ingénieurs se sont appliqués à résoudre un certain nombre d’incohérences, qui, mises bout à bout, amènent presque à se demander si les premiers modèles n’avaient pas des carences volontaires, afin de pouvoir faire renouveller la même demande chaque année.

Des améliorations nécessaires

Ainsi, le dénommé 3GS (pour 3G Speed) a un nouveau processeur (et est donc plus rapide, indispensable et logique après 2 ans d’existence, mais pas une raison en soi d’upgrader), une nouvelle batterie (la dessus, il était temps de faire quelque chose. Mon iPhone n’a jamais tenu 24h sans recharge, même en airplane mode!), le copier coller et les MMS (c’est quand même des basiques, non?), la boussole (sympa mais pas révolutionnaire), et enfin, la caméra vidéo. La, ils pouvaient difficilement faire autrement, vu que les possesseurs d’iPhone jailbreakés en bénéficiaient déjà (ce qui laisse penser, encore une fois, que c’était un choix délibéré de ne pas l’embarqué dès la V1).

En bref, sur le volet iPhone, la stratégie d’Apple est limpide: créer un contenant superbe, technologiquement très avancé, et rendre la courbe de vente sinusoidale en créant des versions améliorées chaque année. C’est sûrement cette stratégie, et le talent avec lequel elle est marketée et communiquée qui est révolutionnaire, dans un secteur de la téléphonie où la demande s’affaisse naturellement dès qu’un nouveau produit sort sur le marché. Demandez à Ericsson ou Alcatel ce qu’ils en pensent..

Un nouveau SDK

L’autre pendant de la stratégie iPhone sont naturellement les applications, le contenu dans le contenant. Les applications sont à la fois garantes d’une marge immense pour Apple, de fidélité de la part de ses possesseurs (difficile de s’en passer), et d’un renouvellement matériel assuré car évidemment, Apple a également pensé à faire évoluer son SDK pour étendre à intervalle régulier le spectre de ce qu’il est possible de faire avec une application. Ces versions successives entraînent des nouvelles applications, donc des achats renouvelés. Exemple concret, dans l’iPhone 3GS, la boussole, qui ne chamboule pas notre vie de consommateur lambda, va permettre d’étendre les fonctionnalités du SDK pour permettre à une société comme TomTom d’avoir enfin son application de guidage routier. Résultat, entre un GPS à 300 euros ou une application TomTom dans mon iPhone à 1 ou 2 euros, je pense que le choix est vite fait. Il suffit de comprendre cela pour reconnaitre l’étendue du génie de Steve Jobs.

Nouvel OS, nouveau Macbook Pro

Mais au delà de l’iPhone, j’ai trouvé d’autres annonces très excitantes. Par exemple, Snow Leopard, la nouvel version de l’OS maison, OS X, va permettre de mieux exploiter les processeurs modernes, qui disposent très souvent de plusieurs coeurs. De plus, l’architecture répandue sur les Mac-Intel, de processeurs à 64 bits va également aboutir à des applications plus rapides. Et pour ne rien gâcher à la fête, le nouvel OS sera proposé à seulement 29 dollars / euros pour les possesseurs de Leopard. Tout le monde pourra donc bénéficier d’une expérience d’utilisation plus rapide, car les processeurs multi-core existent déjà depuis des années.

Enfin, un gros coup de coeur pour terminer. L’ordinateur que j’attendais depuis longtemps. Imaginez tous les avantages du Macbook Pro (processeur et carte graphiques plus puissants, batterie longue autonomie, slot pour cartes SD, clavier rétro-éclairé), sans les inconvénients (le prix prohibitif, la taille bien trop grande pour être pratique), et vous obtenez le nouveau Macbook Pro 13”. Il a la taille parfaite, des spécifications qui font rêver (à part cet écran brillant), et est disponible à partir de 1199 dollars (soit 860 euros si vous l’achetez aux US). Pour un ordinateur de ce calibre, ca devient extrêmement abordable, c’est LA bonne nouvelle du keynote à mon goût.

Je vous conseille d’ailleurs de prendre la version 2GB de RAM, et de compléter avec ce site: http://www.crucial.com/, l’upgrade vous coutera 50 euros pour passer à 4GB, au lieu de 300 euros à l’achat.

Lorsqu’on réalise un projet web d’envergure, il convient de prendre en compte les éléments annexes au développement: le référencement naturel (c’est le cas pour de plus en plus de développeur), et, chose moins commune, le déploiement et l’évolutivité de l’hébergement.

Si vous êtes sur financement, cette question pourra être rapidement éludée en passant par des prestataires à obligation de résultats, qui se chargeront pour vous de monter la meilleure architecture possible, quel qu’en soit le prix.

En revanche si vous êtes en auto-financement, les solutions techniques vous permettant de construire une architecture évolutive à moindre coût vous intéresseront. A notre sens, il convient ainsi de canaliser les goulets d’étranglement du serveur (généralement, la RAM, le processeur, et les écritures simultanées sur le disque dur, hors swap) en séparant les tâches sur des serveurs différents, ce qui permet de monter des système extensibles et légers.

Ainsi, un site avec du PHP extensif, comme une application sous symfony sera réparti ainsi:

- Un serveur avec pas mal de RAM pour servir le frontend. Sur ce serveur, une partie de la RAM doit être allouée à un accélérateur d’opcode type APC (512 Mo dédié parait pas mal). Cela permet de garder en cache une version précompilée de vos fichiers PHP, très utile quand on utilise un framework, puisqu’un framework procède à des inclusions en série de milliers de fichiers PHP, ce qui créé une brèche de rapidité automatiquement.

- Un serveur avec pas mal de RAM/proc pour la base de données. Idéalement, cette base de données ne remplit qu’un seul des deux rôles clés: soit elle lit, soit elle écrit. Si elle écrit, elle doit être couplée à une base “esclave”, elle même sur un serveur à part, avec encore moins de RAM. Si vous optez pour un tel système, sachez que cela implique pas mal de changement côté applicatif, puisque vous devez signaler à chaque action persistante la base de données à utiliser. Dans la théorie, des ORM avancés comme Doctrine et son fameux système de listeners permettent de faire cela. Dans la pratique, on a beaucoup de surprises.

- Un + qui fera toute la différence: si vous avez assez de RAM, et si vos serveurs de DB sont connectés à votre serveur de front en VLAN, profitez-en pour installer Memcache sur ce serveur, ouvrir le port adéquat, et stockez-y vos sessions utilisateurs. Memcache est infiniment plus rapide qu’un stockage sur disque dur, car les couples clés/valeurs sont stockés directement dans la mémoire vive.  Autre avantage, le fait d’avoir vos sessions stockées directement sur un serveur dédié à cette tâche rend votre serveur d’application encore plus indépendant, ce qui facilite, si besoin est, son extension par quelque méthode que ce soit (load balancing, failover heartbeat, round robin, etc…).

- Ensuite, nous vous recommandons de vous débarasser de la gestion des “assets” (éléments persistants uploadés par les administrateurs ou les utilisateurs, typiquement des images). En plus d’encombrer votre bande passante et de démultiplier vos lectures/écritures sur disque dur (ce qui augmente considérablement les risques de casse et pose le souci de la sauvegarde), vous rendez votre cluster de front plus difficile à mettre en place. En effet, pour que celui-ci soit efficace, il faut que chaque serveur contienne exactement la même chose. S’il existe des solutions de synchronisation comme rsync, ou mieux, unison, l’idéal est à notre sens de passer par un système de stockage tiers, comme Amazon S3 ou Mosso. Certes, l’implémentation côté applicatif sera plus complexe à gérer, mais vous vous débarrasserez des problèmes de sauvegarde, de sécurité, et surtout, vous allégerez considérablement votre/vos serveur(s)  applicatif(s).

- Pour finir, quelque chose de plus classique, débarrassez vous de la gestion des emails. Cela monopolise beaucoup de ressources (les AV et autres antispam sont TRES gourmands en RAM), et cela requiert énormément de maintenance pour conserver un système efficace. Optez pour une solution payante (vous transférez les MX et ne vous occupez plus de rien), ou optez au “pire” pour Google Apps qui vous permet également de faire ce genre de délocalisation, souvent pour le bonheur de vos utilisateurs.

Voilà, en ayant ce réflexe délocalisation, vous pouvez bâtir un serveur applicatif ultra light, extensible à l’infini, sécurisé à tous les niveaux (lancez un petit cron sur les serveurs de DB pour faire un dump et l’envoyer sur S3, ca prend 10 mn et 20mn pour faire le travail inverse), et très rapide à mettre en place. Côté installation, nous vous recommandons de travailler sur des box identiques, montées par exemple avec un Ubuntu LTS vide, et bloqués sur tous les ports qu’on utilisera pas avec iptable, ce qui rendra le tout encore plus sécurisé.

En conclusion, faire un système scalable, c’est également penser serveurs, et penser serveurs impose bien souvent de développer des spécificités au sein même de la couche applicative. Dans un prochain article, nous étudierons d’autres moyens d’accélérer l’exécution de son application.

L’iphone est ce genre d’objet qui regorge de petites astuces qu’on découvre à travers le temps et qui embellissent notre expérience utilisateur sur le long cours.

En voici une, découverte par hasard (et certainement connue de longue date des véritables nerds de la marque à la pomme), mais qui s’avère combler un handicap d’utilisation colossal sur la partie musique / iPod.

En effet, il est possible de retrouver ses controles de lecture d’un simple double-click sur le bouton principal, à partir de l’écran vérouillé. Cela évite de le dévérouiller, et de devoir rentrer dans la partie iPod pour enfin pouvoir interrompre la lecture, par exemple.

Voilà! Vous pouvez savourer ce magnifique morceau de Nina Simone, et bien d’autres encore, dans des conditions encore plus optimales.

Lorsque l’on construit une application professionnelle, on a généralement deux préoccupations: 1/ que l’application fonctionne, et 2/ qu’elle se comporte bien quelle que soit la masse de trafic supportée par le serveur.

Certes, la facilité consiste souvent à créer une infrastructure lourde, bardée de serveurs de tous types répartis par des load balancers. Mais malgré la chute sensible du prix de la bande passante et du stockage ces dernieres années, cela reste encore une solution réservée aux privilégiés. Comme dans la vie réelle, c’est dans les moments où les budgets sont les plus serrés qu’il faut faire preuve de malice.

Ainsi, la façon de programmer une application peut être entièrement pensée pour résister à la charge et aux pannes, tout en maintenant un budget d’exploitation modéré. Ainsi, pour répartir une charge ou basculer une application en cas de dysfonctionnement, il faut avoir au moins deux serveurs avec la même somme de données dessus. Pour ce faire, vous pouvez soit synchroniser vos serveurs par batch, ce qui pose un problème évident de resynchronisation après avoir basculé une première fois, soit construire votre application de manière décentralisée.

Une application décentralisée est une application où n’est physiquement stockée sur le serveur que la partie applicative du site. L’ensemble des données, media et base de données, devant idéalement être exclues de ce périmètre. Ainsi, on profitera des espaces de stockage en ligne comme Amazon S3 pour stocker de manière pérenne et sécurisée les données postées par les utilisateurs. Cela présente un double-avantage, puisque non seulement cela vous évite de mettre en place un système de sauvegarde régulière de ces données, mais en plus, cela permet de ne pas avoir à traiter cet énorme amont de GB lors d’un basculement de serveur. Même si NFS permet à plusieurs serveurs de partager le même accès disque, ce système ne garantit en rien la pérennité des données (à moins d’utiliser des disques en RAID5 hotplug, ce qui est assez cher), et surtout ne permet pas un déploiement aisé sur plusieurs datacenters différents.

La deuxième partie d’une application décentralisée est la base de données. Celle-ci doit être hautement protégée contre les failles, être naturellement préservée, et être facilement interchangeable en cas de défaillance. Un premier pas consiste donc à mettre en place la base de données sur un serveur séparé. Cela permet de préserver ces données clés en cas de panne du serveur d’application et de permettre ainsi à d’autres front de secours de s’y alimenter, et surtout de mieux répartir la mémoire et le processeur en séparant les utilisations. Ensuite, il parait important de répliquer ces bases, et donc de concevoir votre application pour traiter de manière différente les écritures et les lectures.

Le serveur maître, séparé de votre serveur front principal, prendra ainsi en charge les écritures (SELECT, DELETE et UPDATE) tandis que votre ou vos serveurs front, tous configurés de manière à répliquer automatiquement le serveur maître, se chargeront de lire les données (SELECT). Dans le cas où vous avez la chance de pouvoir vous procurer deux serveurs maîtres, vous pouvez répliquer les deux maîtres ensembles grâce à la réplication maître à maître (master to master replication).

Enfin, dans un internet de plus en plus décentralisé, à l’ère des webservices et de la flexibilité, il peut être fort à propos d’externaliser l’exécution de certaines tâches très gourmandes en processeur. Je pense notamment à la compression vidéo. Par expérience, nous pouvons dire que cela apporte beaucoup plus de probèmes que cela n’en résoud. La mise à jour des codecs, la charge extrême faite sur le processeur, la lourdeur globale de l’installation de la solution sur le serveur (d’autant que des distrib comme Ubuntu ne livrent pas ffmpeg natif avec la compression sonore) sont autant de gros inconvénients auxquels on ne pense pas forcément au début. A la place, une application décentralisée utilisera un des nombreux services d’encodage à distance, avec des vidéos compressées elles mêmes stockées sur S3 ou équivalent, puis mises en cache dans votre CDN préféré pour une livraison plus rapide à vos visiteurs.

En bref, la programmation orientée serveur est l’art de concevoir ses applications pour faciliter en aval la réplication des données, minimiser ainsi à la fois la charge moyenne et le temps de récupération après une panne.

Avec une telle infrastructure, 2 serveurs de front controlés par HeartBeat, un ou deux serveurs maîtres de base de données sauront vous faire approcher d’un taux intéressant d’uptime. En cas de forte charge, une telle architecture rend la scalabilité possible, en répliquant votre serveur sur le cloud, et en y installant directement l’image de vos serveurs de prod. Un travail qui s’apparente à une tannée lorsque votre appli n’est pas concue pour, et qui vous ouvre des horizons incroyables, comme jouer avec le nombre de serveurs ouverts en fonction de la charge subie par chacun d’entre eux. Ainsi, vous pourrez vous contenter de serveurs à faible mémoire RAM, l’espace disque ne sera plus une préoccupation, et la cadence du processeur aura une importance décroissante. Une solution qui, vous l’aurez compris, est donc très économique.

Jobeet est un tutorial en 24 parties, destiné à couvrir l’ensemble des fonctions offertes par le framework symfony dans le contexte de réalisation d’un projet réel. Alors que la série touche à sa fin, on peut faire quelques observations:

#1 L’ordre des cours

L’équipe symfony a choisi de partir du cahier des charges (sous formes de stories, respectant les principes de l’XP), pour ouvrir les hostilités par le design, juste après la conception du modèle de données, avant de s’attaquer en profondeur à la couche métier.

C’est précisément l’ordre par lequel nous avons également eu le moins de surprises. Juste après la conception de données, nous nous attardons même sur le conception visuelle de l’ensemble des parties où l’utilisateur peut entrer des données. Généralement, donc, le back office. En plus du design des formulaires (très utile pour repasser ensuite aux formulaires objets, faire les bons empilements de formulaires et développer les bons widgets), on peut également designer les différentes listes proposées à l’administrateur, ainsi que les interactions qu’il devrait être en mesure de faire à partir de là (et les implémenter basiquement, y compris l’éventuelle couche javascript).

Il s’agit en fait d’un bon moyen pour se rendre compte des éventuelles incohérences de conception, puisqu’en partant de toutes les possibilités d’entrées de données, il est facile d’adapter le modèle de données au mieux, l’affichage en front n’étant très souvent qu’une simple exploitation de données entrées par ailleurs (ou alors, si ce n’est pas le cas, il convient dinclure ces interactions utilisateurs en front dans ce prototypage graphique du début). Commencer par l’aspect visuel permet aussi de rapidement traduire vos scénarii d’utilisation en modules, actions, et routes correspondantes.

#2 L’importance des plugins

Nous avons beaucoup aimé le retour appuyé sur l’utilité des plugins. En effet, les plugins ne sont pas uniquement des packages publics prets à l’emploi. Ils sont aussi peut être le meilleur moyen de développer la véritable intelligence de votre projet. En effet, leur réutilisation est extrêmement simple, et se résume souvent à copier/coller un répertoire, qui lui reprend l’ensemble de votre travail.

Ainsi, dans les traitements de la couche modèle que nous faisons, nous travaillons par itérations succsessives:

1/ définition du comportement souhaité (exemple, un modèle Article doit etre taggé par un modèle Tag)

2/ qualification selon le critère “besoin ponctuel” ou “fonctionnalité réutilisable”. Si la fonctionnalité doit être réutilisée, soit sur un autre modèle du même projet (ex: modèle Video), soit sur un autre projet, nous pensons “plugin”.

3/ Comme nous travaillons désormais uniquement sur Doctrine, nous avons le bonheur d’utiliser très régulièrement les Templates, natifs à l’ORM. Pour chaque template que nous créons, nous créons un plugin correspondant.

4/ Si des interactions utilisateurs sont propres à cette fonctionnalité, nous les ajoutons au plugin. Par exemple dans notre cas, nous pouvons y intégrer une interface d’administration pour voir la liste des tags et en supprimer, ou encore un widget spécial qui étend une fonctionnalité jQuery qui va puiser dans notre liste de tags pour auto-alimenter un champs text avec suggestions AJAX (qui lui même pourrait étendre ce widget déja existant).

Ainsi, l’application pure de notre système se résume à définir le comportement dans le modèle de données (actAs: Taggable), puis de définir notre nouveau widget dans notre formulaire (sfForm::setWidget(‘field’ => myWidgetFormInputWhatever)). En bref, une fois que le plugin est développé, deux minutes de travail réutilisables sur tous nos modèles.

#3 L’ouverture sur le monde

Le move stratégique le plus intéressant de cette série de tutoriaux est d’avoir inscrit clairement symfony non comme une solution s’opposant aux autres offres du marché, mais comme une solution complémentaire, et en particulier un produit complémentaire du framework Zend.

C’est également une pratique que nous apprécions. En effet, de si nombreuses librairies ayant été développées pour Zend, qu’il serait contraire au principe DRY de vouloir réinventer la roue. De plus, symfony permet d’intégrer facilement n’importe quelle librairie externe. Zend_Rest, Zend_Gdata, Zend_Amf, Zend_Search_Lucene, et bien d’autres encore sont des librairies magnifiques tant elles vous font gagner du temps de développement.

En bref, ces tutoriaux nous ont fait découvrir le symfony que nous pratiquons et que nous aimons: une plateforme complète et fiable qui s’intègre avec toute l’intelligence créée par ailleurs, et qu’on peut vraiment développer de manière modulaire et incrémentale en réutilisant systématiquement chaque entité développée.

C’est en programmant de cette manière (avec des tests systématiques et complets) que l’ont peut beaucoup gagner en productivité, à mesure que l’expérience s’accumule.

Je suis content que Google Maps ait fini par couvrir le Maroc, où nous avons un bureau (à Rabat). En revanche côté précision, ce n’est pas encore tout à fait ca:

L’avenue de France semble allègrement empiéter sur les habitations des pauvres Rabati. Je vous rassure, dans la réalité, cela se passe très bien et elle est située bien sûr, au niveau de la grosse avenue juste au dessus sur la carte. Pareil pour l’avenue Oumeir, perpendiculaire à l’avenue de France. C’est en fait la grosse artère située à la droite de l’image.

En bref, méfiez vous si vous utilisez votre iPhone comme GPS au Maroc, car si vous avez déja la chance de trouver les noms des rues affichés (très rare), vous risquez quand même de vous perdre… à cause de Google!