Reprise du message précédent :
ça a l'air chiant

mais ça paye

ah bon bah on signe où ?

Chez Broadcom, suis un peu bordayl  

Je suis une feignasse hein, je signe les papiers directement.
Je vais pas non plus entamer des process de recrutement. C'est pas payé.

Sinon XaT ça se passe toujours bien ton taf à la mine de lignite?

Oui full télétravail, ils sont cons dans cette mine

Ça l'est devenu... no joke.
 
Heureusement que j'ai certains clients encore techniques avec qui on peut vraiment parler vrai

J'espère que tu palpe T'es toujours en IE ?

Bah je palpe plus que quand j'étais junior en ESN (no shit proof )
 
Et non, de retour en France depuis 2019

MP j'ai pas officiellement de poste ouvert (on a fait 20+ recrutements en moins de 2 ans donc on digère un peu) MAIS toujours intéressé pour regarder ton xp et ton profil pour décider de faire un truc sur mesure si ça a du sens pour nous

Edit : et sache que j'ai beaucoup de respect pour le produit et les équipes de vmware, je sais très bien qui sont les enculés qui prennent ces décisions, je "côtoie" ton ancien CEO qui est a la tete de CSG aujourd'hui.

Bah je trouve plutôt cool de potentiellement avoir une occaz de bosser avec un Hfrien de plus (je sais pas combien on est chez Vates d'ici mais au moins une demi douzaine )

Entre la gloubicorp et toi, en fait le topik est tenu par 2/3 COGIP
On est minimum 4 (enfin j'en connais 4, mais je sais qu'il y en a plus) de la mienne sur ce topik, plus un ancien presta.

Juste par curiosité, vous voyez comment le développement des micro services ?

Dans la tendance actuelle, j'ai l'impression que le fait de pouvoir déployer des containers en trois clics et de faire de l'infra as a code ont grandement favorisé l'adoption, surtout par des populations éloignées du système/réseaux à la base.

J'ai l'impression aussi que la complexité est maintenant déportée sur l'orchestration et que la gestion des ressources n'est plus aussi surveillée.

 
Dans 10 ans, gloubicorp aura racheté alphabet et plamcorp aura racheté amazon (ou l'inverse) Mais l'important est surtout de savoir qui aura racheté HFR

Les vendeurs de Cloud investissent énormément pour rendre leur platformes "ops less" pour que les devs puissent faire le maximum de caca facilement, consommant le plus de ressources pour facturer au max semi troll.

L'autre intérêt c'est de faire disparaître le savoir faire "full stack" pour rendre les gens dépendants des fournisseurs de compute/net/storage. Détruire ces skills = rendre captif car pas d'alternative.

T'es fournisseur de Cloud, cette stratégie est viable, surtout quand on parle d'un mec comme Bezos...

Un milliardaire chinois qui se sera planté en pensant une technologie à venir qui portera ce nom.
Face à cette erreur, il tentera de le revendre rapidement, mais sans succès, il le vendra 1€ symbolique à elon musk qui supprimera 90% des modérateurs, rendra la création de topik payant avec une réduction de 10% pour les multis.

Il faut tracker les couts, sinon effectivement tu peux tout faire, mais ca te coutera une blinde.
Il faut continuer a faire toi meme ce que tu peux faire  (et maintenir) pour moins cher que le cloud provider.
Essayer de limiter l'adherence au cloud provider egalement.
Ca suppose de s'approprier ou de se reapproprier des technos pour les maitriser.
Faire tout avec du no code sur le cloud, demain l'infra de ton organisation te coutera 10 fois plus cher.
Il faut regarder au cas par cas la ou tu veux garder la maitrise et la ou tu choisis de deleguer (desfois c es imbattable a tous niveaux, y compris prix, donc tu laisses les cles)

J'aime assez la stratégie d'extension d'Azure dans les datacenter onprem que Microsoft continue de préciser notamment avec la sortie d'Azure Stack hci 23h2 la semaine derniere

C'est bien mieux fini que la précédente version, maintenant le déploiement/config d'un cluster onprem se fait directement depuis azure avec une pelletée de tests de validation préalables,  les services d'hybridation Arc sont preconfigurés alors qu'avant il fallait se farcir une pelletée de scripts à lancer manuellement et qui plantaient à chaque cas un peu particulier

 
RFC 1925 section 6
 
Je pense que comme avec beaucoup de problèmes complexes, on peut être vite tenté de se focaliser sur la technique alors qu'on tentait au départ d'adresser un problème organisationnel (en l'occurence, quelle entité/équipe est responsable de quelle partie d'un programme ou système). Les microservices ne sont qu'un moyen parmi d'autres de faire respecter une spécification, moyen qui peut s'avérer coûteux et amener son lot de problèmes. Une fois qu'on a choisi la solution microservices, on peut vite être tenté de l'implémenter tête baissée en oubliant le problème qu'on cherchait à résoudre au départ, pour au final ne pas en retirer tellement de valeur (voire même une valeur négative).
 
Après que je sois clair, je dis ça sans être ni dev ni architecte logiciel, dieu m'en garde  

Même si je pars du principe que l'orchestrateur va gérer les instances, les volumes, le réseau, etc. c'est pas du tout gratuit comme choix comparé à un monolithe.
Un appel de fonction qui devient un appel réseau apporte son lot de complexité:
- La gestion des erreurs ou des latences inattendues dues au réseau.
- La sérialisation des données entres les services, l'évolution de leur schéma.
- Les interdépendances lors des redéploiements si certaines APIs sont de fait couplées.
- Plus de logs linéaires, il faut du tracing, corréler les erreurs.
- La complexité du développement local, personne n'a envie de lancer 12 conteneurs avec Docker compose pour pouvoir débugguer un endpoint.
 
Et j'en oublie sûrement.

C'est intéressant comme points de vue. Ça donne vraiment envie de creuser.

http://highscalability.com/blog/20 [...] 0-ser.html
 
Je pense qu'il faut garder à l'esprit que la motivation première est de répondre à un problème organisationnel.
Tu paies le prix d'une plus grande complexité technique à petite échelle, car c'est une approche robuste à grande échelle.
 
Les boîtes qui y arrivent bien investissement sérieusement dans l'infrastructure nécessaire, pour réduire la friction au minimum.
Mais dans les industries en dehors de la tech, avec des équipes hétérogènes, des silos, ... c'est normalement pas trop une priorité.

Je pense que c'est comme tout, c'est une histoire de proportion, de juste équilibre à trouver entre les 2 approches. Du full monolithique ou du full micro-service ne sera probablement pas la meilleur solution. Par contre, une appli avec un certain nb de fonctions à l'intérieur et d'autres faites par des micro-services, là, ça doit être intéressant.
C'est comme tout dans la vie, rien n'est totalement binaire. Et quand tu optimise un critère, tu en dégrades nécessairement un autre (coût, complexité, compétences à avoir...).

Y'a un projet "cloud" chez nous sur les rails en cours de finalisation de signature, déploiement terraform et branchement à la CI/CD gît d'où la question.

Je vais aller me former sur l'ensemble en attendant dans mon coin, ça pourrait être utile.

Mais surtout, c'est quoi pour vous "microservices" ?

En vrai c'est le business qui doit générer une spec fonctionnelle la plus claire possible, ensuite la technique de trouver la solution adaptée (technologiquement parlant mais aussi de manière orga/compétences/coût à disposition). Ça parait évident mais c'est souvent perdu de vue.

Une approche que j'aime bien de manière générale (qui n'empêche en rien de faire du micro service, au contraire), c'est de penser "API first". Même en monolithique, de toute façon on a de plus en plus besoin d'interconnecter les softs entre eux pour éviter de répliquer la data.

Aussi, pour les devs, ça permet de facilement avoir sa CLI pour son API, et tester des choses plus vite que d'introduire une UI en premier avant que ça fonctionne.

Ensuite ya même des systèmes qui sont pensé « ingress as first class citizen », comme l'excellent EspoCRM qui a des end point "built in" pour manger des leads/contacts/opportunités très facilement depuis n'importe quel soft qui peut envoyer vers des webhooks (oui, les webhooks c'est la vie).

/mes 2 cents d'avoir monté un SI de A à Z pour une boite de 40 péons aujourd'hui

Exact !
Je ne sais pas si beaucoup font vraiment des "microservices" (micro étant important) mais plutôt des "services" (mais toutes les boîtes parlent de microservices en opposition à monolithe - enfin toutes les boîtes que j'ai faites).
Et en générale l'organisation n'a pas grand chose à voir là-dedans, encore une fois dans mon expérience.
C'est surtout pour pouvoir scaler certains composants mais pas tous, plus facilement intégrer d'autres langages en fonction du besoin (ça en go, ça en python, un peu de java, etc...), plus de flexibilité pour le futur, et ça permet de déployer tout ça dans du kube ou assimilé.

Du rajoute de l'apigee, qui oblige tout service a s’exécuter en 20s max, ça fait vite dégraisser les micro-services qui n'en sont pas...
A+,

A priori je dirais que c'est complètement orthogonal.

 
un petit bout de code qui fait un petit bout de truc
 
On en fait un peu, mais en asynchrone chez nous. En somme on se sert de Kafka comme de couche de communication entre tous les services.
 
Dans le fond c'est pareil qu'une API HTTP mais c'est un peu plus tolérant aux pannes (les API c'est le bien mais ça oblige à gérer à chaque fois la disponibilité du service en face pour l'appelant).
 
Avec Debezium pour trigger les appels qui vont bien dès que les valeurs sont changées dans les bdd des applis qui ne font pas de push, ça peut faire le café

 
Tel que je suis habitué, ça sent encore le truc qu'on va laisser openbar à n'importe quel mec de la DSI, chacun va faire son petit repo dans son coin, sa petite api et ça va être l'enfer parce que personne ne sera foutue de dire comment les appels sont passés, quels sont les flux, où vont les fichiers générés, rien ne sera loggé. Je suis vraiment pessimiste.

Si demain je suis CTO et que je peux forcer les 300 devs de mon département à utiliser une seule approche je partirai probablement sur https://smithy.io
 
Et comme expliqué dans l'article que j'ai partagé, bien réfléchir à tous les aspects qu'il faut mettre en place en amont et de manière standardisée (logging, tracing, dashboards, ...)

Puis la gestion des transactions en microservices (saga, orchestration), quel bonheur  

Event sourcing, pas de transactions cross-services, problème réglé.  

Y'a aussi l'aspect perfos. A mon boulot, on a changé de GMAO il y a quelques années. Pour certains besoins, j'ai dû coder quelques outils qui accédaient aux données en direct dans la BD (via un compte en lecture seule). Bonnes perfs.
Maintenant, la nouvelle GMAO dispose d'une API REST. C'est cool pour certaines actions (genre de la création de données) mais pour faire des extracts + calculs/stats, les perfs sont horribles Un truc qui était exécuté avant en quelques secondes met maintenant 1 min voire bien plus...

Ça sent un peu trop le dev dans ce topic...

j'avoue...
vite un modo