5 raisons stupides pour lesquelles vous n'utilisez pas Heroku

Russell Smith est cofondateur et directeur technique de Rainforest QA.

Quand je dis à d'autres directeurs techniques et ingénieurs que nous comptons beaucoup sur Heroku pour gérer notre entreprise, ils ont invariablement la même réaction: pourquoi? Pourquoi pas AWS? Est-ce que tu plaisantes? Avez-vous entendu parler de Google Cloud? Es-tu un idiot?

Cela se produit sans faute. Avec. En dehors. Échouer. L'argument est généralement le suivant: pourquoi payer plus cher un PaaS alors que vous pouvez le créer vous-même sur Google ou AWS - et l'avoir exactement comme vous le souhaitez? À quoi je dis: Poppycock. Ces personnes manquent des avantages réels du PaaS, et peut-être aussi d'un sens économique de base.

Nous utilisons largement Heroku à Rainforest QA depuis début 2012 pour exécuter notre service de test automatisé de QA. Nous déployons presque tout dans Heroku - pour la production, la préparation et le contrôle qualité pour la plupart des applications. C'est stable, cela a du sens sur le plan économique et cela répond précisément à nos besoins.

Voici les principaux arguments que j'entends contre Heroku et pourquoi je pense qu'ils sont (pour la plupart) fallacieux.

#1. Heroku est NIH (non inventé ici)

S'il n'est pas assemblé avec amour par notre équipe, il ne peut pas être parfait pour nous, donc ce n'est pas assez bon. La valeur par défaut de nos jours est d'utiliser AWS (qui, soit dit en passant, est également NIH), puis d'embaucher des personnes pour reconstituer l'infrastructure actuellement à la mode, my-startup-is-a-snowflake. Cette ligne de pensée présente plusieurs défauts:

  • Votre équipe d'ingénierie n'a pas le temps d'acquérir les compétences et de faire le travail correctement, à moins que vous n'embauchiez des personnes supplémentaires extrêmement intelligentes.
  • Vous ne pouvez pas embaucher d'autres personnes extrêmement intelligentes. Les gens formidables sont très chers, difficiles à trouver et travaillent probablement déjà ailleurs.
  • Il est rarement nécessaire de créer une infrastructure une seule fois. Lorsque vos besoins changent, vous devrez tout recommencer.
  • Votre infrastructure personnalisée ne sera pas testée au combat tant que VOUS ne l'avez pas testée au combat. Ou plutôt, jusqu'à ce que vos clients et ingénieurs l'aient fait. Ne leur faites pas subir ça. Ne le fais pas.

Si vous pensez pouvoir embaucher les meilleures personnes pour reconstituer votre infrastructure, vous vous moquez de vous. Mais même si vous le pouviez, le temps que vous passez à construire cette infrastructure fait rarement, voire jamais, avancer votre produit (à moins que l'infrastructure elle-même ne fasse partie intégrante de votre offre).

Voici pourquoi je préfère mon itinéraire:

  • Heroku nous permet de nous concentrer sur ce que nous faisons de mieux: créer une plate-forme d'assurance qualité automatisée.
  • Se voir imposer certaines limites architecturales peut en fait être une bonne chose. Ils vous libèrent de la paralysie du choix et de l'analyse.
  • Heroku ajoute constamment des fonctionnalités qui font réellement avancer notre produit.

Voici quelques-unes des fonctionnalités Heroku que nous aimons:

  • Postgres haute disponibilité
  • Le chiffrement pour Postgres est activé par défaut
  • Drains de journaux (un moyen standard de collecter et de transférer des journaux)
  • Examiner les applications (qui exécutent le code dans n'importe quelle demande d'extraction GitHub dans une application complète et jetable sur Heroku)
  • Le marché des modules complémentaires Heroku

Un ajout majeur récent qui mérite d'être mentionné est Heroku Shield, qui nous donne un BAA (accord d'associé commercial pour la conformité HIPAA de Salesforce.com. Il a quelques problèmes de démarrage, mais si nous devions établir la conformité HIPAA nous-mêmes, il faudrait quelques ingénieurs pour mois ou plus de travail. Au lieu de cela, ces ingénieurs font progresser notre produit et rendent nos clients plus heureux.

# 2. PaaS est trop cher

Mais Heroku est tellement cher! Ceci est une réflexion collective et ignore le coût de la recherche, du recrutement et de la formation de grands développeurs pour construire et entretenir votre infrastructure de flocon de neige. Sans parler du coût de rétention de ces personnes, de les mettre dans un bureau et de fournir des tables de ping-pong ou tout ce qu'il faut pour les garder heureux.

Ensuite, il y a le coût d'opportunité de l'embauche de personnes dans des rôles devops et sysadmin au lieu de l'ingénierie produit. Et ces coûts augmentent de manière linéaire à mesure que votre entreprise évolue. Avec Heroku, vous avez des coûts marginaux décroissants à grande échelle.

Et n'oubliez pas le coût supplémentaire de votre manque de concentration. Si vous avez des problèmes d'infrastructure périphérique, vous n'êtes pas concentré sur l'amélioration de votre produit.

Payer Heroku signifie que vous n'avez pas à vous soucier de la construction de votre infrastructure et de sa disponibilité à tout moment - et cela coûte toujours autant ou moins cher que d'embaucher et de retenir ces opérateurs supplémentaires.

# 3. Le PaaS est trop contraignant

Mais… mais… mon flocon de neige! Beaucoup de gens pensent que leur application ou leur architecture a des besoins uniques. Dans la plupart des cas, ce n'est pas le cas - et si c'est le cas, cela ne devrait probablement pas. Cependant, je suis prêt à accepter quelques raisons légitimes pour lesquelles vous ne pourrez peut-être pas utiliser Heroku. Les voici:

  • Vous avez besoin de tonnes de CPU ou de RAM. Heroku ne va pas aussi loin qu'AWS et les configurations sont un peu moins flexibles. Si vous avez vraiment besoin de milliers de serveurs, AWS (ou même bare metal) peut être plus économique. Mais Heroku prend en charge des instances assez importantes. Pour la plupart des gens, cela devrait être plus que suffisant.
  • Vous avez besoin de serveurs bare metal ou de processeurs spécialisés. Si vous effectuez un apprentissage automatique ou un autre travail intensif en GPU, Heroku n'est peut-être pas une solution idéale. Cependant, vous pouvez toujours adopter une approche hybride comme nous le faisons. Nous utilisons Heroku, mais aussi des serveurs bare-metal pour obtenir les meilleures performances de notre plateforme de virtualisation.
  • Vous avez besoin d'un RPC non HTTP, tel que gRPC. Tout trafic entrant qui n'est pas WebSocket, HTTP ou HTTPS n'est pas pris en charge par le routeur Heroku aujourd'hui.
  • Vous ne pouvez pas travailler dans les modèles d'application pris en charge. Par exemple, si vous avez besoin de communications entre nœuds, afin qu'un groupe de serveurs d'applications puisse se comporter comme un pour quelque chose comme Erlang ou Elixir, ou si vous avez besoin d'une configuration de routage unique, Heroku n'est pas pour vous.

Il peut y avoir plusieurs autres raisons, mais elles ne sont souvent pas essentielles à votre entreprise. Si vous pouvez concevoir votre application pour l'adapter au modèle Heroku, vous bénéficiez de nombreux avantages. Le principal est la cohérence entre les applications, du déploiement à la surveillance, en passant par la journalisation et la mise à l'échelle.

# 4. Heroku ne fait pas Docker

Mais je dois avoir Docker! Ne vous inquiétez plus. Depuis début septembre, vous pouvez déployer des images Docker sur Heroku. Même avant cela, Heroku incluait des fonctionnalités quelque peu similaires à Docker, vous permettant d'expédier des versions conteneurisées de votre application. Cela ne correspond pas à la fonctionnalité Docker pour la fonctionnalité, mais vous pouvez penser à Heroku comme étant une version hébergée et gérée de Docker. En tout cas, cette inquiétude a disparu.

# 5. Heroku n'est pas assez sécurisé

Mais Heroku n'est pas en sécurité! LOL. À moins que vous ne soyez dans un secteur fortement réglementé, comme la finance, ou que vous ayez besoin d'une certification particulière qui n'est pas prise en charge par Heroku, cela ne devrait pas être un problème. Il n'y a aucune raison de croire qu'Heroku est significativement moins sécurisé qu'AWS. Il dispose de toute une équipe dédiée à la gestion de la sécurité de sa plateforme; le faites vous? De plus, vous allez prendre une tonne de décisions ponctuelles pendant le déploiement de votre propre infrastructure, dont aucune n'aura été testée. Heroku a pris ces décisions bien avant vous, et elles ont été testées à une échelle que la plupart des entreprises ne peuvent qu'imaginer.

De plus, contrairement à votre environnement personnalisé, Heroku est cohérent et uniforme. Il a des limites qui sont clairement définies, ce qui signifie que votre surface d'attaque sera plus petite. Cela signifie également que c'est plus facile à comprendre, de sorte que vous êtes moins susceptible de faire quelque chose par accident qui crée une vulnérabilité.

Et en passant, les ingénieurs aiment un environnement de déploiement cohérent, pour toutes sortes de raisons en plus de la sécurité. 

En fin de compte, chaque entreprise doit prendre la meilleure décision pour son entreprise et ses clients. Mais rappelez-vous que ces clients ne se soucient pas de savoir si vous êtes sur une œuvre d'art de pointe ou un PaaS à usage général. Ils se soucient que votre service fonctionne, qu'il s'améliore avec le temps et que vous ne soyez pas piraté. Heroku a très bien fonctionné pour nous, et ce serait probablement le cas pour vous.

-

New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à  [email protected] .