Cómo Sobrevivir al Apocalipsis Zombie con Microservicios sin Servidor

Reconozcámoslo, administrar servidores puede ser un dolor. La gestión de la capacidad y el escalado son aún peores. Ahora imagina dedicar tu tiempo a Sistemas Operativos durante un apocalipsis zombie: atrinchera la puerta de los comedores de carne con un brazo mientras aplicas un sistema operativo con el otro.

Esto suena como algo sacado de una pesadilla. Por suerte para ti, este no tiene que ser el caso. En AWS, se facilitan más que nunca la creación y el encendido de aplicaciones a escala con potentes servicios administrados, para que podamos centrarnos en su negocio principal, como sobrevivir, mientras manejamos la administración de la infraestructura que nos ayuda a hacerlo.

¡Únete a los "AWS Lambda Signal Corps"!

En el AWS re:Invent en 2015, pusimos a prueba un taller donde los participantes trabajaron en grupos para crear una aplicación de chat sin servidor, para supervivientes del apocalipsis zombie utilizando Amazon S3, Amazon DynamoDB, Amazon API Gateway y AWS Lambda.

Los participantes aprendieron sobre los patrones de diseño de microservicios y las mejores prácticas. Luego extendieron la funcionalidad de la aplicación de chat sin servidor, con varias funcionalidades complementarias como la integración de SMS móvil y la detección de movimiento zombie, utilizando servicios adicionales como Amazon SNS y Amazon Elasticsearch Service.

En esta publicación, mostraremos cómo nuestra aplicación de chat para sobrevivientes incorpora algunos patrones de diseño de microservicios importantes, así cómo también puede potenciar sus aplicaciones de la misma manera con una arquitectura sin servidores.

¿Qué son las arquitecturas sin servidor?

En AWS saben que la administración de la infraestructura puede ser un desafío. También entienden que los clientes prefieren enfocarse en entregar valor a sus negocios. Hay un montón de trabajos pesados ​​indiferenciados para construir y ejecutar aplicaciones, como la instalación de software, la administración de servidores, la coordinación de programas de parches y la ampliación para satisfacer la demanda.

Las arquitecturas sin servidor le permiten construir y ejecutar aplicaciones y servicios sin tener que administrar la infraestructura. Su aplicación aún se ejecuta en los servidores, pero AWS ha hecho toda la administración del servidor para usted. Las arquitecturas sin servidor pueden hacer que sea más fácil construir, administrar y escalar aplicaciones en la nube al eliminar gran parte del trabajo pesado involucrado con la administración del servidor.

Beneficios clave de las arquitecturas sin servidor:

• No hay servidores para administrar: no hay servidores para su aprovisionamiento y administración. AWS ha realizado toda la administración del servidor para usted.
  
• Mayor productividad: ahora puede centrar completamente su atención en la creación de nuevas características y aplicaciones porque se libera de las complejidades de la administración del servidor, lo que le permite iterar más rápido y reducir su tiempo de desarrollo.
  
• Escalado continuo: sus aplicaciones y servicios se escalan automáticamente hacia arriba y hacia abajo según el tamaño de la carga de trabajo.

¿Qué debería esperar aprender en un taller de microservicios Zombie?

El contenido del taller está diseñado para demostrar las mejores prácticas para arquitecturas sin servidor utilizando AWS. En este post discutiremos los siguientes temas:

• ¿Qué servicios son útiles al diseñar una aplicación sin servidor en AWS?
  
• Consideraciones de diseño para mensajería, transformación de datos y lógica empresarial o de nivel de aplicación, al crear microservicios sin servidor.
  
• Las mejores prácticas demostradas en el diseño de la aplicación de chat zombie survivor.
  
• ¡Los siguientes pasos para comenzar a construir sus propios microservicios sin servidor!

Se usaron varios servicios de AWS para diseñar la aplicación "Chat Zombie Survivor". Cada uno de estos servicios es administrado y altamente escalable. Echemos un vistazo rápido a cuáles incorporamos en la arquitectura:

• AWS Lambda le permite ejecutar su código sin aprovisionar o administrar servidores. Simplemente cargue su código (actualmente Node.js, Python o Java) y Lambda se ocupa de todo lo que necesita para ejecutar y escalar su código con alta disponibilidad.
  
  Puede configurar su código para que se active automáticamente desde otros servicios de AWS o llamarlo directamente desde cualquier aplicación web o móvil. Lambda se utiliza para alimentar muchos casos de uso, como aplicaciones de respaldo, tareas administrativas programadas e incluso, grandes cargas de trabajo de datos a través de la integración con otros servicios de AWS como Amazon S3, DynamoDB, Redshift y Kinesis.
  
• El Servicio de Almacenamiento Simple de Amazon (Amazon S3), es nuestro servicio de almacenamiento de objetos que brinda a los desarrolladores y equipos de TI, un almacenamiento seguro, duradero y escalable en la nube.
  
  S3 se utiliza para admitir una amplia variedad de casos de uso y es fácil de usar con una interfaz simple para almacenar y recuperar cualquier cantidad de datos. En el caso de nuestra aplicación de chat para sobrevivientes, incluso se puede usar para alojar sitios web estáticos con soporte CORS y DNS.
  
• Amazon API Gateway facilita la creación de "RESTful API" para sus aplicaciones. API Gateway es escalable y fácil de configurar, lo que le permite crear integraciones con aplicaciones de servicios de fondo, incluido el código que se ejecuta en AWS Lambda, mientras el servicio maneja la escala de sus solicitudes de la API.
  
• Amazon DynamoDB es un servicio de base de datos NoSQL rápido y flexible, para todas las aplicaciones que necesitan una latencia de milisegundos consistente y de un solo dígito en cualquier escala. Es una base de datos en la nube totalmente administrada y es compatible con los modelos de almacenamiento de documentos y valores clave. Su modelo de datos flexible y su rendimiento confiable lo hacen ideal para dispositivos móviles, web, juegos, tecnología publicitaria, IoT y muchas otras aplicaciones.

Descripción general de la aplicación Zombie Survivor Chat

La aplicación "Chat Survivor" representa una arquitectura completamente sin servidor, que ofrece una aplicación de chat de referencia (escrita usando AngularJS) a los participantes del taller, sobre la cual se puede agregar funcionalidad adicional.

Para entregar esta aplicación de chat de línea de base, se les proporciona a los participantes una plantilla de AWS CloudFormation, que activa el ambiente en sus cuentas. El siguiente diagrama representa una arquitectura de alto nivel de los componentes que se inician automáticamente:

• El cubo de Amazon S3 se creó para almacenar los contenidos de la aplicación web estática de la aplicación de chat.
  
• Las funciones de AWS Lambda se crean para servir como el nivel lógico de negocio de back-end, para procesar las lecturas/escrituras de los mensajes de chat.
  
• Los puntos finales API se crean utilizando API Gateway y se asignan a las funciones de Lambda. El método API Gateway POST apunta a una función WriteMessages Lambda. El método GET apunta a una función Lambda GetMessages.
  
• Se aprovisiona una tabla de mensajes DynamoDB para actuar como nuestro almacén de datos para los mensajes de la aplicación de chat.

Con la pila CloudFormation lanzada y los componentes construidos, el resultado final es una aplicación de chat totalmente funcional alojada en S3, que utiliza API Gateway y Lambda para procesar solicitudes, y DynamoDB como persistencia para nuestros mensajes de chat.

Con esta aplicación de referencia, los participantes se unen en equipos para desarrollar funcionalidades adicionales, que incluyen lo siguiente:

• Integración de SMS/MMS a través de Twilio. Enviar mensajes para chatear desde SMS.
  
• Detección del sensor de movimiento de zombies cercanos con Amazon SNS e Intel® Edison y Grove IoT Starter Kit. AWS proporciona un sensor de movimiento compartido para el taller y usted consume sus mensajes del SNS.
  
• Ayuda con botón de pánico con IoT.
  
• Integración con Slack para mensajes desde otra plataforma.
  
• Indicador de escritura para ver qué sobrevivientes están escribiendo.
  
• Análisis sin servidor de mensajes de chat utilizando Amazon Elasticsearch Service (Amazon ES).
  
• ¡Cualquier otra funcionalidad en la que los participantes puedan pensar!

Como parte del taller, AWS brinda orientación para la mayoría de estas tareas. Con estos complementos, la arquitectura del sistema de chat comienza a parecer un poco más sofisticada, como se muestra a continuación:

Inquilinos arquitectónicos del Chat de supervivientes sin servidor

En su mayor parte, los patrones de diseño que veríamos en un entorno tradicional de servidor, si también lo encontrarás en un entorno sin servidor. No hay sorpresas allí. Dicho esto, nunca está de más repasar las mejores prácticas mientras se aprenden otras nuevas. Repasemos algunos patrones clave que incorporamos en nuestra aplicación sin servidor.

El desacoplamiento es primordial

En la aplicación de "Chat Survivor", las funciones de Lambda sirven como nuestro nivel para la lógica de negocios. Dado que los usuarios interactúan con Lambda en el nivel de función, le sirve para dividir la lógica en funciones separadas, tanto como sea posible para que pueda escalar el nivel lógico independientemente de la fuente y los destinos en los que se sirve.

Como verá en el diagrama de arquitectura en la sección anterior, la aplicación tiene funciones Lambda separadas para el servicio de chat, el servicio de búsqueda, el servicio de indicadores, etc.

El desacoplamiento también se incorpora mediante el uso de API Gateway, que expone nuestra lógica de back-end a través de una interfaz RESTful unificada. Este modelo nos permite diseñar nuestra lógica de back-end con lenguajes de programación, sistemas o canales de comunicación potencialmente diferentes, a la vez que mantenemos a los puntos finales solicitantes al margen de la implementación.

Utilice este patrón y no llorará solicitando ayuda cuando necesite escalar, actualizar, agregar o eliminar piezas de su entorno.

Separe sus almacenes de datos

Trate cada almacén de datos como un componente de aplicación aislado del servicio al que da soporte. Un inconveniente común cuando se siguen arquitecturas de microservicios es olvidarse de la capa de datos.

Al mantener los almacenes de datos específicos para el servicio que admiten, puede administrar mejor los recursos necesarios en la capa de datos específicamente para ese servicio. Este es el verdadero valor en microservicios.

En la aplicación "Chat Survivor", esta práctica se ilustra con las tablas DynamoDB Activity y Messages. El servicio indicador de actividad tiene su propio almacén de datos (tabla de actividades) mientras que el servicio de chat tiene el suyo (mensajes).

Estas tablas pueden escalarse independientemente junto con sus respectivos servicios. Este escenario también representa un buen ejemplo de statefuless. La implementación del complemento de indicador de conversación utiliza DynamoDB a través de la tabla de Actividad, para rastrear la información de estado acerca de qué usuarios están hablando.

Recuerde que muchos de los beneficios de los microservicios se pierden, si los componentes todavía están pegados en la capa de datos al final, creando un denominador común desordenado para escalar.

Aproveche las transformaciones de datos

Al diseñar un servicio, la transformación de datos y la compatibilidad son componentes importantes.

¿Cómo manejará las entradas de muchos clientes, usuarios y sistemas diferentes para su servicio? ¿Ejecutará diferentes sabores de su entorno para que se correspondan con los diferentes estándares de solicitud entrante? ¡Absolutamente no!

Con API Gateway, la transformación de datos se vuelve significativamente más fácil a través de modelos incorporados y plantillas de asignación. Con estas características, puede construir transformación de datos y lógica de mapeo en la capa API para solicitudes y respuestas.

Esto resulta en menos trabajo para usted, ya que API Gateway es un servicio administrado. En el caso de nuestra aplicación de chat para sobrevivientes, AWS Lambda y nuestra aplicación de chat para sobrevivientes requieren JSON, mientras que a Twilio le gusta XML para la integración de SMS. Este tipo de transformación se puede descargar a API Gateway, dejándolo con un nivel empresarial más limpio y una cosa menos para diseñar.

Use API Gateway como su interfaz y Lambda como su implementación de back-end común. API Gateway utiliza Apache Velocity Template Language (VTL) y JSONPath para lógica de transformación.

Por supuesto, hay que considerar una compensación, ya que se podría manejar mucha lógica de transformación en su nivel lógico de negocios (Lambda). Pero, ¿por qué administrarlo usted mismo en el código de la aplicación, cuando puede manejarlo de forma transparente en un servicio completamente administrado a través de API Gateway?

Aquí hay algunas cosas a tener en cuenta al manejar transformaciones usando API Gateway y Lambda:

• Transformar primero; luego llame a su lógica común de back-end.
  
• Utilice las transformaciones VTL de puerta de enlace de API primero cuando sea posible.
  
• Use Lambda para preprocesar datos de formas que VTL no puede.

Seguridad a través del aislamiento del servicio y el mínimo privilegio

Como recomendación general al diseñar sus servicios, siempre utilice los privilegios mínimos y aísle los componentes de su aplicación para proporcionar control sobre el acceso. En la aplicación "Chat Survivor", se utiliza un modelo basado en permisos a través de AWS Identity and Access Management (IAM).

IAM está integrado en todos los servicios de la plataforma AWS y brinda la capacidad para que los servicios y las aplicaciones, asuman roles con conjuntos de permisos estrictos para realizar sus necesidades de acceso con menos privilegios.

Junto con los controles de acceso, debe implementar el registro de auditoría y acceso para proporcionar la mejor visibilidad en sus microservicios. Esto es más fácil con Amazon CloudWatch Logs y AWS CloudTrail.

CloudTrail habilita la capacidad de auditoría de las llamadas API realizadas en la plataforma, mientras que CloudWatch Logs le permite enviar datos de registro personalizados a AWS.

Aunque nuestra implementación de Amazon Elasticsearch en el chat de supervivientes se utiliza para analizar mensajes de chat, puede enviar fácilmente sus datos de registro y realizar análisis en su aplicación. Puede incorporar las mejores prácticas de seguridad de las siguientes maneras con la aplicación de chat de supervivientes:

• Cada función de Lambda debe tener un rol de IAM para acceder solo a los recursos que necesita. Por ejemplo, la función GetMessages puede leer de la tabla Messages mientras que la función WriteMessages puede escribir en ella.
  
  Pero no pueden acceder a la tabla de Actividades que se usa para rastrear quién está escribiendo para el servicio de indicadores.
  
• Cada punto final de la Pasarela API debe tener permisos IAM para ejecutar la(s) función(es) Lambda a la que está vinculado. Este modelo asegura que Lambda solo se ejecuta desde el principio que está permitido ejecutarlo, en este caso el método API Gateway que desencadena la función back-end.
  
• DynamoDB requiere permisos de lectura/escritura a través de IAM, lo que limita la actividad anónima de la base de datos.
  
• Utilice AWS CloudTrail para auditar la actividad API en la plataforma y entre los diversos servicios. Esto proporciona trazabilidad, especialmente para ver quién está invocando sus funciones de Lambda.
  
• Diseñe las funciones de Lambda para publicar resultados significativos, ya que estos se registran en los registros de CloudWatch en su nombre.

Para su información, en nuestra aplicación, permitimos el acceso anónimo a los puntos finales de la Pasarela API de chat. Queremos alentar a todos los sobrevivientes a conectarse al servicio sin registro previo y comenzar a comunicarse.

Supusimos que los zombis no son lo suficientemente inteligentes como para hackear nuestros canales de comunicación. Hasta el apocalipsis sin embargo, manténgase fiel a las claves de la API y la autorización con firmas, ¡que es compatible con API Gateway!

No abandonemos Prueba/Desarrollo

Al desarrollar con microservicios, puede aprovechar entornos de prueba y desarrollo independientes como parte del ciclo de vida de la implementación. AWS proporciona varias funciones para ayudarlo a continuar creando aplicaciones en la misma trayectoria que antes, incluyendo:

• Versiones y alias de la función Lambda: utilice estas funciones para versionar sus funciones en base y con apego a las etapas de implementación como desarrollo, prueba, puesta en escena, preproducción, etc. O tal vez realice cambios en una función Lambda existente en producción sin tiempo de inactividad.
  
• Planos del servicio Lambda: Lambda viene con docenas de planos para que pueda comenzar con el código preescrito que puede usar como esqueleto, o como una solución completamente funcional para completar su back-end sin servidor. Estos incluyen planos con enlaces a Slack, S3, DynamoDB y más.
  
• Etapas de implementación de API Gateway: Similar a la versión de Lambda, esta característica le permite configurar etapas API separadas, junto con variables de etapa únicas y versiones de implementación dentro de cada etapa. Esto le permite probar su API con los mismos o diferentes back-ends, mientras avanza a través de los cambios que realiza en la capa API.
  
• Integración de Maquetas con API Gateway: configure las respuestas ficticias que los desarrolladores pueden usar, para probar su código mientras se desarrolla la verdadera implementación de su API. Las integraciones simuladas (maquetas) hacen que sea más rápido iterar a través de la porción API de un ciclo de vida de desarrollo, mediante la racionalización de piezas que solían ser muy secuenciales y/o en cascada.

¡Manténgase atento a las actualizaciones!

Asegúrese de estar atento al repositorio de AWS GitHub. Aunque no cubrimos cada componente de la aplicación de "Chat Survivor" en esta publicación, ¡vamos a implementar este taller y código pronto para que pueda iniciarse por su cuenta! Esté atento a los Talleres Zombies que se acercan a su ciudad, o designe su ciudad para un taller aquí.