Le 17/09/2021 à 07h 04

Why not

Le 29/05/2021 à 06h 50

Je trouve personnellement que c’est une super nouvelle pour les entreprises françaises qui travaillent avec des données “très” personnelles, comme les données de santé. J’ai en tête une startup qui n’avait pas pu profiter d’Azure à cause du Cloud Act, et même si des services français existent, on est encore loin de tous ce qui est proposé par Microsoft en termes de SaaS (ceci dit, c’est tout à fait normal, le nombre d’employés n’est pas le même, ce n’est même pas une question d’expertise technique de mon point de vue). Ca va réduire drastiquement les temps de mise en place d’une infrastructure et donc réduire les coûts pour toutes ces entreprises naissantes.

Ce n’est également pas nouveau pour Microsoft qui propose déjà ça pour l’Allemagne et la Chine entre autres, j’espère juste que ça ne mettra pas 10 ans à arriver…

Le 06/05/2021 à 05h 31

Bravo pour cet article qui arrive à expliquer un des enjeux de l’architecte cloud. Comme vous dites, on ne passe pas au cloud sans savoir ce qu’on fait ! La duplication des données et la présence d’un recovery plan est souvent délaissé par les clients car évidemment il est nécessaire de passer à la caisse… Pour des petites entreprises, cela peut parfois être catastrophique.

J’imagine qu’il existait déjà des solutions chez OVH à ce sujet (je ne connais pas suffisamment ce provider pour émettre un avis) mais tout ça est une bonne nouvelle. Beaucoup de clients français restent frileux à monter leur architecture chez Azure ou AWS, et OVH restera une belle option (est-ce qu’il existe un article sur le CloudAct chez NextImpact d’ailleurs ? Si non ça ferait un super sujet ^^).

Le 20/04/2021 à 17h 44

san a dit:

Vraie question pour ceux qui utiliseraient les deux logiciels : que peut-on faire dans VS que l’on ne peut faire sur VSC et son catalogue d’add-ons ? On lit un peu partout sur le net que VSC n’est “qu’un éditeur de texte”, mais ça me semble ajd très réducteur. On retrouve rarement sur un simple éditeur : un shell, une gestion de sources (git), un debugger, une gestion de compilateur/interpreteur, un pretty printer, une auto complétion et un lint pour à peu près n’importe quel langage, etc.

Tu as également toute la partie d’optimisation des performances avec le profiling, le debug est plus simple car très guidé, avec toujours plus d’infos (call stack, local watch etc.). Pour profiter de ces fonctionnalités intéressante il faut par contre passer à la version Pro ou Enterprise.

Je suis néanmoins passé côté jetbrains avec Rider et Webstorm qui semblent moins gourmants et plus rapides je trouve (sans compter l’intégration resharper, indispensable avec VS). VSCode je l’utilise pour le scripting genre powershell, ou les fichiers yaml pour les pipelines.

Le 09/04/2021 à 06h 39

cyp a dit:

Faux procès, OVH à quelques solutions et le fait qu’AWS soit en avance à ce niveau n’a pas empêché certains ENT hébergé dessus d’être indisponibles également. Le problème est probablement à chercher ailleurs, du coté des opérateurs/prestataires et des budgets. En particulier pour l’autoscaling il est probablement rendu plus compliqué par les budgets verrouillés qui sont souvent imposé dans le publique.

Yes tout est vrai dans ce que tu dis ! Je ne juge pas OVH c’est super d’avoir ça en France et mon commentaire était mal tourné. Je pensais peut être d’avantage au fait qu’il était beaucoup plus simple de mettre en place une solution scalable sur les services cloud comme Azure ou AWS (on est proche du cliquodrome aujourd’hui sans aucune ligne de commande à entrer). Et aussi au fait qu’on paye à la seconde pour certains services, ce qui permet de limiter la casse à la fin du mois (même si comme tu dis, on ne peut rien faire avec un budget bloqué).

(quote:1866019:Sylver—)
Mais faut arrêter d’imaginer que l’auto-scaling c’est magique hein :o Si lors du dev du projet on te demande de garantir X utilisateurs, rien ne dit qu’en mettant 2x plus de tout tu arriveras à tenir 2x utilisateurs… Donc 4x plus c’est une utopie. Ca peut passer… ou pas Faut prévoir PENDANT le projet que ça puisse scaler relativement “facilement” utiliser des technos qui scale facilement aussi. C’est vraiment pas juste “allez je double la RAM/CPU, c’est sûr ça passe”.

Par contre que ça n’ai pas été anticipé depuis 1an pour que la solution soit capable de gérer plus de connexion qu’en temps normal (ne serait que 50% donc), ça c’est une vraie erreur.

J’ai jamais dit une chose pareil enfin !!!! =) Mais là en parlant de millions d’utilisateurs sur une phase de temps si courte, peu importe l’optimisation de ton code et de ton architecture il faudra quoi qu’il arrive des serveurs supplémentaires pour supporter le surplus de connexion ! Ceci dit, si le système n’a pas été taillé pour comme tu dis, ça ne me choc pas spécialement qu’en un an ils n’aient pas pu tout arranger, parfois c’est plus compliqué que prévu si vraiment les bases n’étaient pas prévues pour… Et même si on a genre aucune infos “technique” sur le sujet, ils disent qu’ils ont été déçus par le résultat, c’est compliqué d’avoir bon du premier coup, c’est pas la première fois qu’un système tombe le premier jour. Le principal c’est que ça marche aujourd’hui. Si j’ai parlé du scaling automatique, c’est que si ça a remarché en quelques heures, c’est bien qu’ils ont du rajouter quelques serveurs “rapidement” ^^

Dj a dit:

Quand un fournisseur de solution achète un serveur et non pas une solution cloud, c’est pas de la faute d’OVH si le serveur n’arrive pas a tenir la charge car il est mal dimensionné. C’est au fournisseur d’avoir prévu d’autres serveur … Si t’arrive a 9h10 en mode “ah tiens, il faut un serveur en plus. Bon jean-mi commande s’en un vite et installe debian” t’es dans la merde

Ce que j’entendais c’est que justement avec les services de cloud comme Azure ou AWS tu ne parles pas “que” de serveur mais de services, qui peuvent être instanciés à la volée en quelques secondes, puis supprimés une fois la folie passée.

Le 08/04/2021 à 05h 33

Il faudrait qu’ils commencent à développer des solutions d’auto-scaling chez OVH. Bien sûr qu’on arrivera jamais au niveau d’AWS ou Azure, mais sans pouvoir fournir ce genre de prestation, et en voulant à tout pris utiliser des produits français, jamais un site internet lié au gouvernement ne tiendra une telle charge sans aucun problème.

Bon courage aux devs qui pensaient que ça allait tenir, c’est toujours une belle désillusion quand on ouvre les vannes, le sujet a toujours été très complexe.. !

Le 11/08/2020 à 08h 22

Je pense aussi qu’il existe une histoire d’évolution des compétences. Dans certaines entreprises dans lesquelles j’ai travaillé, certains admin sys étaient totalement réfractaires au serverless (et même au cloud en général). Evidemment, c’est un tout nouveau monde à appréhender, et se former n’est pas toujours simple quand on voit le nombre de ressources pouvant être créées chez Amazon ou Microsoft.
J’entends également souvent dire “le cloud, ça coûte trop cher”, pourtant, une fois bien utilisé et optimisé avec des politiques d’unscale automatique la nuit par exemple, on s’en sort beaucoup mieux.

Bref, la formation serverless / technologies cloud me parait indispensable aujourd’hui ^^

Le 11/08/2020 à 05h 29

NiKKrO_70 a dit:

Pas sûr que le sujet ai été abordé mais le Serverless avec AWS Lambda n’a pas vocation à fonctionner 24*7, les fonctions ont une timeout maximum. L’objectif est vraiment de donner un environnement d’exécution Python/Node/etc pour qu’on ne s’occupe plus que du code. L’idée étant de pouvoir faire l’interface avec d’autres APIs / services (S3/RDS par ex pour les données) pour construire ses propres briques.Le but final de AWS / Google / Microsoft étant de faire utiliser toute la panoplie de leurs services pour faire de l’argent

Je ne connais pas suffisamment AWS, mais chez Microsoft ils ont des Durable Functions qui permettent d’exécuter un workflow d’Azure Functions, pour un traitement qui du coup ne timeout plus car il est séparé entre plusieurs appels. C’est vraiment super intéressant et ça marche vraiment bien !