Reprise du message précédent :
Il suffit de dimensionner le resal en conséquence

C'est à l'image des décisions techniques prises  
Ça a déjà survécu a une migration hébergeur => hébergeur   ça survivra bien à une migration supplémentaire vers AWS.
Pour améliorer les choses, comme on est en techno super-agile de devops from hell, j'ai appris hier qu'on ne remplacerait plus les pilotes (dont le taux de turn-over est largement supérieur à l'inflation vénézuélienne) partant, car notre méthodologie elle est tellement bien qu'ils sont devenus obsolètes  
A+,

 
ba oui, architecture micro-services avec des éléments pour chacun des services ...
Après en soi, je ne vois pas le soucis à partir du moment où les technos sont maitrisées et nécessaires.
 
ces stacks ne me paraissent pas abérrantes
rabbitmq : files de message, c'est quand même bien pratique et c'est bon d'en revoir maintenant.
MariaDB : ouf une sgbd
greylog : pour porter les logs
 
manque toute la part compute (genre ecs ou EB voire lambda, voire vraiment au pire de l'ec2 mais c'est con de faire de la vm IaaS) et stockage (s3 powa)
 
mongodb : nosql, faudrait déjà justifier du besoin vs une bonne sgbd classique
MarkLogic : connait pas mais le googling fait peur (faire du big data en NoSql, youhou)
HazelCast : connait pas, idem le googling fait peur
 
j'imagine que ça répond à un besoin très spécifique.
 
 

 
Clairement, ça dépend.
 
Ayant appris sur AWS et faisant maintenant du Azure, je peux expliquer.
 
Tu veux que je détaille/développe ? (question sérieuse, je peux, même si je ne maitrise pas tous les services de chacun)

 
en 2h t'as à peine le temps d'avoir un aperçu du mode de facturation

Et les 2h d’après tu te tapes « IAM »

Bah disons que sur 3 fournisseurs majeurs de cloud tu as :
- une boîte de retail
- une boîte de pub
- une boîte d'ingénierie logicielle
Tu prends qui ?
Mon choix est vite fait  

Si seulement. A la base, on n'avait besoin que de MarkLogic (pour sa capacité xml/xsl/xquery. Si tu fais de la doc dans le monde de l'édition technique ou spécialisée, cette BDDD n'a pas vraiment de concurrent et fait le taff, mais comme elle a un semi-monopole, elle applique une politique tarifaire qui rappelle assez bien celle d'Oracle ) + un excellent indexeur + un peu de MariaDB, et pas besoin de mongodb mais ce dernier était à la mode aux échelons décisionnels... On a un maintenant système ou certaines transactions permettent le rollback mais pas d'autres je te dis pas comment ça reste cohérent.
Malgré tout ça, au bout de 2 ans, ça commence a être utilisable par les users, et dans deux ou trois ans, ça devrait être achevé.
 
En tout cas, pour en revenir à la question initiale, il aura fallu moins de 3 mois a une petite équipe (entre 5 et 10) pour avoir une migration démontrable dans AWS (sachant que leur lead s'était fait la main le trimestre précédent en le portant le bouzin dans un environnement Kubernetes et containers, dans un cluster de quelques Lenovos que je voyais depuis mon bureau).
 
A+,

Et déprécié quelques mois après

Icite, les trucs qui marchotent, on les garde le plus longtemps possible, car une fois que leur procédures d'utilisation sont connues, le management peut établir de manière précise le temps nécessaire a telle ou telle production, et ça c'est un critère auquel ils sont très attachés.
Changer de process, c'est entrer dans une zone floue de délais de production pendant quelques mois, pendant lesquels on ne peut pas être certain que telle offre pourra être proposée ou non à la clientèle lors des salons professionnels annuels, bref c'est le truc    
De toute façon, ça pourra pas être pire que ce que ça a déjà remplacé pour un produit, qui, dans son incarnation précédente nécessitait une config à 98 coeurs et 128 Go de mémoire pour s'exécuter dans des délais raisonnables (de qques heures).
 
A+,

 
ce qui est assez terrible à dire c'est que :
- gcp, faut globalement oublier, c'est du roots de pf k8s avec des composants développés pour le machine learning. le reste, c'est franchement réduit.
 
- aws, construit au départ pour les besoins d'amazon, a une philo et une logique orientée infra. C'est très bon et les services se montent au fur et à mesure dessus.  
(c'est pas pour rien qu'ils sont largement leader)
Pour de l'infra/compute/stockage, c'est excellent. Pour le workspace et autre, très mauvais
 
- azure a été construit en // entre des services workspace (o365) et pass publiques. ça manque d'une logique infra et les service endpoint ne suffisent pas réellement.
Donc côté sécurité infra classique, c'est putain de léger voire clairement insuffisant.
On retrouve bcp des services d'aws, tant IaaS/PaaS/Saas.
Par contre, on traine des choix d'architecture qui forcent à utiliser certains services (notamment l'azure AD).
Et c'est moins ergonomique.
Par contre, c'est de loin le plus polyvalent des clouds et vous pourrez bouffer du windows/linux très facilement.
Leurs composants saas (dont IoT) sont aussi simples et rapides à mettre en oeuvre tant qu'on suit leur philosophie.
 
Par contre, c'est compliqué pour trouver des compétences dessus par rapport à AWS notamment.
 
Car oui, malheureusement, autant les sysadmin linux ont pris le pas du cloud et donc gcp/aws (mais ne vont pas naturellement choisir azure),
Autant les sysadmin windows ont pris du o365 pour remplacer office mais ne sont que peu investis dans Azure.
 
 

On doit pas voir les mêmes clients alors. Plus de la moitié des machines dans azure sont sur Linux (info publique) et la plupart de ceux qui me parlent d'azure sont pas les admins Windows mais les devs(ops) peu importe la plate-forme ou langage.
Azure à la base c'est du service paas qui s'est mis à faire du iaas à l'inverse de aws et c'est la ou est la vrai valeur (le paas).
Azure Ad est en phase de faire comme son ancêtre l'ad un boom (a cause de 365 tt le monde a un azure ad et est donc prêt à consommer de l'azure).
Gcp c'est très bien pour du big data/ML.

Chez nous on a les deux. Selon ce qu'on veut faire on utilise aussi bien Azure qu' AWS.
Je confirme pour Azure AD, c'est le next big thing.
 
Par contre, wé, encore une fois, chez Google y'a rien à voir

 
ça ne remet pas en cause ce que j'ai dis.
"la plupart de ceux qui me parlent d'azure sont pas les admins Windows mais les devs(ops) peu importe la plate-forme ou langage."
C'est bien ce que je dis.
 
En %, j'ai pu voir beaucoup plus de profils admin linux aller vers le devops que de profils admin windows, qui eux se dirigent vers o365 (en remplacement des exchange/sharepoint/skype).
 
C'est maintenant que la mouvance est bien installée que les admins windows vont vers Azure et ses composants.
 
Ce qui explique que AWS soit devenu leader au début et qu'Azure rattrape son retard maintenant.
 
Peut-être parce que justement, Azure=o365 a surement donner une 1ere impression qu'avec le cloud, l'admin fait pratiquement plus rien.
Alors qu'avec la vision infra côté aws, ba tu te rends bien compte qu'un cloud / vmware / openstack / ... c'est finalement la même problématique : gestion d'accès, gestion réseau, fournir de la puissance & du stockage pour des plateformes applicatives, gérer les inventaire/patch/livraisons/monitoring/... qui sont toujours là.  
 
Donc tu y va sans avoir l'impression que tu va perdre ton job à terme parce que "tout est dans le cloud". (ce qui est complètement faux par ailleurs, le hosting n'est jamais autant complexe que maintenant qu'on a autant de choix possibles différents)
 

GCP, c'est bien pour faire du LAB en fait!!

essaye de faire un chmod +x sur le .exe et de le run on sait jamais sur un malentendu...
 

En toute objectivité AWS

Potential over engineering spotted mais pas choquant
Par contre, pourquoi continuer de maintenir certaines briques quand ces dernières sont consommables via un service AWS ?

Je vois pas de quoi tu parles

J'ai ri. J'avoue que le billing est un service à part entière qu'il faut maîtriser

Et tout le monde devrait commencer par maîtriser SCP/IAM

C'est absoluement pas réducteur.

Précise ce que tu entends par workspace et autre, ca m'intéresse.
Si on parle d'application user facing, à la limite...
Si on parle d'infrastructure pour supporter les environnement par contre...

Je vois pas ou le bas blesse sur les services AppStream ou Workspaces par exemple
A la limite je peux comprendre pour Amazon Workmail, c'est assurément pas O365 mais ça tourne et couvre surement la plupart des besoins
Et je préfère Chime à S4B à titre perso.

AWS Directory Service for Microsoft AD ?

Je constate d'ailleurs un biais des ops qui font du MS et qui vont naturellement essayer de s'orienter sur de l'Azure pour je ne sais quelle raison sans même regarder ce qu'il se fait à côté.

 
A rediscuter mais oui, c'est le cloud dont l'approche est la plus facile et simple pour ceux venant de l'infra traditionnelle.
La construction des plateformes se fait de la même façon.
 

 
Soit par méconnaissance, soit parce que ce sont des briques AWS déjà et que ça tourne tout seul.
 

 
J'ai dû commencer AWS par l'aspect billing ... comment je me suis vautré les premières fois     (et sans formation préalable).
 
Et c'est triste de voir les formations "officielles" : des pans sont complètement oubliés.
Étrangement, ce sont ces pans qui aident à réduire la facture globale    
 

 
J'ai oublié le mot "office" mais c'est bien ça, les workmail et cie, bref l'équivalent d'o365, nettement plus abouti.
 
AWS Workspace, c'est du VDI donc de l'infra ... donc ça tourne bien ^^
 

 
AWS DS, c'est un ec2 avec un windows server avec AD, c'est d'ailleurs très pratique vu qu'ils intègrent les CAL à chaque fois dans le coût mensuel.
A côté Azure AD, c'est une brique étrange et fondamentale, beaucoup plus chiante (parce que y'a pas de Domain Service notamment et qu'il vaut mieux en déployer un en IaaS Marketplace Windows Server plutôt qu'utiliser le Amazon AD DS).
 
Mais Azure AD gagne sur la gestion du IAM des PaaS, très simple par les app registrations.
C'est très facile à utiliser et bien plus rapide pour une mise en place d'infra serverless.

J'aime bien la console Azure, la possibilité de dialoguer avec ton infra depuis l'interface web.  
J'aime bien aussi les acces faciles aux VMs.  
 
leur politique de prix est en revanche louche. Et la securité de base inexistante. Alors que sur AWS on ferme tout par defaut et on ouvre ensuite.  
 
question services ils se tirent la bourre des qu'un truc sort d'un coté l'autre s'empresse de le mettre

 
Pourquoi tu dis que Azure = Office 365 ? Ca n'a rien à voir sauf la brique Azure AD qui est commun aux 2.
Les admins windows qui font de la messagerie oui se tournent vers 365 mais les admins serveurs, infra etc. n'en n'ont que faire. Ils font de l'Azure/AWS/etc.
Le cloud MS c'est pas que Office 365 et Azure mais Office 365/EMS (Intune, Autopilot etc.)/Dynamics 365/Power BI pour la partie SaaS et Azure pour IaaS/PaaS
 

 
Rien à voir, Azure AD n'a d'AD que le nom, en pratique ça n'a rien à voir. Ce qui s'en rapprocherait le plus serait Azure AD Directory Service mais c'est plus une verrue qu'autre chose.
La raison est simple, ils ont déjà un contrat avec MS via un EA, tu peux réutiliser tes licences windows server dans azure bref ça coute moins cher.
 

 
Politique de prix louche ?    
Sécurité de base inexistante ?

tout comme Je@nb
 
Par contre je me garderais bien de comparer avec AWS, j'y ai jamais mis le nez.

Soft codé en mode Frankenstein  
Un bout de truc ici , un reste récupéré par la, un cadavre pas trop faisandé comme structure, des grosses sutures degeu pour les jointures et on espère que ça marche  

On avait testé * , on gratte a peine 1% de perf sur le réseau donc c'est pas rentable vu le temps de développement

* En 1996 sur du réseau 10mb/s avec des hubs

/ et je rigole même pas en racontant ca  

Si tu fais du CQRS t'arrives assez facilement à un ensemble de composants similaire, rien de bien choquant. Ici j'ai Cassandra, Blazegraph, Elasticsearch, Redis, et on vient de virer Kafka et Zookeeper pour une solution de communication intra-services un peu plus ad-hoc à base de server sent events.

 
Tiens, la liste, c'est plus rapide
https://azure.microsoft.com/fr-fr/solutions/
https://azure.microsoft.com/fr-fr/services/
 
Mais même si le cloud MS est vaste et qu'on sait tous les deux séparer o365 des souscriptions Azure, dans l'esprit des gens, c'est compliqué.
 
Ce que je veux dire, c'est que, contrairement à AWS qui a eu l'image "VM dans le cloud" directement, Azure a eu en 1ère image (fausse) de "office/exchange/skype dans le cloud".
Donc des admins windows que j'ai pu cotoyer, peu voyaient en Azure un cloud pour déployer de l'infrastructure.
D'autant que, pour eux, le devops était encore très loin : la maturité de l'automatisation pour le déploiement/configuration système & l'infra-as-a-code vient du monde linux, pas du monde windows.
 
Donc passer de "on déploie des VM/applications" à la main, à partir de procédures écrites" à "on SCRIPTE dans un cloud avec des outils d'automatisation", ça a fait une énorme marche à franchir.
 
Pendant ce temps, côté linux, on n'a pas hésité à y aller, avec au choix aws, gcp ou azure.
Par contre, une fois o365 déployé, tu as un effet "WOW mais c'est quoi tous ces services ?" qui fait que ces mêmes admins commencent à déployer dans Azure.
 
Ce qui explique que :
1/ gcp est plus implanté coté étudiant/startup mais peu dans un environnement de SI de production ancien.
2/ aws est largement leader, devant les autres
3/ azure rattrape son retard sur aws, particulièrement dans les envs de SI de production ancien majoritairement sous windows (ce qui est le cas de pas mal de boites).
 
 

 
Politique de prix, comme AWS, c'est un peu merdique pour savoir exactement combien ça va te coûter.
Le problème de l'elasticité et du pay-as-you-consume.
 
Sécurité de base pas inexistante mais clairement faible.
Par défaut, tout composant est créé en public, accessible par un cname.
Ensuite ils ont inventé les service endpoint pour les rendre privé ... mais puré que c'est horriblement con et chiant à gérer.
 
Et comme ça n'est pas une vraie carte réseau, certains services ne peuvent pas se voir par le service endpoint et il faut activer la case [] Allow All Azure services to access.
Ce qui autorise TOUS les services Azure de joindre le composant, pas uniquement ceux de ta souscription ...
 
T'as intérêt à pas te chier dans ton IAM, c'est ton seul truc qui t'autorise à sécuriser un minimum.
Et donc un login/pwd perdu avec qqs privilèges, hop, tu as accès de n'importe où.
 
Au hasard, par exemple, oublier de désactiver avec un peu de retard un accès privilégié à un dev et il pourra tout downloader de chez lui, tranquillement.

Et pourtant chez eux c'est super simple, tu appelles le 706, tu fournis ton numéro de compte et ton numéro de bon de livraison qui était avec ta carte SIM et ensuite ils vont te donner ton numéro de téléphone.
Ta carte SIM sera alors activée.
sinon oui l'activation par le portail web n'est pas vraiment fonctionnelle. Perso une fois sur deux je ne vois pas non plus mes dernières cartes SIM commandées.
Donc je ne m'embête plus et le fais directement via le 706....

Ah le fameux réseau de XaT

Installer du node.js et faire du git. bordel je suis vraiment dépassé sur plein de technos récentes

Tu es devenu un dev  

c'était le must du must

Non non je dois faire de ca pour "industrialiser" et mettre au propre certains dev.  

In before the docker Je viens de me retrouver dans la même position actuellement, j'installe des nginx/php, je mets à jour du soft à coup de git, on a tenté de me forcer à utiliser du docker pour un cas qui ne s'y prête pas tellement, j'ai su rester fort pour ne pas compliquer inutilement le truc Dans l'absolu ça marche, c'est simplement pas mon dada  
J'ai peur de faire un peu du #devops car je coordonne autant l'opérationnel que les discussions avec les devs du fournisseur Yavait d'ailleurs "big data" mentionné dans la dernière présentation de ce fournisseur, ça m'a fait loler en repensant à devops_borat https://twitter.com/devops_borat

Docker est assez fortement verboten. Pour le moment.
Ce qui veut dire que le mois prochain j'en installe probablement.

Et borat dev . Utiliser des technos de l'an 3000 pas fiable et pas abouti qu'on pige que dalle  

In startup we are apply strategy of one size fail all.  
 
Et pour ref à je sais plus qui à propos d'IBM "nobody ever got fired for buying IBM" :  
In devops nobody is get fire for buy open source.

https://twitter.com/BigDataBorat
Big data  
Grande nation  

Je connaissais pas celui-là

 
J'ai jamais vu qui que ce soit penser que Azure = office/exchange/skype dans le cloud. Ca a toujours été clair pour tous ceux que j'ai rencontré que c'était office 365.
 

En PaaS c'est vrai certains services écoutent sur Internet par défaut mais ça veut pas dire que tout le monde a accès à tes données. Ton storage account n'est pas public par défaut, ta base SQL est protégée aussi. Tu as la possibilité d'avoir des webapp en privée, ton api management en privé et plein d'autres.
En IaaS, tu crées une VM par défaut elle n'est pas du tout accessible de l'extérieur (par le portail, en ps/cli/arm/terraform c'est encore moins vrai vu qu'il faut créer les ressources explicitement)

J'faisait du NodeJS avant de sortir de l'école
Bon, c'était y'a pas si longtemps remarquez

 
 
heureusement que tu as passé des concours pour arrêter l'informatique  

Tellement vrai  Bon on peut dire qu'on reste 107 ans en arrière

Oui, enfin bon, en tant que développeur, je chercherais un boulot, une boîte qui n'utiliserait pas git, ce serait un niet ferme et définitif (a moins d'un zéro supplémentaire au salaire mensuel proposé ).
On peut accepter de bosser dans de mauvaises conditions, mais il y a des limites.
A+,

Et puis bon, ce serais pas plus mal que les admin système et réseau en tout genre se mettre a git : scripts, fichiers de conf... Et avec les outils de configuration as code/infra as code ils finiront par ne pas avoir le choix