Pour les équipes de développement et de production, le Paas "Platform as a Service" propose rapidité de mise œuvre et possibilité de monter en charge. Pourtant, choisir son fournisseur Cloud implique d'être vigilant sur les contraintes posées par certains services.

Choisir un service Paas, c'est bien évidemment comparer les prestations techniques offertes par chaque plateforme, calculer les coûts de fonctionnement en fonction du nombre d'utilisateurs ou des volumes de données attendus. Il ne faut surtout pas arrêter son choix sur ces seuls critères. Certains services Paas peuvent en effet être très compétitifs en termes de tarifs mais très limités sur certains points qui peuvent entrainer des surcouts non négligeables une fois l'application mise en production. De ce fait, le niveau d'automatisation d'une plateforme Paas est un point clé dans le TCO d'un projet Cloud.

Un Paas doit pouvoir être automatisé

Bien souvent, face au Paas, les équipes DevOps ont peur ne pouvoir atteindre le niveau d'automatisation qu'elles peuvent obtenir sur le Iaas où le contrôle sur les machines virtuelles est total. Alors qu'elles ont l'habitude de développer des scripts PowerShell pour déployer leurs applications, elles craignent de ne pouvoir faire de même sur un Paas. Il est indispensable de vérifier les capacités d'automatisation d'une plateforme via scripting, API ou un outil graphique avant d'opter pour tel ou tel fournisseur de Paas.

Autre point de vigilance à prendre en compte lors du choix d'un Paas, la personnalisation du service. Un catalogue de services trop restreint va imposer des contraintes bien trop restrictives aux architectes. Par exemple, un service Paas doit donner le choix dans les bases de données disponible et ne pas contraindre les développeurs à adapter les applications au seul SGBD disponible. La réflexion est la même sur les serveurs d'applications et les langages disponibles. En outre, il faut veiller à ce que ces choix puissent être réalisés via l'interface self-service du Paas et ne nécessitent pas une demande d'assistance spéciale qui va alourdir les tâches d'administration et les délais de mise en œuvre.

Attention au "vendor lock-in" !

Qu'elle soit on-premise ou dans le Cloud, une architecture informatique est amenée à évoluer dans le temps, tout comme la stratégie de l'entreprise. Certains DSI utilisent le Cloud comme un moyen de transformation de leur architecture technique et veulent conserver la possibilité de réinternaliser la plateforme de production sur un Cloud interne une fois cette transformation achevée. Encore faut-il que les applications puissent supporter une telle migration. Ce n'est pas toujours le cas, notamment lorsque celles-ci font appel à des services managés proposés par le fournisseur Cloud et dont il n'existe pas d'équivalent sur un Cloud interne.

Ce problème de portabilité devient aigu lorsqu'on souhaite changer de fournisseur Paas. Pour se ménager une telle possibilité, il faut privilégier les Paas qui se basent sur des briques logicielles standards et que l'on peut trouver sur des Paas concurrents. Tout au long du cycle de vie de l'application, il faut veiller à préserver son indépendance vis-à-vis des spécificités de la plateforme Paas. C'est le prix à payer pour une stratégie Paas gagnante sur le long terme.