Una introducción a Amazon Fargate: qué es, por qué es increíble (y no) y cuándo usarlo.

Cuando Amazon anunció Fargate a fines de 2017 en AWS re: Invent (junto con EKS), realmente pasó desapercibido. Ninguno de los blogs o influencers que estaba siguiendo en ese momento realmente hablaba de eso más que algo como:

Ah, sí, y hay algo nuevo que permitirá a los usuarios de ECS ejecutar contenedores directamente en la nube.

Como desarrollador, eso realmente me dejó alucinado. Veamos por qué.

El boom de la productividad

Siento que ha habido cinco grandes revoluciones en el mundo del desarrollo de software que aumentaron dramáticamente la productividad y la capacidad de los desarrolladores para escribir e implementar aplicaciones de nivel de producción con la máxima eficiencia.

Todos ellos también resolvieron problemas importantes. Aquí está mi desglose de las revoluciones y los problemas que resolvieron:

  • Emergencia de servicios en la nube (IaaS)

    Costo de infraestructura y escalabilidad

  • Comunidad de código abierto, conferencias, talleres, blogs de tecnología, desbordamiento de pila, etc.

    Acceso limitado al conocimiento

  • Sistemas de control de versiones, herramientas de colaboración, herramientas de integración continua

    Ingeniería concurrente Discrepancia de sistemas e integración infernal

  • Arquitectura en contenedores

    Dificultad para crear aplicaciones en entornos inconsistentes

  • Servicios informáticos sin servidor (PaaS)

    Administración de servidores y sistemas

Todas y cada una de estas revoluciones tienen un rasgo común: todas dan más control a los ingenieros de software. Lo hacen fomentando las buenas prácticas y el uso compartido de código con un flujo de trabajo colaborativo, y reducen la necesidad de costosos servidores dedicados, administradores de sistemas, DevOps, soporte de TI, etc.

Genial, pero espera, ¿dónde está Fargate en todo esto?

Tu barco es el problema

Vea, cuando Docker llevó los contenedores a las masas, rápidamente se convirtió en un nuevo estándar en desarrollo y fue ampliamente adoptado.

Poco después, y tras el éxito de Kubernetes , AWS lanzó su propio servicio de administración de contenedores (más básico): Amazon Elastic Container Service (ECS). Introdujo el concepto de Tareas.

Una tarea puede ser cualquier instancia de contenedores trabajando juntos. Desde una aplicación web que ejecuta un servidor web, varios microservicios, una base de datos y un proxy inverso, hasta una lista de lotes de scripts de shell que se ejecutarán periódicamente.

Al ser uno de los primeros en adoptar ECS, realmente me gustó y funcionó muy bien durante un tiempo. Pero finalmente, tener que administrar estas capas adicionales (tareas y contenedores) en lugar de solo instancias EC2 se volvió cada vez más complicado.

Tampoco me sentía cómodo con su seguridad . Cuantas más capas tenga en su pila, más debe estar atento. Cada una de estas capas genera una mayor complejidad junto con una mayor probabilidad de errores de configuración y vulnerabilidades de seguridad.

De hecho, con ECS, sus contenedores se ejecutan en instancias de contenedores EC2 en un clúster que configurará para el escalado automático. Cada instancia puede albergar varias tareas diferentes. Cada tarea puede ejecutar varios contenedores.

Debido a que sus tareas se implementarán aleatoriamente (de forma predeterminada) en el mismo tipo de instancias EC2 con recursos disponibles , se enfrenta a los siguientes problemas:

  • Un clúster sigue las mismas reglas para el escalado automático y aprovisiona automáticamente el mismo tipo de instancias EC2.
  • Algunos contenedores necesitarán recursos totalmente diferentes pero aún tendrán que trabajar juntos.
  • Algunos contenedores no siguen necesariamente las mismas reglas para el ajuste de escala automático.
  • A veces, varios contenedores en la misma tarea necesitan su propio equilibrador de carga y no es posible tener varios equilibradores de carga para la misma tarea.

La solución alternativa preferida al enfrentar estos problemas fue:

  • Implemente manualmente algunas de sus instancias con diferentes recursos según la necesidad.
  • adjunte estas instancias a su clúster
  • ejecutar un contenedor por tarea
  • vincular sus instancias EC2 juntas manualmente
  • escribir restricciones de ubicación de estrategias complejas en ECS para asegurarse de que la tarea correcta estuviera en la máquina correcta que tenía el recurso apropiado dependiendo de lo que hizo

Eso es mucho trabajo, es bastante tedioso y difícil de mantener. Y en cierto modo frustra el propósito de trabajar con contenedores en primer lugar.

Alguien tuvo que tener una idea mejor.

Déjalos flotar

Resulta que el equipo de AWS tuvo los mismos problemas. Lo pensaron durante el año pasado y trabajaron para resolver el siguiente problema:

¿Cómo podríamos ejecutar contenedores sin tener que preocuparnos por servidores y clústeres?

Y de esto se trata AWS Fargate . Abstrae completamente la infraestructura subyacente, y ve todos y cada uno de sus contenedores como una sola máquina.

Solo tiene que especificar qué recurso necesita para cada contenedor y hará el trabajo pesado por usted. Ya no tiene que administrar reglas de acceso de múltiples capas. Puede ajustar los permisos entre sus contenedores como lo haría entre instancias EC2 individuales.

Es como si sus contenedores se convirtieran en barcos con su propia vela, timón y tripulación y pudieran flotar a su destino por sí mismos.

Contenedores como servicio (CaaS)

De hecho, creo que Containers as a Service (CaaS) es la PaaS real que los desarrolladores han estado esperando durante años. Permite a los desarrolladores implementar sus contenedores directamente en la nube sin tener que preocuparse por todo lo demás.

Por supuesto, ya existen muchas tecnologías que le permiten ejecutar su código sin problemas en la nube sin tener que preocuparse por la escala o la administración del servidor (como el increíble Heroku , Lambda o incluso, a su manera, el motor de aplicaciones de Google) . Pero todos tienen limitaciones.

  • Tienes que elegir entre perder un poco de flexibilidad
  • Tienes que ceñirte a los idiomas admitidos
  • No puede usar los idiomas admitidos porque su proyecto necesita una biblioteca nativa de bajo nivel que solo está disponible en sistemas muy específicos
  • Su proyecto utiliza una tecnología de vanguardia que no estará disponible para las masas en los próximos años.
  • Algunas de estas plataformas son muy (muy) caras, especialmente cuando se amplían

Fargate (o CaaS) le ofrece lo mejor de ambos mundos.

La arquitectura en contenedores le brinda la flexibilidad y el control que necesita. Le permite utilizar cualquier tipo de tecnología que se ejecute en cualquier tipo de sistema que desee. El aspecto del contenedor asegurará que tendrá el mismo comportamiento en todos los hosts, ya sea un entorno de desarrollo, prueba, preparación o producción.

Encuentro este punto crítico para muchas nuevas empresas tecnológicas. De hecho, a veces una de sus ventajas competitivas es el uso de una tecnología de vanguardia en la que ha participado en el desarrollo, o la reutilización inteligente de otra en un contexto totalmente nuevo y revolucionario.

La implementación sin servidor le permite concentrarse en escribir código excelente. Sin aprovisionamiento, fácil escalado.

Limites

CaaS frente a PaaS

Es cierto que está renunciando a algunos aspectos interesantes de la PaaS real. Sí, aún tendrá que actualizar manualmente las imágenes de su contenedor y, a veces, tendrá que escribir sus propias imágenes de Docker. Esto puede resultar complicado al principio si no conoce los conceptos básicos de la administración del sistema .

Pero también significa que puede hacer prácticamente cualquier cosa en la que pueda pensar y tener total flexibilidad y libertad en los sistemas, lenguajes, herramientas, bibliotecas y versiones que desee utilizar.

Costo

Seamos realistas, los servicios en la nube (IaaS) son más costosos que tener su propia infraestructura (si pudiera escalarla hacia arriba y hacia abajo según la demanda). Por la misma razón, no tener que aprovisionar, administrar y escalar sus servidores tiene un costo. Puede que aún no sea la mejor solución para algunos de sus casos de uso más simples.

Esperemos que trabajen para reducir el costo. Por muy bueno que sea el producto, es difícil justificar casi 4 veces el precio de una instancia EC2 equivalente bajo demanda (para t2.medium, por ejemplo).

¿Debo cambiar todas mis tareas de ECS a Fargate?

Aún no. Como se indicó anteriormente, en algunos casos, triplicará sus costos con creces. Hasta que reduzcan el costo, es posible que sea mejor usar instanes estándar EC2.

Sin embargo, Fargate puede ser más beneficioso para usted en los siguientes casos de uso:

  • Si tiene problemas para escalar automáticamente sus tareas de ECS de manera eficiente y, a menudo, termina con una gran cantidad de CPU o memoria sin usar . Con Fargate, solo paga por los recursos que haya definido en sus tareas .
  • Para sus tareas que se ejecutarán según demanda o según una programación y no necesitan una instancia EC2 dedicada. Con Fargate, solo paga cuando su tarea está en ejecución.
  • Para sus tareas que tienen picos de uso de memoria y / o CPU . Solo porque le ahorrará el tiempo y las molestias de la configuración y gestión de tales casos.

Prima

Para aquellos que prefieren Kubernetes sobre ECS , Fargate pronto podrá ejecutar Elastic Container Service para Kubernetes.