C’est quoi la différence ?
Quand on décide de déployer son produit dans Azure, ici une API, on se retrouve face à un choix cornélien entre ces deux modes d’hébergement cloud. Avant toute chose il important de bien définir ces modes, et surtout de comprendre qu’ils ne sont pas en opposition et trouvent tous les deux leur utilité. .

La différence majeure entre Infrastructure asa Service (IaaS) et Platform as a Service (PaaS) est qu’en IaaS nous devons gérer la configuration logicielle alors qu’en PaaS cela se fait automatiquement en spécifiant la pile logicielle sur laquelle repose notre solution. Dans les deux modes d’hébergement, le hardware est à la charge du fournisseur de service (Azure, Aws, etc…). Le IaaS peut être vu comme une porte d’entrée dans le cloud, car il ne nécessite pas de modifier le code déployé pour la plateforme, il faut juste répliquer sa pile logicielle dans le cloud. L’applicatif peut ensuite être déployé tel quel, cette technique s’appelle le Lift & Shift. Le PaaS quant à lui demande un peu plus d’expérience sur la plateforme du fournisseur de cloud car il va tirer parti des différents services cloud du fournisseur à travers l’intégration de SDK spécifiques mais c’est aussi celui qui nécessite le moins d’efforts pour son maintien opérationnel (l’infrastructure étant la responsabilité de notre fournisseur de cloud).
Infrastructure as a Service dans Azure
Dans Azure il existe deux services principaux pour héberger une API en IaaS :
- Containers – Kubernetes
- Les Machines Virtuelles
La solution à base de container peut être intéressante dans le cadre où nous avons déjà de l’applicatif conteneurisée. Il est aussi relativement trivial de conteneuriser ses applicatifs hébergés on-premise. Dans la mesure où cela ne demande pas de modification de code, mais la création d’un fichier docker. Ce fichier « décrivant » la pile logicielle (ensemble des SDKs, runtimes nécessaire à l’exécution de cette brique applicative). La solution Kubernetes permet de centraliser la gestion des ressources matérielles nécessaires à l’exécution des conteneurs Docker et les interconnections entres les images docker déployées.
Nous allons ici nous concentrer sur le déploiement d’une machine virtuelle, dans la mesure où c’est la solution la plus souple et facile à mettre en place lorsque l’on désire migrer rapidement et sans de large surcoût ses applicatifs on-premisedans le cloud. Pour cela rien de plus simple, le déploiement d’une nouvelle VM se fait très rapidement. Dans un premier temps il faut définir l’image à utiliser pour l’OS ainsi que les ressources matérielles allouées.

Nous devons ensuite créer un compte Administrateur pour cette machine. Il est très fortement recommandé d’utiliser des clés SSH plutôt que le classique mot de passe pour sécuriser l’accès à ce compte. Par la suite il nous est demandé d’attacher un disque de stockage ou d’en créer un, vous pouvez bien entendu partager ce disque entre plusieurs VM. A noter que l’OS est bien entendu installé sur un disque séparé, qui est totalement géré par Azure.

Nous pouvons maintenant passer à la partie réseau. Les machines virtuelles Azure doivent être intégrées au sein d’un réseau virtuel. Cela revient à leur attribuer une carte réseau virtuelle. L’adresse IP associée à cette carte peut être publique ou alors uniquement accessible au sein d’un réseau privé (c’est la solution à privilégier). Il faut ensuite gérer comme sur une machine on-premise les ouvertures de port et éventuelles redirections de trafic afin que notre service soit disponible sur l’internet publique. Il est toujours bon de rappeler que nous exposons uniquement le strict nécessaire aux réseaux publiques, afin de limiter la surface d’attaque.

L’onglet suivant, dans la création d’une VM : Management, permet de configurer la récupération de télémétrie sur l’usage de la machine virtuelle. Le tout pour assurer avec efficacité et réactivité la disponibilité et le bon fonctionnement de notre machine virtuelle. Il est important de ne surtout pas négliger cette partie collecte d’info afin de pouvoir réagir si notre machine virtuelle est en souffrance. Nous avons bien entendu la possibilité de faire du load balancing avec des VMs Azure afin d’assurer une disponibilité optimale de notre service.
Une fois la machine virtuelle déployée (cela prend en général quelques minutes) vu que nous somme en IaaS, il nous faut encore installer les prérequis logiciels de notre API. Typiquement nous pourrions nous connecter en SSH avec le compte administrateur que nous avons créé et lancer l’installation d’un serveur web.
ssh azureuser@publicIpAddress sudo apt-get -y update sudo apt-get -y install nginx
Notre VM est maintenant prête à accueillir notre API, nous avons configuré la pile matérielle ainsi que la pile logicielle. Le maintien opérationnel de ces 2 stacks est à notre charge. Il existe aussi des moyens plus rapides pour définir ces machines virtuelles notamment si nous avons déjà ces machines on-premise. Microsoft propose différents modes de migration pour des VMs on-premises. Mais si vous ne souhaitez pas gérer la machine virtuelle, c-à-d les mises à jours logicielles et le serveur web installé sur la VM, vous pouvez vous orienter vers les services de types PaaS.
Platform as a service dans Azure
Sur les services de type PaaS dans Azure pour héberger une API nous pouvons aussi en isoler deux principaux :
- App Services
- Azure Functions
Une des différences majeures vient de par le mode de facturation : les Azure Functions sont facturées à l’utilisation. Elles ne sont activées que lorsqu’elles doivent gérer une requête HTTP (ou d’autres types de déclencheurs). Tandis que les App Services sont facturés dès la création de ceux-ci en fonction de la puissance allouée. Cependant les Azure Functions nécessitent l’utilisation d’un SDK spécifique (disponible dans de multiples langages) et sont plus adaptées à une architecture orientée microservices. Cela est rarement le cas lorsque l’on décide de migrer sur le cloud. Pour initier une transition vers le cloud le choix de l’App Services permettra de déployer son API plus rapidement. En effet il n’est pas nécessaire de réécrire le code de son API pour la déployer dans un App Service. Azure App Services supporte .NET Core, ASP .NET mais aussi Java, node, etc…
Nous allons créer un App Service pour héberger une API .NET Core cela se fait en quelques étapes. Contrairement aux VMs Azure le choix de la configuration matérielle se résume à la sélection d’un niveau de puissance allouée. Il est important de bien déterminer la puissance nécessaire pour assure la charge de son API.

Il nous suffit maintenant de configurer du monitoring afin d’assurer le suivi opérationnel de notre API. C’est une étape très importante souvent négligé mais qui permet d’être proactif et de réagir rapidement à d’éventuels soucis logiciels. Avec les App Services, un service est mis à disposition afin d’assurer cela. C’est Azure App Insights qui va récolter des télémétries de base de notre API. Ce service peut aussi agréger les logs émis par notre API.

Notre App Service est dorénavant configurée. Il suffit de valider et il sera déployé dans le cloud. Une fois cela fait, nous pouvons déployer notre API directement sur ce service. Il prend en charge différent mode de déploiement en passant du simple package zip à du Github ou bien sûr Azure Dev Ops. Nous voyons donc qu’il est très rapide de déployer une API avec les App Services, c’est donc un très bon moyen de rentrer progressivement dans le cloud. Le tout en minimisant les coûts liées à l’infrastructure et à d’éventuels modification du code afin de le rendre opérationnel dans le cloud. Il est par la suite envisageable de migrer progressivement vers des Azure Functions en isolant des fonctionnalités de notre API. Cela permet de s’orienter petit à petit vers une architecture microservices si cela est bénéfique à notre applicatif bien sûr. Mais isoler certaines parties de notre applicatif dans des Azure Functions permet d’optimiser la facture globale de notre applicatif si cela est bien fait.
Le mot de la fin
Nous avons parcouru ensemble les principales différences entre les services cloud dit « IaaS » et les services « PaaS ». Ils ne sont pas du tout en opposition et le premier peut être un premier point d’entrée dans le cloud pour migrer ses applicatifs sans en modifier le code. Tandis que le deuxième peut être vu comme une seconde étape, la réécriture des applicatifs pour le cloud, dans le cadre d’une migration dans le cloud ou tout simplement pour les futurs services qui seront ajoutés à notre application. Les solutions IaaS et PaaS peuvent totalement cohabiter au sein d’un applicatif cloud découpé en plusieurs briques. Quoi qu’il en soit ces deux modes d’hébergement dans le cloud sont très faciles à mettre en place. Nous avons vu ensemble comment déployer ces solutions en quelques clics mais il reste une partie souvent négligée mais cruciale : la sécurisation de son applicatif cloud. La prochaine étape et de sécuriser ces ressources. Vous pouvez retrouver nos conseils pour aborder la sécurité dans le cloud dans notre livre blanc.
Pour aller plus loin
Découvrez notre dernier Livre Blanc qui vous expliquera comment comment exposer de manière fiable et sécurisée votre application dans le Cloud.
0 commentaires