¿Cuáles son los pros y los contras de AWS Elastic Beanstalk en comparación con otras estrategias de implementación?


17

Soy bastante nuevo en todo el stack de Netflix OSS y en las implementaciones en general. Como antecedentes de mi nivel actual de conocimiento en operaciones, mi papel principal es como ingeniero de aplicaciones front-end. Sin embargo, disfruto del lado operativo de las cosas, por lo que intento configurar una nueva estrategia de implementación y las herramientas para un nuevo proyecto.

Nuestras metas

  • Implementaciones súper fáciles (queremos presionar un botón para actualizar la producción)
  • Implementaciones automatizadas para probar entornos (usando Jenkins)
  • Facilidad de mantenimiento (tenemos una aplicación para escribir, no queremos pasar nuestro tiempo jugando con problemas de producción)
  • Capacidad para manejar una arquitectura orientada a servicios (muchas aplicaciones pequeñas, varios idiomas y almacenes de datos)
  • Suficiente flexibilidad para garantizar que no tengamos que cambiar las estrategias en el corto plazo (ya estamos tratando de alejarnos de RightScale)

Estamos de acuerdo con un poco más de tiempo de configuración inicial si hacerlo nos ahorrará algunos dolores de cabeza en el futuro.

Entonces, en esta línea, he estado escuchando podcasts, viendo charlas de operaciones y leyendo toneladas de publicaciones de blog y, en función de nuestros objetivos y lo que he considerado como mejores prácticas de formación, hemos comenzado a elaborar un plan utilizando Asgard, enrollando nuestro paquete en un frasco y convirtiéndolo en un AMI.

Todo esto estaba planeado y nos gustan las ventajas del proceso en comparación con el uso de un servidor Chef y las instancias convergentes sobre la marcha (sentimos que esto era propenso a errores dada nuestra línea de tiempo limitada y la falta de comprensión sobre el flujo de trabajo del servidor Chef). Sin embargo, un compañero de trabajo miró un poco por su cuenta y sintió que Elastic Beanstalk satisfizo nuestras necesidades.

Lo he examinado y he creado un entorno de prueba con un archivo WAR y una base de datos RDS adjunta. Las cosas parecen funcionar y creo que podemos automatizar las implementaciones en un entorno de prueba utilizando Jenkins a través de la API de AWS. Parece bastante simple ... tal vez demasiado simple.

Lo que me pregunto es, ¿cuál es el problema? Si Elastic Beanstalk es tan simple y efectivo, ¿por qué no se habla más? Me cuesta encontrar suficientes opiniones objetivas y datos sobre las dos estrategias de implementación diferentes, así que pensé en preguntar.

¿Usas Elastic Beanstalk? Si es así, ¿por qué y qué factores conducen a esa decisión? ¿Qué te gusta y qué no te gusta?

Si no usa Elastic Beanstalk pero lo consideró, ¿qué usa y por qué no usó Elastic Beanstalk?

¿Cuáles son las ventajas y desventajas de una estrategia de implementación basada en Elastic Beanstalk para una SOA? Es decir, ¿Elastic Beanstalk funcionará bien con muchas aplicaciones pequeñas que dependen unas de otras para funcionar?

Respuestas:


11

He evaluado Elastic Beanstalk además de otras ofertas de AWS al intentar mejorar nuestras instancias de AWS enrolladas a mano. Las razones por las que elegí no usarlo se debieron a complicaciones que surgirían al migrar mi aplicación existente y no con la oferta en sí. El problema es que no tienes tanto control sobre la implementación / configuración de la aplicación de los servidores. Si está comenzando una nueva aplicación, puede ser útil no tratar esas cosas en este momento, si tiene una aplicación existente, entonces es más difícil encajar en el modelo Beanstalk.

Beanstalk ofrece una oferta similar para Heroku y otros proveedores de PaaS, pero no es un gran beneficio para aquellos que solo quieren enfocarse en hacer su aplicación. Al menos puede determinar los recursos virtualizados en mayor grado que otros proveedores de PaaS.

Problemas con los que me encontraba con mis aplicaciones:

  • Implementaciones basadas en Git: me encantan pero nuestro repositorio es 1+ GB. Bastante grande para empujar de forma regular. Este repositorio también contiene alrededor de 40 aplicaciones (que realmente deberían dividirse), pero eso llevaría algún tiempo. Cargar cualquier tipo de paquete podría funcionar, pero la mayoría de nuestras aplicaciones requerirían una gran cantidad de trabajo para convertirlo en un paquete.

  • Integración con otros servicios: por lo que he visto, Beanstalk asume que todo lo que está conectando es un servicio único. Esto funciona bien si sus servicios están atrasados ​​y ELB pero nuestros nodos estaban separados y atacamos a través de HAProxy que se ejecuta en cada servidor de aplicaciones. Si está ejecutando sus almacenes de datos y otros servicios como un único punto final, debería estar bien.

En mi evaluación también incluí OpsWorks y CloudFormation. OpsWorks tiene problemas de integración similares con el funcionamiento de la automatización existente para estas aplicaciones. CloudFormation no hizo mucho más de lo que algunos scripts de Python y Chef ya se ocupaban de nosotros.

Terminé eligiendo usar AWS Autoscaling Groups en su lugar con algo de automatización proporcionada por Asgard . Este fue el cambio más pequeño en el código de configuración / aplicación existente y nos proporcionó los beneficios que estábamos buscando, la administración simple de múltiples servidores disponibles a través de la API de AWS.

Las restricciones establecidas por Elastic Beanstalk en su aplicación son muy útiles. Deberá asegurarse de que su aplicación no tenga estado, proporcione un punto final para un servicio y dependa de otros servicios para el estado. Si está intentando hacer servicios independientes reutilizables, múltiples aplicaciones en Beanstalk es un gran comienzo.

Si / cuando llegas al punto de querer más configuración, OpsWorks es un gran próximo paso. Los roles predefinidos deberían facilitar el comienzo de la transición y proporciona un marco de automatización en torno a Chef para ayudar a coordinar el aprovisionamiento de varios servidores.


2
Gran respuesta, Philip. Parece que la mayor limitación para Elastic Beanstalk es cualquiera que sea la base que AMI haya configurado. Entonces, sí, para un servicio básico sin estado parece ser excelente. Sin embargo, una vez que necesite ejecutar múltiples servicios (p. Ej., Nginx, monitoreo especializado) dentro de una sola instancia, debe desplegar su propia AMI y luego perder las actualizaciones automáticas de la AMI base para los servicios de AWS. En ese punto, ya estás en un proceso de implementación personalizado. Creo que ese es el momento en que querrías considerar alejarte de EB.
James van Dyke

0

Sí veo el punto de pérdida de control, pero no necesariamente veo la apatridia obligatoria. Todo lo que eb realmente hace es implementar la automatización, que por cierto es increíble. Sí veo el punto de un gran repositorio. En general, creo que separar las funciones lógicas de la aplicación en aplicaciones de beans separadas, y luego tener entornos de "puesta en escena" y "producción" debajo, es realmente agradable. Tenemos entornos de módulos como el cargador, no hace mucho y, en teoría, agrega muchos costos, pero luego está utilizando instancias más pequeñas, solo un poco más. Ejecutamos un nginx centralizado y tuvimos que escribir una gran cantidad de identificadores de mensajes sns personalizados para notificar a ngnix los cambios en la política de escala automática. Otro gran problema de eb es la incapacidad de desactivar los equilibrios de carga, ya que usamos ngnix, ¿por qué? elb no es compatible con websocket.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.