Avec le IaaS (Infrastructure as a Service), le datacenter est virtualisé et reproduit peu ou prou dans le nuage, tel qu'il existerait dans les murs de l'entreprise. En pratique, on loue des machines virtuelles, même si de nombreux services complémentaires viennent se greffer, comme l'équilibrage de charge ou la fourniture d'images prêtes à l'emploi (système, base de données et autres socles applicatifs). Les processus de déploiement ne changent pas : installation d'une base de données, d'un OS et des applications, puis création d'une machine virtuelle que l'on transfère ensuite vers le cloud.

Avec le PaaS (Platform as a Service), les couches systèmes sont entièrement masquées. L'entreprise ne voit qu'un vaste nuage partagé par tout le monde. De plus, des services mutualisés de stockage ou de bases de données sont proposés. Le déploiement est directement réalisé à partir de l'environnement de développement qui peut être en ligne mais qui peut aussi reposer sur une plate-forme standard comme Visual Studio ou Eclipse, complétée par un plug-in.

Avec le PaaS, l'administration des couches basses est entièrement prise en charge par le prestataire. L'entreprise réduit donc drastiquement ses coûts d'exploitation. La montée en charge peut également être automatisée. Le IaaS impose au contraire de gérer les mises à jour du système ou du moteur SQL, de prévoir une architecture permettant de répartir la charge sur plusieurs serveurs virtuels, puis d'augmenter leurs ressources ou les dupliquer en cas de montée en charge.

Les PaaS se démarquent des IaaS par l'intégration d'un processus bien balisé de gestion du cycle de vie incluant la recette, le test et la mise en production. Ce qui facilite la mise en œuvre du concept de devops (lire notre article : Des DSI plus agiles grâce au devops et au cloud http://www.indexel.net/management/des-dsi-plus-agiles-grace-au-devops-et-au-cloud-3810.html). Il existe toutefois plusieurs types de PaaS. Avec Microsoft Azure ou Google App Engine, la phase de développement reste assez classique. Avec Force.com en revanche, une interface utilisateur générique est fournie et peut être personnalisée. De plus, un catalogue de composants applicatifs est mis à disposition. Force.com privilégie en outre le paramétrage et la programmation par clics, plutôt que par codage (qui reste possible).

Le IaaS facilite la reprise d'applications existantes, surtout si elles sont déjà virtualisées. Hormis un travail sur la configuration réseau, l'effort de migration d'application x86 se résume au déplacement de machines virtuelles dans le cloud. En corollaire, la réversibilité est tout aussi simple. L'intégration avec le système d'information ne pose guère plus de difficultés puisque les mécanismes de communication entre applications ou de réplication de bases de données peuvent être conservés, à condition de tenir compte de la latence du réseau.

Avec le PaaS, une adaptation du code applicatif est nécessaire. Tout d'abord, l'accès aux bases de données est spécifique, sans être très différent. Par exemple, Azure SQL Database ne se comporte pas exactement comme SQL-Server. D'autre part, une requête ne doit pas s'exécuter dans un délai excédant 30 à 90 secondes (selon les PaaS). Il faut donc adapter ces requêtes et prévoir leur redémarrage en cas d'échec. L'intégration entre PaaS et système d'information interne n'est guère possible qu'au travers de mécanismes de haut niveau comme les services Web, ou par échange de fichiers. Certains PaaS proposent toutefois des fonctions de réplication asynchrone de bases de données.

Synonyme de reprise de l'existant, de réversibilité, de changement mineur dans les processus de développement et de déploiement, le IaaS reste privilégié par les DSI. Mais il s'agira probablement d'une étape permettant de réduire les risques, avant une évolution vers le PaaS, qui constituera un projet de migration à part entière.