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/
