Basée sur Linux, Apache, MySQL et PHP, l’architecture LAMP propulse des millions de sites web. Mais est- elle en phase avec les futurs besoins des entreprises, à l’heure du big data ?
I – Les Atouts d’une infrastructure L.A.M.P. (Linux, Apache, MySQL, PHP)
Avant de voir s’il a atteint ses limites, ou s’il est dépassé, il faut revenir sur les bases qui ont fait le succès de LAMP. A la fin des 90, le modèle a été une révolution dans le monde des serveurs. Il prouvait sans contestation possible que des solutions open-sources pouvaient être aussi complètes que les solutions propriétaires et les concurrencer. Depuis, cette révolution est devenue un grand classique. Un classique qui n’a pas stagné. Bien au contraire. Chacune de ses couches a évolué et s’est améliorée au fil du temps grâce à des communautés très actives. Et même si de nouvelles questions pèsent sur ce modèle – notamment l’avenir de MySQL – il conserve à bien des égards de très nombreux atouts.
Le premier est d’être simple. Composé de quatre briques – Linux pour le noyau du serveur, sur lequel se greffe le serveur Web Apache, la base de données MySQL, le tout complété par du PHP/Python/Pearl – la stack est robuste, éprouvée, simple à mettre en place et a montré son efficacité.
Linux est né en 1991 des travaux d’un étudiant devenu célèbre : Linus Torvald. En le faisant passer sous licence GNU/GPL en 1992, Torvald donne un nouvel élan à son projet qui attire de très nombreux contributeurs. D’une ébauche de noyau, Linux devient un OS qui offre tous les avantages de l’open-source : gratuit, ouvert, modifiable et adaptable, évolutif, soutenu par une communauté… autant de caractéristiques qui assureront son succès auprès des Webmestres.
Mais se sont ses performances au sein de LAMP qui lui a permis de s’imposer face à UNIX, l’autre OS open-source. Un des éléments qui a su séduire est l’optimisation extrêmement poussée entre son Kernel det le serveur Web Apache. C’est par exemple au niveau du noyau que se gère la gestion de la concurrence (le dispatch des visiteurs en fonction de la charge de travail). Avec pour résultat des performances remarquables – voire inégalées.
Apache justement. D’après Netcraft, plus d’un serveur HTTP sur deux (58 %) est un serveur Apache. Un succès qui s’explique pêle-mêle par sa modularité, les nombreux langages qu’il est capable d’interpréter (Perl, PHP, Python et Ruby) et surtout ses grande possibilités de configuration.
Tout comme le Kernel Linux sont intimement liés, Apache et PHP forment un duo. le mod_php d’Apache est particulièrement rapide quand il s’agit de processer du PHP (plus que que PHP-CGI). Technologie phare sur le Web côté serveur, le langage PHP est à l’origine (en 1994) une bibliothèque logicielle en Perl créé par Rasmus Lerdorf pour enregistrer le nombre de visteurs ayant consulter son CV sur son site web.
Là encore, c’est la facilité qui en a assuré le succès. Peu typé, souple, pragmatique, le langage est simple à prendre en main. Son installation ne pose pas de problème. L’accès aux bases de données bénéficie de nombreux modules et ses fonctionnalités ne cessent de s’enrichir. Presque vingt ans plus le langage fait partie des incontournables indétrônables du Top 10 de l’Index TIOBE.
Ne restait plus qu’à trouver une base de données pour avoir une offre complète. PostgreSQL, plus ancien et lui aussi open-source, aurait pu remporter la partie. Mais c’est bien MySQL – crée en 1995 et dont le nom est un mélange de celui de la fille de son co-créateur Michael Widenius (My) et de SQL (Structured Query Language, son langage de requête) – qui est devenu le plus populaire.
Directement utilisable en production, avec des performances élevées en lecture, sans configuration particulière, multi-OS, multi-langage, multi-thread et multi-utilisateur, MySQL est aussi plus rapide sur les faibles volumes que PostGreSQL du fait qu’il n’effectue pas de tests d’intégrité. Depuis la version 3.23.15, MySQL permet également de gérer la réplication très facile à mettre en place (même si elle ne permet qu’une redondance limitée)… Seul défaut, bien que théoriquement non plafonné, MySQL devient moins performantes sur les gros volumes de données complexes, alors que PostgreSQL peut travailler avec des bases dde plusieurs Teras. Mais la simplicité était du côté de MySQL.
Au final, et en plus des atouts liés à chacune de ses briques, ce mariage des quatres technologies au sein de LAMP est bon marché. Il ne demande pas d’achat de licences particulières (toutes les briques sont gratuites – hors frais de support éventuel) ce qui en fait une alternative à faible coût comparé aux outils propriétaires. Bref, en 1998 – année ou pour la première fois le magasine allemand de référence C’t utilise cet acronyme – tout était en place pour l’émergence de cet ensemble alternatif, modulaire et flexible.
Autre point crucial, la stack est très facile à essayer. A l’opposé, les solutions de traitement intensif de données propriétaire comme HANA – celles qui pourraient rendre LAMP caduque – ont un coût non négligeable. Et pas de version Freemium pour les tester. SAP le sait et propose depuis peu sa base in-memory en mode Cloud après une certification sur AWS pour réduire les couts d’entrée (environ 4$ de l’heure). Mais un inconvénient persiste par rapport à une particularité de l’open-source qui a fait le succès de LAMP : HANA requiert des spécificités matérielles particulières. Il n’est toujours pas possible de la télécharger et de la tester telle quelle.
A supposer qu’une solution orientée Big Data soit plus en adéquation avec les besoins futures des entreprises, celle-ci ne pourra remplacer LAMP dans de nombreux projets qu’en respectant ces deux conditions : universalité du support et simplicité de mise en place. Or une telle solution n’existe pas… Sauf à faire évoluer LAMP ?
A l’usage, LAMP s’est en effet imposé par sa légèreté. Une légèreté que la concurrence (Windows Server / IIS / SQL Server / ASP.NET ou dans un univers JAVA du JBOSS ou du Tomcat) a souvent qualifié de “limite”. Mais au vue de la popularité actuelle de LAMP, celle-ci reste bien un atout.
Tout comme l’autre autre mot clef de LAMP : l’adaptabilité. Cette capacité à évoluer et à être « tout terrain » tient d’une part à la possibilité d’intégrer de nouvelles technologies dans le mix (PHP peut par exemple être remplacé par du Python ou du Perl et inversement) et d’autre part à des communautés très actives sur chaque brique.
Un simple exemple. LAMP est d’ores et déjà prêt à supporter les architectures ARM du simple fait que le noyau Linux l’est. Celles-ci ne sont pas encore très répandues dans le monde des serveurs mais la recherche continue de gains d’énergie dans les datacenters les rend de plus en populaires.
Les serveurs LAMP continuent d’ailleurs à s’adapter aux évolutions. Notamment au IAAS. Ou pour le dire de manière plus juste, la popularité actuelle du modèle a poussé les responsables des nouvelles offres Cloud à les rendre compatibles avec LAMP. Il est ainsi aujourd’hui parfaitement possible de mettre la stack entière sur une machine virtuelle sur Windows Azure ou AWS pour bénéficier de la scalabilité de ses solutions ET des avantages de LAMP.
Reste que – malgré cette adaptation au Cloud – l’accélération de la volumétrie des données à traiter pourrait tout de même donner un coup de vieux aux serveurs LAMP, peu adaptés originellement au Big Data. Une crainte renforcée par la consumérisation de l’IT qui semble se faire aussi sentir dans les technologies pour serveurs. Les entreprises veulent de plus en plus aller vers ce qu’il y a de plus simple avec des solutions « out of the box » qui n’ont plus besoins d’être déployées (comme SAP HANA One ou l’alliage HADOOP-SQL Azure sur Windows Azure), et dont les parties techniques et de maintenances sont externalisées.
Bref, « un clef en main » à l’opposé de l’esprit de LAMP qui est – pour le meilleur et pour le moins bon – le représentant parfait du « faites le vous-mêmes » pour garder la maîtrise de la technologie, de ses données et de la totalité de sa stratégie IT. Des atouts qui poussent de nombreux utilisateurs de solutions open-source à appeler de leur vœux un « LAMP-like » pour le Big Data : simple, robuste, ouvert, universel et standardisé.
