PAAS or not PAAS, that is the question

paasJusqu’à récemment HopWork tournait sur un PAAS, mais ça va changer. Pour les quelques uns qui ont dormi ces dernières années, un PAAS c’est l’acronyme de Platform as a service. En très gros c’est un cadre de travail pour délivrer rapidement votre code en production avec tout un ensemble de services préinstallés, gérés pour vous et qui s’associent simplement avec votre applicatif.

Pour simplifier très fort, c’est ce qui permet au développeur de faire un simple : “git push provider master” pour que magiquement votre dernière version sur git se retrouve en prod.

Remplacez ici “provider” par Cloudbees, Heroku, Clever-Cloud, Google App Engine etc…

Au tout début d’un projet comme HopWork, le choix d’un PAAS se fait naturellement. Tout ceux qui ont un projet en tête, qui souhaitent le prototyper rapidement et le montrer, le PAAS est votre ami. Vous ne vous concentrez que sur votre code et quelques paramétrages relativement légers sur votre PAAS. En plus, bien souvent, pour de petites utilisations un PAAS va se révéler très peu coûteux, voire même gratuit.

Pour notre part, nous avions choisi Heroku. Heroku propose un système de worker et pour un seul worker vous ne payez pas.

Par contre un PAAS s’accompagne de quelques contraintes qu’il faut apprendre à respecter. Par exemple chez Heroku :

  • les disques sont volatiles
  • votre appli doit être rapide à booter
  • l’environnement d’execution est contraint (512Mo de ram pour un worker Heroku)
  • avec un seul worker sur Heroku, si pas d’activité, votre appli est mise en hibernation (donc elle doit être rapide à redémarrer par la suite)

Au dessus de votre PAAS vous allez rapidement faire appel à des SAAS (Software as a service). Sur HopWork nous avons utilisé ou utilisons encore :

(pour localizeyourapps, ne cherchez pas, c’est moi qui le développais, c’est plus ou moins mort pour l’instant)

Pour ces quelques services, nous en avons évalué d’autres et continuons à en évaluer régulièrement (CloudAmqp, Fasterize et Cloudflare sont dans les tuyaux par exemple).

Là encore, pour des utilisations légères, ces services proposent souvent des plans gratuits qui vont être utilisables pendant longtemps.

Alors pourquoi changer ?

Pour être honnête, c’est un choix difficile de changer et de revenir sur un serveur dédié pour une partie des services. Quelle plus-value ? Quelle moins-value ?

Les coûts ?

Selon moi un produit connaît plusieurs phases.

Au tout début d’un produit, vous faites tout avec des bouts de ficelles car vous avez zéro budget. De plus vous voulez montrer très vite ce que vous faites. Le PAAS est l’idéal pour cela et vous permet d’être concentré sur votre appli et rien d’autre. (Au diable la sécurité ! :))

Ensuite si vous avez de la chance, votre soft rencontre un peu de succès, vous avez des sous mais vous devez passer sur des plans tarifaires supérieurs pour certains services que vous utilisez. Vous êtes dans la période où vous devez perpétuellement jongler entre la surveillance des coûts et la rapidité d’exécution. Soyons clair, on doit toujours jongler avec ça, mais dans cette période d’autant plus.

Pour illustrer, voici les coûts mensuels des services avec notre traffic actuel :

  • Heroku 1 worker de 1024Mo : 35$
  • Heroku : certificat SSL : 20$
  • Cloudinary : 30$
  • Mandrill/Mailchimp : 35$
  • Twilio : cout fixe par SMS
  • Mangopay : % par transaction

A cela s’ajoute des coûts qui vont ou pourraient arriver :

  • Nous sommes à la limite de devoir passer sur un plan payant pour MongoLab : 15$
  • Si nous étions restés chez Searchbox : 9$
  • Nous sommes en fin de période “promo” chez Zendesk, le cout passe ensuite à 25$ + 29$ par “agent support”.
  • Pour bien faire il faudrait 2 worker Heroku : 70$
  • Logentries si on veut garder les logs plus longtemps ce sera 19$

Mais on ne peut pas comparer SAAS et “fait maison” en parlant que des coûts :

  • Mangopay c’est du paiement et nous n’avons pas vocation à en faire nous-mêmes
  • Mandrill, Twilio, Cloudinary, Zendesk proposent des services à forte valeur ajoutée et nous perdrions beaucoup de temps à le refaire
  • A l’inverse certains produits même sur des plans supérieurs ne proposent pas exactement les fonctionnalités que l’on souhaiterait (comme Logentries)
  • De toute façon je ne vous ai pas encore parlé des coûts du “fait maison” 🙂

Pour être clair nous allons continuer à utiliser du SAAS pour des services à forte valeur ajoutée car cela n’aurait pas de sens de les refaire de notre côté. Cela reste dans l’optique d’une architecture micro-service telle que nous la concevons sur HopWork (Certains SAAS continueront cependant à être évalués régulièrement face à leurs concurrents). Ce qui est remis en cause c’est uniquement un subset de tout ces services :

  • mongo
  • elasticsearch
  • logentries (et encore celui-ci se discute)
  • Rabbitmq
  • et le PAAS : Heroku

En fait vous remarquerez que j’ai fait le distinguo entre les SAAS à forte valeur ajoutée, et les SAAS qui proposent de l’infra.

Pour ceux la, sur HopWork il nous semble que c’est justement le moment où les coûts restent maîtrisables mais nous commencons à les sentir et on note voyez que les plans tarifaires encore au dessus vont être vraiment plus chers (entre 89 et 200$ mensuel en entrée de gamme selon ce qu’on cherche chez mongolab).

De toute façon sur les plans de base, c’est souvent labellisé “sandbox” ou “developpement” avec tout ce que ca implique donc nous avons fortement intérêt à upgrader et là ca peut faire très mal.

Au delà de ça, avoir son elasticsearch et sa base mongo accessible sur le net, même protégé par un login/password, ca reste moyen. Nous en avons eu récemment l’expérience avec Heartbleed, tout les providers sans exception nous ont demandé de changer les credentials et clés d’API utilisés sur leurs services.

Pire, il y a quelques mois, seul Searchbox proposait un elastisearch as a service sécurisé.

 

La scalabilité ?

Une promesse de ces services, c’est la scalabilité et l’élasticité. Ici par exemple le slogan d’Heroku :

Build, run, and scale apps.

Cloud computing designed and built for developers.

 

Sauf que “scaler” n’est pas une de vos priorités immédiate. Construire des clusters de mongodb avec du sharding ou gérer un traffic de 10000 visiteurs/minutes ce sera dans longtemps. Enfin pas trop, je vous le souhaite, mais pas immédiatement.

HopWork c’est 4000 inscrits, un peu moins de 1000 visites/jour (ca augmente chaque mois). C’est très honorable mais ca représente pas tant que ça pour une machine bien dimensionnée et bien utilisée. Pour l’instant la priorité c’est les fonctionnalités, pas la tenue en charge.

Par contre cette fameuse “scalabilité”, quand vous avez une appli simple vous la payez alors que vous n’en profitez pas.

Déjà vous avez une application distribuée, c’est cool mais contrairement à ce que certains croient, c’est pas le paradis (le réseau n’est pas fiable, la bande passante n’est pas illimitée, etc…)

Parmi les fausses croyances du distribuée, on pense que les latences sont négligeables mais elles existent bel et bien.

Par exemple entre un Heroku sur zone US et un Heroku sur zone EU vous avez une latence qui varie entre 200 et 300ms. Entre une appli hébergé sur Amazon EU (Irelande) et une base Mongo hébergé en France (OVH), vous avez une latence qui varie entre 50 et 150ms.

 

Nos choix

Si je résume, en fait nous sommes en cours de migration de certains services pour les raisons suivantes :

  • le coût (pour ce qui concerne le PAAS, les bases de données, files de messages)
  • la sécurité
  • des besoins actuels simples en terme de scalabilité
  • des besoins de meilleure performance (des latences moins élevés)

Comme je le disais plus haut, le choix de repasser sur du dédié sur certains services fut difficile. Nous nous sommes donc posé deux contraintes simples :

  • il doit être possible de refaire le chemin inverse facilement
  • la simplicité de mise en prod doit être maintenue

Ce qui implique des choix assez évidents :

  • ne toujours pas reposer sur le disque, faire comme s’il était volatile
  • le serveur lui-même est considéré comme volatile, il peut à tout moment crasher. Il doit donc pouvoir être remonté rapidement et automatiquement
  • avoir une appli qui boote très rapidement
  • ne pas bouffer des ressources comme des malades 🙂
  • conserver un workflow simple de déploiement, idéalement basé sur git
  • garder un découplage maximal entre les différents composants de l’architecture

Factuellement, pour héberger tout cela, nous avons pris un serveur OVH Soyoustart 32Gb de ram, disque SSD, 8 coeurs pour 40euros/mois. En terme de ressources et en simplifiant grossièrement cela représente 64 workers Heroku (évidemment c’est exagéré, une appli a une empreinte sur la machine qui ne se résume pas à sa heap).

Pour l’installation des composants, nous utilisons Ansible.

Pour le déploiement applicatif, le choix n’est pas encore posé, c’est l’étape qui reste à faire. Il existe plusieurs pistes : git-deliver, git-deploy ou tout simplement du Fabric ou du Ansible piloté par Jenkins.

D’ailleurs si vous avez des suggestions ou des retours je suis preneur.

 

Ok, dans cette configuration certains vont me dire qu’il reste de le souci de la disponibilité. Sauf que par expérience nous avons eu plusieurs “incidents” depuis qu’HopWork existe, que ce soit des indispos et crash de elasticsearch, des indispos Mongolab, Heroku ou carrément amazon, ce qui dans ce cas flingue tout le reste.

En centralisant sur un serveur, nous ne sommes dépendants que de ce serveur et nous gagnons sur les latences entre composants. Ok, il peut crasher, d’où le fait de tout automatiser pour rapidement remonter un autre serveur.

 

Certains pourraient poser la question “mais quitte à gérer votre plateforme, pourquoi pas du IAAS avec Amazon EC2 ou Google Cloud ?”.

D’autres encore pourraient demander “mais pourquoi pas Cloudwat ou Numergy”, et là ce serait une grosse tranche de rire. Mais passons…

Concernant EC2 déjà, j’avoue que je trouve leur grille de prix n’est pas simple pour s’y retrouver. Vous avez des instances à la demandes, des instances réservées pour utilisation modérées ou intensives, des instances ponctuelles, vous avez des tarifs pour transferts de données (?! WTF), des instances optimisées pour EBS (?!). En fait, rien que la page de pricing simplifiée est d’une longueur infinie. Et leur calculette fait pas rêver non plus. En essayant vaguement de jouer avec la calculette pour une instance médium avec disque SSD et 3Gb de ram j’arrive tout de même à 56$/mois et je n’ai rien rempli dans les parties Data Transfert ou ElasticIP.

Bref, c’est obscur et pas si rentable si on compare à la machine que j’ai décrit plus haut pour le même prix.

Google Compute Engine a une grille de tarif à peine aussi claire. Cette fois on ne sait même pas quelle disque est disponible mais on retombe grosso modo sur le même prix que ci-dessus pour 3Gb de ram. Encore une fois, toutes les options du bas de page laisse penser que dès qu’on veut du disque ou une IP ca coute encore plus cher.

Dans les deux cas il s’agit de VM. Pour ma part j’ai des expériences pas très heureuses en ce qui concerne les performances IO et la virtualisation donc déjà sur le principe je ne suis pas emballé.

Bref, je ne demande qu’à être convaincu par quelqu’un ayant déjà utilisé (et je ne parle pas d’avoir juste jouer a spawner une instance).

 

Voilà, vous savez tout. Nous ne savons pas avec certitude s’il s’agit du meilleur choix mais nous avons fait en sorte de pouvoir changer d’avis par la suite. Dans les prochains billets je reparlais peut-être d’Ansible ou de quelques outils mis en place pour notre infra.

A bientôt

9 réflexions sur “PAAS or not PAAS, that is the question

  1. Bonjour, je suis le CEO de Clever Cloud et j’avais quelques points de réactions à votre articles.

    Je trouve dommage d’incriminer tout les PaaS sur la seule utilisation d’heroku, qui est certes pionnier, mais qui n’en ai pas moins bourré de défauts.
    => L’hibernation des workers est une super mauvaise idée en effet, mais elle est lié à heroku, ce n’est pas une généralité dans le PaaS
    => les tailles fixes de scalers aussi, par exemple chez clever des machines avec 8 cpu et 16 Go de RAM sont disponible de série
    => la vollatilité des disques est une bonne pratique, mais certains acteurs proposes des solutions pour y répondre (oui, je sais : comme clever).
    => les latences que tu évoques sont lié à AWS, je pourrais détailler les postes de performances du HW ou du réseau, mais encore une fois, nous ne jouons pas dans la même cours (en moyenne on divise par deux les temps de mise à dispo d’une réponse pour une requête par rapport à heroku)

    L’analyse de coûts se concentre sur les addons et donc pas sur le PaaS lui même… Et surtout occulte tout le temps de travail pour installer et gérer cette migration : combien coute une journée de travail ? vous avez mis une semaine au mieux à migrer ? 500 * 5 = 2500 En lissant cet investissement temps sur 12 mois, tu peux ajouter 210€ à ta facture mensuelle, ce qui ne comprend même pas la maintenance… Quel coup humain pour ces infrastructure ? Et surtout, si le focus est sur les fonctionnalités, quel coups à ne pas travailler sur autre choses pendant ce temps là ?

    Sans parler du débat du monitoring… Il doit être fait par un serveurs externe, par exemple new relic à 150$/mois… Et qui doit gérer un problème serveur à 3h du matin le samedi ? 365 jours par an il faut avoir quelqu’un de compétent et dispo…

    En quoi le PaaS est unsecure ? Cela dépend de la façon dont les gens travaille : on a fixé la faille heartbleed avant à peu prêt tout le monde ( http://git.exherbo.org/arbor.git/commit/?id=bbd3406f39aec6c35eefe89d68dcec46ecab5d79 ), puis on a tout deploy and co sans que personne n’y voit rien : le vrai service du PaaS est là ! Il est humain. On regarde les CVE tout le temps et on corrige tout le temps sans rien dire à personne… Pourquoi serait on unsecure ?

    Réduire le PaaS au prototypage est très dommage, c’est fortement induit par le produit qu’est heroku aujourd’hui, j’en suis bien conscient, mais au contraire un PaaS est conçu pour la durer et aider ses clients : nous avons des clients qui font des passages télé, nous on tiens, certains qui sont sur des IaaS ne le font pas… Parce que c’est négliger la partie Service d’un PaaS : nous assurons vos arrières ! Vous faites des applications, nous on les héberge. That’s it.

    Un bon PaaS est là pour aider les développeurs, assurer que l’application fonctionnera et leur faire gagner un temps précieux, les laissent se concentrer sur leur valeur ajoutée sans se defocus. C’est ce qui permet de shipper plus vite et bien.

    En clair : vous n’étiez pas satisfait d’heroku, du coup, le PaaS ne répond pas au problème… C’est bien dommage… Pourquoi ne pas shooter un mail à sales@clever-cloud.com ? On peut vous proposer quelques chose. Il y a d’autre providers… C’est pas parce que windows est une sombre daube que tout les systèmes d’exploitations sont à jeter…

    Voilà… pour dire que je trouve dommage d’imputer à tout les PaaS les soucis rencontré avec heroku. Certains essayent de faire leur travaille honorablement.

  2. Et derniers point :

    Une VM bien gérée n’induit pas d’overhead I/O. Par exemple Virtio sous KVM permet d’employer le driver de l’hote dans la VM est d’avoir des perfs d’I/O quasi Host 😉

  3. Oki, long message et intéressant donc je vais essayer de répondre en n’oubliant rien.

    Tout d’abord, avant de répondre je « n’incrimine pas les PAAS ». J’ai l’impression en te lisant (je peux te tutoyer ? J’ai même vu ta conf à Mixit :)) que tu lis mon post de facon négative envers les PAAS.
    En fait j’apprécie beaucoup les PAAS et la décision de migrer n’est pas évidente comme je l’indique dans le billet. Donc avant toute chose, le boulot fourni par les PAAS de façon générale est une bénédiction pour tous les devs Java et qui plus est j’aime bien ce que fait Clever-Cloud.
    Pour la petite histoire nous avions échangé à un moment pour migrer sur Clever mais Mongodb et elasticsearch ne faisait pas partie des addons que vous aviez en stock. Je crois que ce n’est pas encore le cas pour elasticsearch. Et j’ai également besoin de RabbitMq et je crois que ce n’est pas proposé également.

    Quelques réponses :

    => l’hibernation des workers. En soi ce n’est pas mauvais, ca permet à Cloudbees ou Heroku de proposer des plans gratuits mais limité. Pratique quand on démarre un produit avec très peu d’users au début.
    => le système de workers. Sur le fond, c’est une facon de m’assurer que je ne vais pas exploser mes coûts. J’ai un environnement contraint, mes ressources vont me coûter tant, pas de surprise à la fin du mois. C’est pas la même chose que les « scalers » sur Clever Cloud ? A une époque il y avait un système de « drop » sur Clever qui justement faisait un peu peur car on pouvait craindre que la consommation augmente sans qu’on maîtrise les coûts.
    => la volatilité des disques ne me déplaît pas. Je ne le cite pas comme un défaut. C’est une découverte quand on démarre sur un PAAS mais c’est une bonne chose.
    => les latences : je les évoque car pour les services de base : l’appli, bases de données, files de messages, à partir du moment où elles ne sont pas hébergées dans le même datacenter elles sont pénalisantes. Evidemment si j’ai tous mes services dans un même datacenter en théorie ca devrait mieux se passer. Encore faut-il que le PAAS propose tout ces addons de facon colocalisés. Par exemple si elasticsearch n’est pas dispo en addon et que je dois le chercher chez Searchly dans un autre datacenter, j’ai un surcoût inévitable. Bon et sans surprise l’accès local reste le plus rapide.

    Concernant les coûts, évidemment je ne souhaite pas négliger les temps de setup/maintenance etc… Il y a un coût d’entrée pour automatiser correctement puis surveiller. Pour moi ils ont été moins importants que ceux que tu décris mais je suis prêt à parier que pour beaucoup de gens ce sera un mur infranchissable, je ne le conseille pas à tout le monde. Je t’assure qu’il ne faut pas négliger non plus le coût d’évaluation de chaque PAAS, ces contraintes (car chaque PAAS en a qui lui sont propres), ses addons etc… Et non, ça ne dure pas 5 min pour savoir si on pourra bosser vraiment avec un PAAS ou non.

    Pour le monitoring, ouaip je suis d’accord que c’est confortable d’avoir une personne qui gère les soucis d’infra. Je mettrais même ce point devant le setup. Après il ne faut pas négliger le fait qu’un incident sur un élément central (une file de message par exemple) peut avoir des impacts nécessitant aussi une intervention des « développeurs ». Ce n’est donc pas comme si les incidents arrivaient et que c’était transparent à chaque fois (parfois ca l’est quand même). J’ai déjà perdu la totalité de mes données sur un elasticsearch en SAAS. Ok, l’instance est revenu, mais j’ai du intervenir pour les remettre.

    Concernant la sécurité, là dessus c’est un long débat. De mon côté j’estime que laisser un mongo, un elasticsearch ou une file de message ouverte sur l’extérieur, même protégé par un mdp c’est une mauvaise pratique. Plus il y a de système accessible depuis l’extérieur plus on laisse de porte d’entrée possible. Chaque système publie régulièrement des correctifs de sécurité, personne n’est parfait. Pour ma part j’estime que déjà si on ferme un certains nombre de services qui n’ont rien à faire ouvert aux quatre vents c’est mieux (bind uniquement sur ip locale ou acceptation de communication par IP, firewall etc…). Je ne sais pas ce que Clever propose à ce niveau là, mais les autres ne proposent pas ça.
    A propos de Heartbleed, même si une faille est corrigée, cela ne veut pas dire qu’elle n’a pas été exploité. C’est bien dans ce sens que chaque fournisseur de SAAS a demandé à ces clients de changer ses credentials, c’était pour minimiser le risque.

    Pour la fin de ton message, en fait elle est beaucoup plus négative que mon texte d’origine sur Heroku 🙂 Du coup j’ai pas grand chose à répondre en dehors du fait que non, je ne suis pas contre l’utilisation de PAAS. J’ai pesé le pour et le contre pour mon cas d’usage, et uniquement le mien, avec les connaissances que j’avais à l’instant T, le savoir faire que j’avais également et j’ai tiré cette conclusion.
    On verra par la suite.

    Dernier point puisque tu as rajouté un message à la fin : concernant les perfs I/O c’est cool. Perso j’ai toujours été déçu pour de gros accès disque mais c’était en 2007, il y a sans doute eu des progrès depuis et je n’avais pas forcément les meilleures aides dessus à l’époque. Mais je ne prends pas tout sur papier, faudra que je teste 😉

  4. Super article, j’ai pris note au passage d’un ou deux SaaS dans ta liste que je ne connaissais pas!

    Et coïncidence, nous sommes passés par la même sorte de transition il y a 1 mois dans ma startup.
    Un PaaS est super pour débuter et coder vite comme tu dis. On était sur EngineYard qui est sympa pour entre autres du Ruby (nous avons une stack Rails).

    Mais arrive un moment où on a voulu un niveau de contrôle de notre architecture qu’un PaaS ne peut offrir. EngineYard était trop lourd, par exemple une faille de sécurité Ruby est à mettre à jour ASAP, mais ils ont mis 7 jours avant de la corriger. Aussi, on ne peut pas tweaker certaines options aussi facilement. Et de manière générale EY commençait a ressentir trop « clunky ». Et comme tu dis, arrivé un certain palier les coûts en dehors des formules basiques peuvent s’avérer prohibitifs pour finalement peu de valeur ajoutée par rapport à du dédié/IaaS.

    Je ne sais pas si les coûts sont vraiment supérieurs pour du IaaS comparé à du dédié. Il y a une différence négligeable entre ton OVH à €40/mois = $55/mois et ton $56/mois avec la calculette Amazon EC2. En tant que développeur et ops-ultra-débutant je penses personellement que c’est kiff/kiff, mais je ne suis pas un « Cloud expert/guru/sorcerer ».

    Nous avons choisi Amazon EC2 principalement parce que nous utilisions déjà leurs autres services (S3 pour le stockage de documents, Route 53 pour les DNS, Cloudfront pour le CDN, etc.) et que ça nous permettait d’avoir toutre notre archi sous un même toît. Ce n’était pas une décision ultra forte, il y a d’autres IaaS très bien comme Digital Ocean, Rackspace, Linode, etc. AWS peut peut-être sembler lourd à gérer parfois, et même si c’est le pionnier de l’IaaS c’est pas forcément le meilleur rapport qualité/prix. Mais on est partis dessus, et pour l’instant je dois dire que j’en suis ultra satisfait.

    On gère le déploiement des instances avec Chef qui est assez populaire chez les rubyistes vu que c’est du code Ruby côté conf. J’ai rapidement entendu parler d’Ansible mais je ne connais pas vraiment (plus connu dans le monde Java peut-être?). Entièrement satisfait de Chef (on utilise la variante Chef Solo plus simple), marche super bien avec nos instances EC2. Pour le déploiement applicatif, on utilise Capistrano, encore une fois populaire chez les rubyistes. C’est une breeze à utiliser (désolé pour le discours JCVDesque). Maintenant avec l’arrivée de Docker, faudra peut-être revoir tout ça dans 1 an si ça apporte vraiment plus de facilité de déploiement, mais pour l’instant ça marche bien.

    Au niveau des instances AWS, on utilise un m3.medium pour le serveur de DB et du c3.large pour le reste. On a pas mal d’instances, du coup via Amazon VPC on utilise un subnet privé pour plus de facilité niveau sécurité, et seul les Load balancers Amazon sont publics, ainsi qu’une instance t1.micro qui sert juste de gateway quand on veut SSH dans les machines privées. On a 4 instances AWS dans notre subnet privé:
    – PrincipaleAppli1Web avec nginx+unicorn et notre principale appli1 Rails
    – PrincipaleAppli1Worker avec les delayed jobs et cron jobs
    – Appli2 qui host a la fois une appli2 et ses workers avec nginx+unicorn, appli2 Rails, delayed jobs et cron jobs
    – DB avec postgresql (contient les DB de Appli1 et 2)
    – UtilStorage avec les elasticsearch et redis pour nos Appli1 et 2

    C’est en gros l’archi prod, on a le même pour du staging.
    Ok, ça coûte pas mal au final, on pouvait faire bien moins cher avec juste une instance AWS j’imagine. Notre archi est un peu plus avancée et plus souple si on veut ajouter une deuxième instance web à la demande par exemple (même si j’en doute on n’est pas Netflix, lolz). Les sous ne sont pas un problème chez nous donc on y est allé probablement un peu loose. Je ne peux pas encore te dire combien cette transition nous coûte car le mois dernier on a payé pour pas mal d’autres instances/sites AWS secondaires et notre transition s’est passée en milieu de mois; ce sera plus facile pour moi de savoir à la fin de ce mois avec un full mois.

    Personnellement je trouve l’expérience agréable, le site est même plus rapide qu’avant. A voir au fil des mois. Peut-être que j’écrirai un blog post à ce propos, avec les tarifs exacts si ça intéresse des gens.

  5. PS: il y a énormément d’offres PaaS/IaaS/dédié, ça évolue tout le temps, et j’ai envie de dire qu’à un moment faut se lancer avec les connaissances qu’on a, faire du trial and error, et potentiellement ajuster.

    C’est pas une science exacte, et tout ce monde est encore jeune.

    Il y a des PaaS plus évolués comme peut-être CleverCloud (jamais essayé), des IaaS sympas developer-friendly comme DigitalOcean, et avec Docker il y a encore beaucoup de potentiel pour tout ce beau monde (service simplissimes d’host Docker, etc). A mon avis tout va boil down vers le service le plus simple à utiliser pour le dév/op ainsi que le moins cher, que ce soit un PaaS/IaaS/autre service qui le provide.

  6. Ouaip, il y a encore plein de choses à faire sur le sujet. Je sais que la comparaison va en faire sourire, mais ça me rappelle la première fois qu’on pouvait héberger nos petites applis PHP gratuitement fin 90. C’était une révolution, tout le monde avait enfin accès au web. On trouvait plein de blog, de forums phpbb et des t’as d’autres services communautaires (perso je faisais du fansub).
    Voir enfin des hébergements plus « évolués » avec Heroku, Playapps (mort désormais) c’était une nouvelle étape dans les possibilités offertes pour nous développeurs. Je ne doute pas que nous ne soyons qu’au début et nous aurons encore le temps de changer sur Hopwork 🙂

    Pour info, Ansible c’est du Python mais on n’écrit pas de Python dans les « playbook ». Et « l’équivalent » de Capistrano serait peut-être Fabric (mais je n’ai jamais utilisé Capistrano).

  7. Pingback: PaaS : Platform as a Service ← JavaTeam Sodifrance

  8. Pingback: Spring-boot et Ansible sont sur un bateau | Eventually Coding

  9. Pingback: PaaS : Platform as a Service | Le blog Netapsys

Laisser un commentaire