On 23/11/2020 18:50, Wallace wrote:

En dehors de ce problème légal, attention à l'utilisation des fonctionnalités avancées des clouds, il vaut mieux déployer ses propres instances avec les services que l'on veut et que l'on maîtrise plutôt que de s'enfermer dans une solution AAS et ne plus pouvoir bouger à moins de redévelopper les connecteurs API et souvent les applis.

Avec une solution maitrisée en interne tu peux rapidement réinstaller dans un autre cloud avec une simple migration dns et des données. Quand tu utilises la base de donnée managé, le load balancer, le ... ben t'es bien coincé.

Plutôt pour Frsag mais c'est intéressant.

En effet c'est une des grosses questions qu'il faut se poser quand on va dans l'un des trois gros cloud publique. Quel degré d'adhérence tolérer pour mon déploiement ?

D'un coté tu voudrais avoir le moins d'adhérence possible, donc en faisait du pur IaaS. D'un autre coté utiliser un cloud sans ses services managés c'est perdre une grande partie de son intérêt. Ce que je préconiserais c'est d'utiliser les services managés avec parcimonie, et de surtout regarder leur compatibilité.

Par exemple : LB , pas de problème il s'agit de reverse proxy https classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as plus intéressant, car utiliser un cloud publique sans utiliser son object storage c'est se passer d'une ressource plus qu'avantageuse. L'ennui c'est que S3 est devenu un standard de facto (voir Minio par exemple) mais pas disponible partout (notamment sur Azure). Résultat ma recommandation la dessus serait de l'utiliser mais avec une petite couche d'abstraction. Pour le reste des autres services types DynamoDB (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car c'est en effet trop se locker.

--

Raphael Mazelier




---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à