Si tu n'as pas besoin de scalabilité, de haute disponibilité, de clusters répartis dans plusieurs datacenters, d'API pour tout gérer comme du code (infra/réseau compris), de HSM, de IAAS ou de PAAS ou de SAAS ou les 3 (et d'autres *aaS d'ailleurs, cf Cloud_computing par exemple), de mutualiser fortement des coûts, de ressources élastiques, de facturation à l'usage ou d'avoir des clusters de tout type déjà disponibles (ElasticSearch, Kubernetes, MongoDB, MariaDB, etc.), ou si tu as un budget / des ops / des ressources infinies pour tout faire, alors tu peux te passer du cloud (ou faire ton cloud privé). La plupart des structures n'auront pas l'ensemble des compétences pour tout faire, ni le budget pour tout faire sans aucune mutualisation (parce que les clouds tirent les coûts vers le bas justement parce qu'ils ont énormément des clients), sans même parler de la dette technique de leur SI actuel qui peut aussi être un souci.
Donc soit tu te passes de ces fonctionnalités, soit tu fais du cloud public (utiliser les ordis d'un autre donc), soit tu fais du cloud privé (mais faut déjà être un peu gros).
Et oui il y a un côté auto-réalisation/amplificateur pour diverses raisons : les coûts baissent avec l'augmentation des utilisateurs, les retards pris deviennent durs à rattraper, les applis non-cloud sont délaissées/vieillissantes en interne et/ou sans API, etc.
Oui ça pose des problèmes de contrôle, d'indépendance, de données, etc. Oui, ça permet de faire des choses impossibles sinon. Non, ça ne devrait pas être utilisé dans toutes les situations (d'ailleurs y a des restrictions pour les données de santé par exemple). Oui, c'est très orienté optimisation capitaliste au final. Et non ce n'est pas du vent ni des fonctionnalités que tu avais avant en interne.
[^] # Re: Maintenant, c'est clair
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 8.
Si tu n'as pas besoin de scalabilité, de haute disponibilité, de clusters répartis dans plusieurs datacenters, d'API pour tout gérer comme du code (infra/réseau compris), de HSM, de IAAS ou de PAAS ou de SAAS ou les 3 (et d'autres *aaS d'ailleurs, cf Cloud_computing par exemple), de mutualiser fortement des coûts, de ressources élastiques, de facturation à l'usage ou d'avoir des clusters de tout type déjà disponibles (ElasticSearch, Kubernetes, MongoDB, MariaDB, etc.), ou si tu as un budget / des ops / des ressources infinies pour tout faire, alors tu peux te passer du cloud (ou faire ton cloud privé). La plupart des structures n'auront pas l'ensemble des compétences pour tout faire, ni le budget pour tout faire sans aucune mutualisation (parce que les clouds tirent les coûts vers le bas justement parce qu'ils ont énormément des clients), sans même parler de la dette technique de leur SI actuel qui peut aussi être un souci.
Donc soit tu te passes de ces fonctionnalités, soit tu fais du cloud public (utiliser les ordis d'un autre donc), soit tu fais du cloud privé (mais faut déjà être un peu gros).
Et oui il y a un côté auto-réalisation/amplificateur pour diverses raisons : les coûts baissent avec l'augmentation des utilisateurs, les retards pris deviennent durs à rattraper, les applis non-cloud sont délaissées/vieillissantes en interne et/ou sans API, etc.
Oui ça pose des problèmes de contrôle, d'indépendance, de données, etc. Oui, ça permet de faire des choses impossibles sinon. Non, ça ne devrait pas être utilisé dans toutes les situations (d'ailleurs y a des restrictions pour les données de santé par exemple). Oui, c'est très orienté optimisation capitaliste au final. Et non ce n'est pas du vent ni des fonctionnalités que tu avais avant en interne.