Heroku, le fournisseur de Platform-as-a-Service (PaaS), a récemment annoncé l'expansion de leur présence mondiale et présenté un ensemble de mises à jour de leur architecture. Bien que n'ayant pas d'accord de type Safe Harbor (NdT: "Sphère de Sécurité", accord USA-Europe sur la protection des données privées), Heroku est le dernier vendeur PaaS à établir leur présence en Europe. Ils ont également ajouté de nouvelles options de montée en charge verticale (*scale up*) à leurs processus cloud, de l'activité réseau isolée, et un outil pour vérifier qu'une application est prête pour la production.
Heroku - propriété de Salesforce.com - est l'un des premiers fournisseurs de services PaaS et il supporte des applications écrites en Ruby, Java, Node.js, Scala, Clojure et Python. Au lieu de déployer les applications sur des serveurs virtuels, les développeurs Heroku interagissent avec des unités de calcul appelées dynos, qui sont des conteneurs isolés qui exécutent des processus web ou de calcul. Les dynos ont traditionnellement 512 Mo de mémoire et les développeurs sont entraînés à faire monter en charge leurs applications horizontalement, via d'avantage de machines, quand la capacité d'un dyno est atteinte. Bien que Heroku soit un fournisseur de cloud computing mature connu pour son marché d'add-ons robuste de services de cloud computing et pour ses fonctionnalités innovantes telles que leurs snapshots de données appelés Dataclips, ils ont passé une bonne partie de 2013 à rétablir la confiance de leurs utilisateurs après avoir omis de divulguer les changements dans leur plateforme qui ont entraîné une faible performance et des coûts excessifs. Cependant, cette collection d'améliorations récentes de la plateforme a commencé à modifier la donne pour l'entreprise.
Dans un récent billet de blog, Heroku a annoncé l'accès aux centres de données européennes dans le cadre d'une version bêta publique. Les fonctionnalités de la plateforme disponibles en Europe correspondent à celles disponibles pour les clients américains. Heroku promet une plus faible latence pour les utilisateurs européens, tout en offrant une gestion unifiée et une expérience de déploiement indépendante de l'endroit où les développeurs et les administrateurs résident. Un sous-ensemble du marché des add-ons est disponible pour les applications européennes et beaucoup de ces add-ons sensibles à la latence sont déployés directement dans la région européenne. Heroku fournit aux développeurs un outil - appelé heroku fork - qui migre une application de la région Etats-Unis à la région européenne. Heroku rejoint d'autres fournisseurs de PaaS avec des centres de données européens, y compris Microsoft Windows Azure, Google App Engine, CloudBees et Engine Yard. Cependant, contrairement à Windows Azure et Engine Yard, le PaaS Heroku ne participe pas encore au programme Sphère de Sécurité (*Safe Harbor*) de l'UE. Selon Heroku, cette certification est en cours.
Heroku n'est pas encore un participant inscrit au programme Sphère de Sécurité. Nous avons jeté les bases pour devenir certifié Sphère de Sécurité et espérons l'être bientôt. La bêta publique de la zone Europe est conçue pour vous permettre de créer des applications de haute performance pour des utilisateurs européens. Elle n'adresse pas actuellement l'hébergement de données ou des préoccupations de juridiction. Vous devez supposer que certaines parties de votre application et ses données seront sur, ou passeront au travers, des datacenters situés aux États-Unis.
Heroku est également en train de changer la façon dont les applications montent en charge sur leur plate-forme. Avec l'introduction de dynos 2x, les développeurs d'applications peuvent désormais provisionner des unités de calcul avec 1 Go de mémoire et deux fois le CPU d'un dyno traditionnel. Dans un billet de l'équipe Heroku, ils fournissent trois cas d'utilisation pour une montée en charge verticale.
- La concurrence pour Rails avec Unicorn - Le premier cas d'utilisation est l'augmentation de la concurrence sur les applications Rails mono-thread utilisant Unicorn. En raison de l'amélioration de l'efficacité de la mise en file d'attente des dynos qui résulte de l'augmentation du nombre de workers Unicorn, doubler les workers dans les dynos 2X tout en réduisant de moitié le nombre de dynos se traduit souvent par une meilleure performance.
- Les langages de la JVM - La JVM moderne dispose d'un modèle de mémoire explicite conçu pour la concurrence multi-thread, et a de nombreux frameworks explicitement conçus pour tirer parti de cette propriété. Utiliser plus de threads nécessite plus de mémoire à la fois pour les piles de threads et les objets créés par ces threads. La JVM est pleinement capable de tirer parti de la dimension verticale dans un dyno 2X.
- Les tâches de fond gourmandes en mémoire- le traitement d'image et le traitement géospatial ont souvent besoin de dynos plus importants. Si vous avez reçu une erreur out-of-memory R14 et que ce n'est pas une fuite mémoire, les dynos 2X pourraient être faites pour vous.
Toutes les applications ne bénéficieront pas de la puissance de calcul et de la mémoire supplémentaires, et Heroku encourage les développeurs à utiliser une variété d'outils pour découvrir si la dimension horizontale ou verticale améliorera les performances de l'application. Heroku met en évidence le tableau de bord open-source log2viz qui montre les consommations de mémoire et de CPU, et un add-on de New Relic, leader des fournisseurs de Gestion de Performance des Applications, pour identifier les problèmes de concurrence.
Le modèle de réseau offert par Heroku est également en train de changer. Auparavant, les dynos partageaient des interfaces réseau, ce qui provoquait ce qu'ils décrivaient comme une "fuite d'information de bas niveau" où les dynos pouvaient observer des détails de connexion provenant d'autres dynos. C'est terminé. Heroku propose désormais des configurations réseau entièrement isolées pour chaque dyno, comme décrit dans un article de blog.
Pour un réseau local dans un dyno, les processus peuvent maintenant écouter et se connecter sur les ports qu'ils souhaitent. Cela vous permet d'utiliser les interfaces du réseau local pour envoyer des données entre les processus s'exécutant dans un même dyno. Les interfaces réseau d'un dyno sont protégées à la manière d'un firewall des accès réseau externes, y compris d'autres dynos Heroku. Pour un dyno web, le seul accès réseau externe autorisé est sur le port TCP spécifié dans la variable d'environnement
$PORT. C'est le port utilisé par le router de Heroku pour transmettre les requêtes HTTP au dyno.
Heroku a fait ce changement pour tous les dynos et clame qu'aucune mise à jour n'est nécessaire pour les applications en cours d'exécution. Cependant, ils admettent que quelques bugs se sont glissés mais ils ont rapidement émis des composants mis à jour pour que les développeurs les utilisent.
Enfin, Heroku a présenté le Production Check qui surveille les applications et vérifie si les meilleures pratiques ont été appliquées. Les applications sont testées pour la redondance de dynos, l'exactitude des paramètres DNS et SSL, l'utilisation d'une base de données Postgres Heroku pour la production, et un monitoring et un système de logs correctement configurés. Bien que ce processus de vérification optionnel est loin d'être exhaustif, il offre un précieux service aux développeurs qui peuvent ne pas être familiers avec le déploiement d'application compatible cloud, sur un PaaS distribué et public.