5 tontas razones por las que no estás usando Heroku

Russell Smith es cofundador y director de tecnología de Rainforest QA.

Cuando les digo a otros directores de tecnología e ingenieros que dependemos en gran medida de Heroku para administrar nuestro negocio, siempre tienen la misma reacción: ¿Por qué? ¿Por qué no AWS? Estas bromeando ¿Has oído hablar de Google Cloud? ¿Eres un idiota?

Esto sucede sin falta. Con. Afuera. Fallar. El argumento suele ser algo como esto: ¿Por qué pagar más por una PaaS cuando puede crearla usted mismo en Google o AWS y tenerla tal como la desea? A lo que digo: Poppycock. Estas personas están perdiendo los beneficios reales de PaaS y quizás también algún sentido económico básico.

Hemos estado utilizando Heroku ampliamente en Rainforest QA desde principios de 2012 para ejecutar nuestro servicio automatizado de pruebas de control de calidad. Implementamos casi todo en Heroku: para producción, preparación y control de calidad para la mayoría de las aplicaciones. Es estable, tiene sentido económico y se adapta precisamente a nuestras necesidades.

Estos son los principales argumentos que escucho contra Heroku, y por qué creo que son (en su mayoría) falaces.

# 1. Heroku es NIH (no inventado aquí)

Si nuestro equipo no lo ensambla con amor, no puede ser perfecto para nosotros, por lo tanto, no es lo suficientemente bueno. El valor predeterminado en estos días es usar AWS (que, por cierto, también es NIH), luego contratar personas para reconstruir la infraestructura actual, my-startup-is-a-snowflake. Esta línea de pensamiento tiene varios defectos:

  • Su equipo de ingenieros carece de tiempo para aprender las habilidades y hacer el trabajo correctamente, a menos que contrate personas adicionales que sean extremadamente inteligentes.
  • No puede contratar personas adicionales que sean extremadamente inteligentes. Las personas excelentes son muy caras, difíciles de encontrar y probablemente ya estén trabajando en otro lugar.
  • Rara vez necesita construir una infraestructura solo una vez. Cuando sus necesidades cambien, tendrá que volver a construirlo.
  • Su infraestructura personalizada no será probada en batalla hasta que USTED la haya probado en batalla. O mejor dicho, hasta que sus clientes e ingenieros lo hayan hecho. No los hagas pasar por eso. Simplemente no lo hagas.

Si cree que puede contratar a las mejores personas para reconstruir su infraestructura, se está engañando a sí mismo. Pero incluso si pudiera, el tiempo que dedica a la construcción de esta infraestructura rara vez, o nunca, hace avanzar su producto (a menos que la infraestructura en sí sea una parte central de su oferta).

He aquí por qué prefiero mi ruta:

  • Heroku nos permite enfocarnos en lo que hacemos mejor: construir una plataforma de control de calidad automatizada.
  • Tener algunas limitaciones arquitectónicas impuestas puede ser algo bueno. Te liberan de la parálisis de elección y análisis.
  • Heroku agrega constantemente características que realmente hacen avanzar nuestro producto.

Estas son solo algunas de las características de Heroku que nos encantan:

  • Postgres de alta disponibilidad
  • El cifrado para Postgres está activado de forma predeterminada
  • Desagües de registros (una forma estándar de recopilar y reenviar registros)
  • Revisar aplicaciones (que ejecutan el código en cualquier solicitud de extracción de GitHub en una aplicación completa y desechable en Heroku)
  • El mercado de complementos de Heroku

Una adición importante reciente que vale la pena mencionar es Heroku Shield, que nos otorga un BAA (acuerdo de socio comercial para el cumplimiento de HIPAA de Salesforce.com. Tiene algunos problemas iniciales, pero si tuviéramos que construir el cumplimiento de HIPAA nosotros mismos, necesitaríamos un par de ingenieros mes o más de trabajo. En cambio, esos ingenieros están haciendo avanzar nuestro producto y haciendo que nuestros clientes sean más felices.

# 2. PaaS es demasiado caro

¡Pero Heroku es taaaan caro! Este es un pensamiento colectivo e ignora el costo de encontrar, reclutar y capacitar a excelentes personas de DevOps para construir y mantener su infraestructura de copos de nieve. Sin mencionar el costo de retener a estas personas, ponerlas en una oficina y proporcionarles mesas de ping pong o cualquier otra cosa que sea necesaria para mantenerlas felices.

Luego está el costo de oportunidad de contratar personas en roles de devops y sysadmin en lugar de ingeniería de productos. Y esos costos aumentan linealmente a medida que su negocio se amplía. Con Heroku, tiene costos marginales decrecientes a escala.

Y no olvide el costo adicional de su falta de concentración. Si está lidiando con asuntos de infraestructura periférica, no está enfocado en mejorar su producto.

Pagar a Heroku significa que no tiene que preocuparse por construir su infraestructura y mantenerla disponible en todo momento, y todavía cuesta lo mismo o menos que contratar y retener a esas personas de operaciones adicionales.

# 3. PaaS es demasiado restrictivo

Pero ... pero ... ¡mi copo de nieve! Mucha gente piensa que su aplicación o arquitectura tiene necesidades únicas. En la mayoría de los casos, no es así, y si lo hace, probablemente no debería. Sin embargo, estoy dispuesto a aceptar algunas razones legítimas por las que es posible que no pueda utilizar Heroku. Aquí están:

  • Necesitas toneladas de CPU o RAM. Heroku no escalará tan lejos como AWS y las configuraciones son un poco menos flexibles. Si realmente necesita miles de servidores, AWS (o incluso bare metal) puede resultar más económico. Pero Heroku admite algunos casos bastante importantes. Para la mayoría de las personas, debería ser más que suficiente.
  • Necesita servidores bare-metal o procesadores especializados. Si está haciendo aprendizaje automático u otro trabajo intensivo en GPU, es posible que Heroku no sea una buena opción. Sin embargo, aún puede adoptar un enfoque híbrido como lo hacemos nosotros. Utilizamos Heroku, pero también servidores bare-metal para obtener el mejor rendimiento para nuestra plataforma de virtualización.
  • Necesita RPC que no sea HTTP, como gRPC. En la actualidad, el enrutador Heroku no admite el tráfico entrante que no sea WebSocket, HTTP o HTTPS.
  • No puede trabajar dentro de los modelos de aplicaciones compatibles. Por ejemplo, si necesita comunicaciones internas, para que un grupo de servidores de aplicaciones pueda comportarse como uno para algo como Erlang o Elixir, o si necesita una configuración de enrutamiento única, Heroku no es para usted.

Puede haber algunas otras razones, pero a menudo no son esenciales para su negocio. Si puede diseñar su aplicación para que se ajuste al modelo Heroku, obtendrá muchos beneficios. El principal es la coherencia entre las aplicaciones, desde la implementación hasta la supervisión, el registro y el escalado.

# 4. Heroku no hace Docker

¡Pero debo tener Docker! No te preocupes más. Desde principios de septiembre, puede implementar imágenes de Docker en Heroku. Incluso antes de eso, Heroku incluyó capacidades algo similares a Docker, lo que le permite enviar compilaciones de su aplicación en contenedores. No coincidía con la función de Docker por función, pero podría pensar en Heroku como una versión alojada y administrada de Docker. En cualquier caso, esa preocupación ha desaparecido.

# 5. Heroku no es lo suficientemente seguro

¡Pero Heroku no es seguro! LOL. A menos que esté en una industria fuertemente regulada, como las finanzas, o necesite una certificación en particular que no sea compatible con Heroku, esto no debería ser un problema. No hay razón para creer que Heroku sea significativamente menos seguro que AWS. Tiene todo un equipo dedicado a gestionar la seguridad de su plataforma; ¿Vos si? Además, va a tomar un montón de decisiones únicas mientras está implementando su propia infraestructura, ninguna de las cuales habrá sido probada. Heroku tomó estas decisiones mucho antes que usted, y se han probado a una escala que la mayoría de las empresas solo pueden imaginar.

Además, a diferencia de su entorno personalizado, Heroku es consistente y uniforme. Tiene límites claramente definidos, lo que significa que su superficie de ataque será más pequeña. Eso también significa que es más fácil de entender, por lo que es menos probable que haga algo por accidente que cree una vulnerabilidad.

Y, por cierto, a los ingenieros les encanta un entorno de implementación coherente, por todo tipo de razones además de la seguridad. 

En última instancia, toda empresa debe tomar la mejor decisión para su negocio y sus clientes. Pero recuerde, a esos clientes no les importa si está en una obra de arte local de vanguardia o en una PaaS de propósito general. Les importa que tu servicio funcione, que mejore con el tiempo y que no te pirateen. Heroku ha funcionado muy bien para nosotros, y probablemente lo haría para ti.

-

New Tech Forum proporciona un lugar para explorar y discutir la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra selección de las tecnologías que creemos que son importantes y de mayor interés para los lectores. no acepta material de marketing para su publicación y se reserva el derecho de editar todo el contenido contribuido. Envíe todas sus consultas a  [email protected] .