Entre l'hébergement old school et le cloud je commence à me lasser de passer un temps fou à gérer de l'infra alors que mon job c'est plutôt le dev… D'autant que l'on nous pousse à avoir une résilience de GAFAM, si t'as pas une redondance multi-région t'as raté ta vie.
Pendant longtemps ça m'a beaucoup plus de tout gérer, du serveur http jusqu'aux mails, merci Linux.
Ca a commencé par systemd, puis docker, puis lambda etc. et je ne m'y retrouve plus, ça ne m'amuse plus du tout. Je ne retrouve plus la philosophie Unix, simple et efficace.
Et au fil des infos sur le cloud souverain voilà t-y pas que je tombe sur Scalingo et Clever cloud, des clones de Heroku frenchies, cocorico, qui ne font pas de bruit. On réinvente rien d'autre que le mutualisé à la papa, un push et ça déploie, mais ça semble fait dans les règles de l'art par rapport à mes pâles imitations. Du coup je me renseigne un peu plus, je tombe sur leurs dépôts github où on peut voir comment ils bossent, des vrais devs répondent en chat sur l'interface où on gère nos déploiement, on se sent moins seul que sur les IAAS.
A force de DIY, un peu peur de déléguer… Qu'en est-il ? Ca marche ? C'est fiable ? Ca soulage ? Ca soigne la déprime du vieil admin ? Ca rassure le décideur ?
Pour ceux qui n'auraient pas suivi, un PAAS c'est une plateforme as a service. Le service en l'occurrence c'est de déployer une application web. On a donc notre dépôt git, notre code et push, on l'envoi sur la plateforme. Et là, magie, le code est automatiquement compilé, les dépendances installées et le tout finalement exécuté dans une VM au chaud, avec sa base de données si besoin etc. De là un load balancer fait transiter les requêtes, les logs sont archivées, le tout est monitoré pour relancer la machine en cas de plantage, pour en lancer plusieurs si y a du monde qui arrive, et il y a même des humains insomniaques qui se lèvent la nuit pour rebrancher les cables si quelqu'un s'est pris les pieds dedans et s'excuser le matin.
Des retours d'expérience ?
# La réponse est dans ta question
Posté par MrBidon . Évalué à 6.
Visiblement tu souhaites te concentrer sur le fonctionnel et tu n'as pas les moyens de recruter quelqu'un pour gérer ton infra, ce genre de solution semble être intéressante dans ce cas.
# J aime bien regarder les offres d'emplois
Posté par syj . Évalué à 7. Dernière modification le 30 janvier 2022 à 12:25.
Quand, je découvre une société. J'aime bien regarder ce qu'ils embauchent. Quel techno,
https://scalingo.com/jobs/ingenieur-cloud-devops
Je vous laisse faire votre avis mais il ne paie pas assez pour moi
[^] # Re: J aime bien regarder les offres d'emplois
Posté par bbo . Évalué à 9.
Du côté de Clever Cloud, sur la partie techno, ils aiment beaucoup Rust et ils ont aussi du Scala pour leurs développements internes. Leur choix de distribution Linux s'est porté sur Exherbo.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par wilk . Évalué à 6.
J'avoue qu'au niveau techno chez Scalingo ils parlent la même langue que moi, Go, ce qui m'arrange plutôt, d'autant plus qu'une partie de leurs outils sont sur github. Ca m'a permis de tester très rapidement leur api.
Chez Clever Cloud j'ai vu que c'était du Rust, y compris sur des traceback du CLI… J'ai eu pas mal de difficultés à faire des essais, utiliser des modules privés en Go, utiliser l'API etc… J'ai pas trop insisté vu que l'idée était justement de ne pas avoir à me prendre la tête.
Si j'ai bien compris Scalingo s'appui d'avantage sur des technos classiques existantes et un fournisseur, sans chercher à étendre trop les fonctionnalités, tandis que Clever Cloud essaye de faire beaucoup plus de choses eux même y compris au sein du kernel (vu sur des confs de Quentin Adam), y compris avec OVH (plus trop confiance…). Plus ambitieux mais ça me semble aussi plus risqué.
Dans un premier temps ce que je vais essayer de faire c'est de rendre mes applis les plus facilement portables de l'un à l'autre (conf en env, stateless etc). Le double effet c'est que si je dois revenir sur mes serveurs je conserverai le principe.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
C'est du remote, donc tu peux cumuler 3 ou 4 postes pour compenser
[^] # Re: J aime bien regarder les offres d'emplois
Posté par syj . Évalué à 3. Dernière modification le 31 janvier 2022 à 10:11.
çà marche pour un bon admin pas trop regardant.
Mais pour un développeur, c'est beaucoup plus compliqué :-p
[^] # Re: J aime bien regarder les offres d'emplois
Posté par Misc (site web personnel) . Évalué à 6.
Suffit d'être admin et développeur du coup. Tu peux aussi devenir influenceur sur Linuxfr.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par groumly . Évalué à 4.
Ca se fait beaucoup le tutoiement dans les offres d’annonces en France?
Meme après 15 ans en californie, culture informelle au possible, ça sonne pas super professionnel…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par devnewton 🍺 (site web personnel) . Évalué à 9. Dernière modification le 31 janvier 2022 à 09:23.
C'est du voustoiement avec anglicisme, écriture parfois inclusive, incohérences…
Bref un joli howto rédiger votre annonce pour faire fuir tes candidat·e·s :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par jihele . Évalué à 10.
C'est juste que c'est pas le même qui rédige l'intro, la description technique et la formule de politesse.
Ils sont un peu silotés.
[^] # Re: J aime bien regarder les offres d'emplois
Posté par Misc (site web personnel) . Évalué à 7.
C'est con, l'annonce dit le contraire:
Nous n'aimons pas les silos : nous faisons attention à ce que tout le monde puisse voir et comprendre ce que les autres font, nous avons une culture de la transparence par défaut.[^] # Re: J aime bien regarder les offres d'emplois
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5.
C’était de l’humour…
# Chez moi Scalingo ça marche
Posté par G.bleu (site web personnel) . Évalué à 9.
tl;dr: 1) Le PAAS c'est la vie 2) Scalingo c'est très cool
Ma boite utilise Scalingo depuis 2 ans, jamais eu de soucis et comme tu dis leur support client est super (il y a un chat intégré et c'est souvent Yann le CEO qui vient répondre !).
Par rapport à Heroku y'a moins d'extensions disponibles forcément, mais les indispensables sont là (PosttgreSQL/MySQL/Mongo/Redis etc.). Perso je trouve qu'il ne manque que une extension de gestion des logs pour faire des recherches facilement dedans (en l'état on a accès aux logs en directe dans la page web de son projet, et sinon il faut utiliser la cli ou bien télécharger les archives à la main)
De mon point de vu le développement et l’administration système sont deux métiers totalement différent. Du coup soit on a une équipe dédié à chaque métier, soit le travail sera mal fait.
À partir de là la question est : est-ce que tu as le budget pour avoir ta propre équipe admin sys en interne ? Perso je suis très content de déléguer ça à Scalingo/Heroku ;-)
[^] # Re: Chez moi Scalingo ça marche
Posté par wilk . Évalué à 5.
Merci, ça me rassure, vu la rapidité de réponse du support je me demandais si je n'étais pas tout seul sur le bateau ;-)
Pour les logs ça me va très bien de les télécharger avec l'api bien que j'ai trouvé surprenant que les logs routeur soit irrécupérables si on les désactive visuellement…
Je suis ma propre équipe d'admin sys (j'ai des besoins très modestes mais des besoins quand même), du coup ça n'est pas une question de budget mais de temps et surtout de motivation !
Au niveau deux métiers par contre je trouve que le fait de gérer les deux oblige à se poser des questions qui oriente l'un et l'autre et ça peut être très bénéfique. Par exemple j'ai choisi Go en grande partie pour faciliter le déploiement et économiser sur les ressources. Inversement j'imagine très bien des situations ou un choix de dev a des conséquences désastreuses sur l'infra, dépendre d'un fournisseur par ex.
Mais après oui, une fois sur le terrain c'est sur qu'il vaut mieux que chacun soit à sa place.
[^] # Re: Chez moi Scalingo ça marche
Posté par claudex . Évalué à 4.
Avoir des personnes différentes ne veut par dire que ce sont des personnes qui ne se parlent pas. De la même manière que dans une équipe de dev, il faut faire des choix techniques (genre choisir go) et il faut se mettre d'accord, ça peut avoir des impacts bénéfique ou négatifs sur certaines partie du code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chez moi Scalingo ça marche
Posté par wilk . Évalué à 10.
Des équipes qui se parlent ? Et pourquoi pas un décideur qui les écoute pendant qu'on y est ?
Hahaha, oui, évidement tu as tout à fait raison, d'où l'intérêt du chat de Scalingo… Je continue ma progression…
[^] # Re: Chez moi Scalingo ça marche
Posté par Eh_Dis_Mwan . Évalué à 4. Dernière modification le 30 janvier 2022 à 21:38.
le CEO qui reponds aux ticket support me rassurerait pas.
1- N'a t'il pas autre chose à faire que de prendre des tickets ? (des entretiens d'embauche, des recherches de marchés , ou plutôt de financements ici)
2- Ce qui peux signifier qu'il n'y aucune organisation dans la direction "Customer".
Enfin chacun son avis.
Après , si c'est que du chat, c'est sans doute un bot qui redirige après les tickets vers des ingénieur support , Automation Anywhere , je crois qu'ils font ça
[^] # Re: Chez moi Scalingo ça marche
Posté par cg . Évalué à 10.
Chez REdHat, c'est (c'était ?) parfois le CEO qui répondait à la hotline.
C'est bien je trouve de temps en temps de faire le travail des autres.
[^] # Re: Chez moi Scalingo ça marche
Posté par Misc (site web personnel) . Évalué à 3.
Que je sache, ça n'est arrivé qu'une fois:
https://access.redhat.com/videos/344503
Ensuite, je trouve ça bien que le support soit fait de temps en temps par d'autres personnes, même si au bout d'un moment, il faut se souvenir que le support est un métier à part entière, et que n'importe qui peut pas le faire (donc qu'on peut pas prendre un pdg, un commercial, un dev et dire "c'est bon").
Mais avoir une idée de comment ça se passe auprès des clients, ouais, c'est super important. C'est dans la même lignée que les ingés de Peugeot (je crois) qui doivent passer 3 mois sur la chaine avant de prendre leur poste.
[^] # Re: Chez moi Scalingo ça marche
Posté par eggus . Évalué à 4.
Je ne connais pas leur organisation interne, j'ai un jour travaille chez un petit editeur (50 personnes), et on planifiait des jours de 'rush' pour traiter un backlog de ticket (support / demande de feature). Le directeur des operations prenait aussi sa part de travail ce qui ne veut pas dire qu il n'y ait personne derriere (on etait 4 dans l'equipe).
[^] # Re: Chez moi Scalingo ça marche
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Ça dépend du temps qu'il consacre à ça. S'il répond à 1 ou 2 tickets de temps en temps, ça peut être un moyen pour lui d'avoir une meilleure vision de ce que pense les clients de son produit et de ce qu'il faudrait améliorer en priorité. Mais, effectivement, il ne faudrait pas que ça lui prenne du temps plus utile par ailleurs.
[^] # Re: Chez moi Scalingo ça marche
Posté par Yann KLIS (site web personnel) . Évalué à 5.
Ca fait très très longtemps que je n'ai plus le temps de gérer le support. Même si je peux effectivement filer un coup de main de temps en temps.
# clever cloud
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
J'ai utilisé clever-cloud, ça juste marche pour ma part.
"La première sécurité est la liberté"
# Data trop cher
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Presque 1000€ par mois le postgres avec une taille (qui compte) ridicule :(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Data trop cher
Posté par Misc (site web personnel) . Évalué à 5. Dernière modification le 31 janvier 2022 à 12:50.
Alors j'ai fait le calcul hier pour les conteneurs en comparant avec le cluster Openshift que j'ai au boulot.
Scalego, c'est 7€ le conteneur à 256 Mo de ram.
Le cluster openshift du taf, c'est 7 machines m5.xlarge de chez Amazon, 138 US$ par mois et par machine normalement (en Oregon). Je viens de regarder les factures, on est à 1300 US$ avec reduc (grosso modo 10% sur le prix public), donc 1160€ par mois, la majorité (90%) du coût étant les VMs.
Donc si je décide de revendre des conteneurs au même tarif que Scalego avec la ram qui reste (cad 64G de ram), j'aurais 1960 euros de chiffres d'affaire par mois.
Mais, ça, c'est avec un cluster de petite taille. Si je rajoute 1 noeud à 16G de ram pour faire tourner des conteneurs, ça va me coûter 138$ par mois (123€) + ~10%, etc, mais je vais avoir de quoi faire tourner 448€ de chiffres d'affaires en terme de ram.
Ça reste une marge assez confortable (~300€) pour payer les ingés qui font tourner tout ça.
Ensuite, je ne compte que le coût de l'infra. Les ingés coûtent de l'argent. Par exemple, avec un client qui consomme 320G de ram, tu va faire 6000€ de marge, ça permet de payer 1 ingé plus divers frais à temps plein.
Le support coûte de l'argent. La comptabilité coûte de l'argent. Le fait d'avoir l'infra non rempli à 100% coûte de l'argent. Certains clients qui vont prendre plus de ressources vont te coûter de l'argent.
Mais à coté de ça, une fois que tu as un client, la compta te coûte pas tant que ça sur la durée (tout comme les commerciaux). Une fois que tu as assez de client, tu peux avoir des réductions sur l'infra (genre, passer en instance réservé semblent permettre de faire des économies substantielles).
Donc ouais, ça parait cher, mais pas tant que ça quand on prends en compte le coût humain.
[^] # Re: Data trop cher
Posté par barmic 🦦 . Évalué à 4.
Pour un tas de raisons j'ose espérer que différents clients c'est pas simplement mappé sur des namespaces kube.
Mais c'est logique que ce soit plus chère quand tu fais ce genre de mapping. Des pratiques d'IaaS ne fit pas bien dans le PaaS, oui.
Donc si tu en a besoin d'1, c'est moins chère qu'un EC2 qui commence à ~13€ et ton coût peu se calculer en 7 * le nombre de conteneurs. Si tu pars sur des machines que tu administres, tu es à 138 * (nombre de conteneur / 64 + 1). Selon la façon dont tu prévois de croitre ça peut arranger ou non. Puis tu as un ou plusieurs control-plane et etcd.
Ensuite tu as la gestion en plus, devoir maintenir ton kubernetes (mise à jour au moins 3 fois par an + le linux sous-jacent, faire sa veille technique et pas juste mettre à jour l'applicatif mais coller aux bonnes pratiques - comme le fait de remplacer docker -), si tu veux de l'élasticité, il faut potentiellement automatisé le (dé)commisssionement des machines, etc, etc
Ça se fait (moi je le fais), mais le faire bien c'est compliqué et c'est du temps que tu ne passe pas ailleurs. Pour moi le coût de tout ça en balance uniquement avec le prix du matériel c'est cacher beaucoup de coûts. Sachant que tout ce que tu investit dans cette maintenance c'est de l'investissement que tu ne met pas ailleurs et que le gain d'être à l'état de l'art peut être intéressant (ou dit autrement ça peut te faire perdre du temps de ne pas être à la page).
Et tout cela c'est sans parler du fais que c'est surtout fait pour être élastique généralement et si tu peut rentrer dans 10 conteneurs 5 à 10h/jour tes calculs ne vont pas être les même.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Data trop cher
Posté par Misc (site web personnel) . Évalué à 3.
je suis d'accord, mais dans le cadre de la discussion actuelle, la techno sous jacente n'importe pas trop sauf si elle change fondamentalement le coût (genre si chacun a une VM et que ça coûte 20% de plus que mon estimation). C'est une estimation au doigt mouillé avec les chiffres que j'ai.
Ça rentre dans la partie "les ingés coûtent de l'argent" dans mon post, et la fin de "ça coûte cher, mais pas tant que ça si tu comptes les salaires".
La différence à ce niveau entre le faire soi même ou demander à une boite de PaaS, c'est que la boite va standardiser tout au delà des limites de mon entreprise. Mais sinon, les ingés coûtent globalement autant des 2 cotés. L'exemple extrême serait de passer par un PaaS externe dont tu es le seul client, je pense qu'on peut facilement dire que ça va pas réduire la facture de beaucoup.
Par contre, si tu as 1000 clients qui veulent exactement la même chose, c'est le gros lot.
Ensuite, tu as rarement 1000 clients qui veulent la même chose, mais ça rentre dans la partie ou c'est compliqué d'estimer les coûts (tout en sachant que la boite externe est la pour maximiser son profit, pas pour baisser tes coûts).
Oui, c'est aussi pour ça que j'ai dit que si ton infra est pas rempli à 100%, ça te coûte de l'argent (ou ça te rapporte moins, ce qui est grosso modo pareil).
[^] # Re: Data trop cher
Posté par barmic 🦦 . Évalué à 3.
Si tu veux mais c'est sous-estimé alors. Tu as 2 cas :
Si tu as déjà les compétences en interne qui sont allouées à ce type de travail, c'est un cas où tu as déjà répondu à la question.
Non. L'embauche, la gestion RH, l'augmentation que ça induit sur ta masse salariale, la capacité à débaucher,… Ça n'est vraiment pas la même chose.
Oui et non si tu leur demande du mesos ils vont te rien faire pour toi. Ils ont un contrôle sur les changements qu'ils acceptent ou pas et si tu n'a pas 1000 clients qui veulent la même chose ça ne veut pas dire que tu as 1000 clients tous différents entre eux.
AMHA quand tu va vers chez eux, tu va mécaniquement finir par t'y mettre, ils ont les outils pour et la facturation y pousse.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Data trop cher
Posté par Misc (site web personnel) . Évalué à 3.
Non, mais ce que je veux dire, c'est que le risque d'embaucher quelqu'un qui ne va pas est pareil que ça soit toi ou une boite externe. Si la boite qui fait le PaaS va embaucher quelqu'un qui ne va pas, les conséquences pour toi sont pas très différentes de ce que ça va donner en interne.
Mais ça va dépendre de la taille de ta boite plus que de savoir qui est fournisseur de qui et plus que de savoir quel flux va dans quel sens. À un moment, quelqu'un paye en temps pour l'embauche.
Si c'est le fournisseur, le coût est répercuté sur tout les clients. Si c'est le client (ou plutôt, le non-client), c'est direct.
[^] # Re: Data trop cher
Posté par barmic 🦦 . Évalué à 3.
Non du tout. C'est leur métier ils savent bien mieux estimer les compétences et ils ont déjà fait ce travail quand tu vient les voir c'est pour ça qu'ils te proposent leurs services. Et quand toi tu va galérer pour avoir un profile. Eux en ont toute une équipe donc pas d'indisponibilité pour les vacances, lissage de l'apprentissage, roulement pour les nouveaux, ça n'a rien à voir avec ce que tu peux faire en tant que client. Sauf si c'est déjà ton métier mais tu as alors déjà fais ton choix. Et non tu ne paie pas le même prix d'embauche en tant que client parce qu'une part importante de ce coût n'est pas financié (est du temps pour beaucoup) et qu'ils n'embauchent pas un gars par client.
Les conséquences sont très différentes parce qu'avec un presta ce n'est pas un gars qui va s'occuper de toi, mais une équipe. Il faut donc avoir raté un paquet d'embauche pour que ça revienne au même et c'est là qu'intervient la question du journal.
Je ne dois pas comprendre de quoi on parle. Il me semblait qu'on regardait le prix du offre du point de vu du client pas les coût des systèmes avec ou sans un pourvoyeur de service.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Data trop cher
Posté par mr_unichs . Évalué à 4.
S'ajoutent également la supervision, l'astreinte (!), la gestion des mises à jour (de la base de données mais également de l'OS sous jacent…), les patch de sécurité, la gestion du PCA/PRA, du réseau…
Le modèle PAAS ne s'adresse clairement pas à tout le monde, et il peut paraitre (très) cher de prime abord, mais quand on fait l'effort de décortiquer en détail le coût réel d'une installation "on premise" on s'aperçoit qu'il est souvent bien plus important que la partie visible initialement à savoir l'achat du matériel et l'installation de la base de données.
[^] # Re: Data trop cher
Posté par Misc (site web personnel) . Évalué à 5.
Ensuite, la supervision et l'astreinte, tu va avoir ça aussi même en passant par un PaaS. Déjà parce que le fournisseur va aussi avoir des emmerdes (incendie chez OVH, us-east-1 down chez AWS, etc). Mais aussi parce que tu peux aussi te planter et avoir du code foireux de ton coté. Tu peux avoir des soucis de paiement (et ton compte disparait), etc.
De même, tu va forcément avoir un PRA même avec un PaaS. Tu va devoir t'occuper de la sécurité de ton code et mettre à jour la plateforme sous jacente quand elle change (cough python 3 cough), même avec un PaaS.
Je suis d'accord qu'il y a plein de trucs quand on rentre dans les détails, mais en passant à des services externes, tu va parfois simplement changer les détails.
Et suivant les prix, ça peut être plus cher ou moins cher. Par exemple, oui, un service de PaaS va être plus efficace sur son cœur de métier que toi (et potentiellement moins cher).
Mais toi, tu n'as pas à payer les commerciaux et le marketing quand tu fais des choses en interne (et donc le PaaS va avoir des frais en plus que tu n'as pas), et tu peut arriver à être moins cher sur la gestion en passant à l'échelle (compta, RH, service généraux) si tu es plus gros que la boite de PaaS (qui va avoir les mêmes besoins).
[^] # Re: Data trop cher
Posté par Psychofox (Mastodon) . Évalué à 7.
Faut mettre ça en rapport avec avoir des sysadmin dans ta boite, possiblement avec un contrat pour qu'il y ait quelqu'un on-call 24/7 donc mini 2-3 ingénieurs.
Si tu mutualises ces ingés pour pleins d'autres trucs, c'est une autre affaire mais pour une seule base, ça te coûtera bien plus cher.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.