Environnement d’application: ce que nos développeurs de rails préfèrent maintenant

by Elixir Consultant

• 0
• 12.1K
• Uncategorized

Environnement d’application: ce que nos développeurs de rails préfèrent maintenant

Rails Developers – Discussion sur l’environnement

Rails Les développeurs veulent toujours faire les choses avec style. Cela a toujours été une question classique, ce qui est bon pour les développeurs de Ruby on Rails: AWS ou Heroku. La même discussion est en cours dans notre société, parmi les développeurs de Rails depuis un moment et je pourrais dire qu’il s’agit d’un débat sans fin. Mais en travaillant avec différents développeurs Ruby on Rails de différentes origines et expériences, je pouvais constater un certain nombre de points échangés au cours des discussions. J’essaie de consolider ces points communs dans cet article de blog.

Rails Developers – AWS VS HEROKU

Tout d’abord, permet de comprendre le fait que comparer AWS et Heroku n’est pas une comparaison de pomme à pomme. AWS est IaaS (infrastructure en tant que service) et Heroku est PaaS (plate-forme en tant que service). Quelle est la différence? IaaS offre un ensemble de composants dont un développeur a besoin pour créer une application par dessus. PaaS fournit un environnement prêt au déploiement, dans lequel le développeur doit déplacer le code avec un minimum de modifications de configuration pour que l’application fonctionne. IaaS a besoin de plus de compétences pour être déployé, mais PaaS permet au développeur de se concentrer davantage sur le code.
AWS propose en fait une offre PaaS: «Elastic Beanstalk», qui prend en charge Ruby, Node.js, PHP, Python, .NET et Java, mais la majorité de la foule saute autrement, gardant ainsi AWS PaaS en dehors de toute discussion / comparaison.

Composants d’environnement – Vue développeur Rails:

Du point de vue du développeur Ruby on Rails, ils utilisent principalement les composants suivants.
AWS concerne les instances EC2, S3, l’équilibreur de charge, la couche de cache, Apache, Passenger, Ruby, Rails, PostgreSql… tout ce dont un développeur Ruby on Rails a besoin pour se développer / se déployer, pour être configuré individuellement. Enfin, le développeur Ruby on Rails doit implémenter un système de déploiement tel que Capistrano et plus sur le système de journalisation.
Heroku, il ne s’agit pas de configurer des composants individuels. Rails Developers doit modifier quelques lignes de code dans l’application, faire les add-ons nécessaires, faire un git-push; c’est ça.

Security Horizon – Rails Developer View:

Dans AWS, la plupart des mises à jour de sécurité et des correctifs consistent à le faire manuellement par les développeurs Rails, quand et où cela est requis. Il y a de bonnes chances que cette activité soit mal gérée et que les serveurs de production soient bien en retard sur les mises à jour de sécurité. Avec Heroku, les mises à jour de sécurité appartiennent à la plate-forme mais pas aux développeurs Rails. Il y a des opinions mitigées sur la prise de responsabilité de Heroku et des cas où l’activité va à l’encontre du code déployé, mais il est certain que cela enlève beaucoup de problèmes à Rails Developers.

Application de mise à l’échelle – Vue développeur Rails:

J’ai expliqué comment un développeur Ruby on Rails implémente généralement l’environnement dans sa comparaison IaaS vs PaaS ci-dessus. Approximativement, l’application a un Procfile, qui a des lignes de la forme dyno_type: command_to_run, donc par exemple (voir http://devcenter.heroku.com/articles/process-model):
web: bundle exec sur serveur serveur: bundle exec travaux de travail: travail
Ceci, avec un:
heroku scale web: 4 travailleurs: 15
vous aurez alors 4 dynos Web et 15 dynos de travailleurs en cours d’exécution. Notez que le Web est un type de dyno spécial, qui a accès au monde extérieur et se trouve derrière son joli multiplexeur de trafic Web qui acheminera le trafic en conséquence.

Facteur de coût:

Encore une fois, il n’est pas correct de comparer AWS et Heroku sur le facteur coût. Bien que le coût d’utilisation de l’environnement Heroku soit 100% plus coûteux que celui d’AWS, le temps et les efforts nécessaires ont davantage compté pour EC2 que pour Dyno. Il n’est probablement pas déraisonnable de considérer un dyno comme un peu comme une micro-instance EC2. Mais le temps et les efforts requis par le développeur Ruby on Rails pour créer un environnement en plus d’une offre IaaS pour le rendre conforme à la norme PaaS ne sont certainement pas faciles et bon marché. Soyons également d’accord sur les coûts associés à la main-d’œuvre requise pour la mise en place d’un environnement et son maintien.

Conclusion:

Heroku et AWS sont d’excellentes plates-formes. Les développeurs de Ruby on Rails souhaitent désormais se concentrer davantage sur le “Code” que sur l’environnement. La plupart d’entre eux préfèrent donc travailler sur Heroku pour le développement, les tests, la mise en scène et la production. Mais pour un «déploiement de production sérieux» avec plusieurs clients payants avec une configuration d’application complexe, avec un contrat de niveau de service à maintenir, avec du temps dédié sur le Dev-Ops, etc. AWS serait le choix. AWS ou Heroku constituent la plate-forme gagnante, celle qui aide le plus les développeurs de Rails à atteindre leurs objectifs, les rend heureux et productifs. tout en restant suffisamment abordable pour être durable. Rails Developers – Happy Coding !!!!