La evolución de las Tecnologías de la Información hacia la hiperconvergencia

Las tecnologías avanzadas alteran continuamente el panorama de nuestro mundo y cada paso es una evolución incremental que lo impulsa hacia adelante. Las empresas modernas dependen en gran medida de esta disrupción positiva cíclica e iterativa para ser competitivas en el mercado e innovar, brindando nuevos servicios y productos a sus clientes más rápido que nunca.

Las empresas también exigen flexibilidad, posibilidad de elegir, agilidad y rentabilidad de estas tecnologías habilitadoras, para garantizar que las capacidades comerciales puedan cambiar con la demanda, el mercado, la misión comercial, etc.

En la última década, el auge de los servicios en la nube satisfizo la demanda de más Tecnologías de la Información y agilidad empresarial, lo que permitió que nuevas aplicaciones y servicios estuvieran en línea casi de la noche a la mañana. Sin embargo, esta capacidad creó problemas secundarios de expansión de datos y sistemas, gobernanza y estratificación del cumplimiento, costando a las empresas más que los modelos tradicionales de centros de datos, ya que carecía de controles de costos maduros.

Entonces, por estas razones y más, las empresas se dieron cuenta de que ciertas cargas de trabajo y conjuntos de datos eran más adecuados para sus centros de datos, mientras que otras requerían una arquitectura a escala "web" que llegara a una audiencia global, sin fricciones ni resistencia alguna. Así nació el modelo de nube híbrida. Ésta combina control, flexibilidad, seguridad, escalabilidad y rentabilidad, satisfaciendo las necesidades tanto de las empresas como de los clientes. Pero para comprender realmente los impulsores comerciales que llevaron a la nube híbrida, debemos analizar brevemente dónde comenzó todo esto. Y todo empezó con El Mainframe (la Primera Plataforma).

Mainframes (nace la Primera Plataforma)

Comenzando con la computación basada en Mainframes u Computadoras Centrales, los usuarios tenían la capacidad de crear estructuras de código monolíticas masivas, que residían en equipos en gran parte aislados y hechos a la medida. La potencia de procesamiento y el diseño centralizado de este sistema lo hacían muy costoso e inflexible. Utilizaban tecnología propietaria y el mantenimiento de cada sistema requería capacitación especializada y una coordinación cuidadosa, para garantizar interrupciones comerciales mínimas.

En caso de falla, se requiere forzosamente de un Mainframe Secundario, y la restauración desde las cintas de respaldo puede tardar días en completarse (Recovery Time Objective prolongado). Hablando de las aplicaciones, éstas tenían que ser escritas a medida para cada plataforma, lo que requería mucho tiempo y dinero.

Servidores Unix (nace la Segunda Plataforma)

La creación de los sistemas operativos Unix impulsó una estandarización de hardware y software en sistemas más enfocados y manejables. Esta homogeneidad permitió a los operadores de computadoras estandarizar sus habilidades y mantener los sistemas de manera similar en cualquier rubro de negocio o empresas. Sin embargo, el hardware del sistema Unix todavía está especializado por el proveedor (IBM POWER, IA64, SUN SPARC y otros), al igual que los distintos Sistemas Operativos Unix. 

Las aplicaciones (ahora en modalidad Cliente-Servidor) se desarrollan pero aún no se transfieren entre proveedores dispares, creando un bloqueo y requiriendo conjuntos de habilidades personalizados para los operadores de computadoras. Creación de Silos de Cómputo.

Arquitecturas Intel-AMD x86/X64 (se consolida la Segunda Plataforma)

En los años noventa hace acto de presencia la plataforma Intel-AMD x86/X64: un conjunto de hardware comercializado que se entrega de manera rápida, económica y estandarizada de la forma en la que se crean los sistemas de hardware en la actualidad. Al optimizar la arquitectura de hardware subyacente, los siguientes sistemas operativos en sistemas Intel-AMD x86/X64 se administran más fácilmente que sus contrapartes. Los componentes y los sistemas completos son intercambiables, las imágenes del Sistema Operativo se transfiere con relativa facilidad y las aplicaciones se desarrollan y migran más rápidamente a nuevos sistemas.

El avance de los sistemas Intel-AMD x86/X64 también hizo que la innovación de hardware supere la demanda de software, donde los sistemas multinúcleo con abundante memoria y almacenamiento quedarían inactivos o subutilizados en algunos momentos, debido a la naturaleza estática del tamaño del sistema. Los servidores Intel-AMD x86/X64 sufrieron su propio éxito y requirieron más innovación a nivel de software para desbloquear la próxima innovación: La Virtualización.

Virtualización de la Arquitectura Intel-AMD x86/X64 (cimientos de la Tercera Plataforma)

Aquí es menester hacer un paréntesis, pues el concepto de "Hipervisor" y por ende "Virtualización", ya había sido creado desde la era de los Mainframes. Pues gracias a ambos era posible poder ejecutar múltiples Cargas de Trabajo en el mismo Hardware.

La Virtualización de la Arquitectura Intel-AMD x86/X64 (como en cualquier otra plataforma) abstrae un sistema operativo de su hardware subyacente, lo que permite que cualquier sistema operativo que ya de por sí se podía ejecutar sobre la Arquitectura Intel-AMD x86/X64, ahora se pueda ejecutar simultáneamente con otros sistemas operativos en el mismo servidor "Bare Metal" (de manera nativa o a metal desnudo). Esto permitió aún más flexibilidad, ahorro de costos y eficiencia, así como portabilidad; ahora las aplicaciones se envían preinstaladas dentro de los “archivos” o imágenes de la máquina virtual. Estos sistemas virtualizados maximizan la densidad del sistema operativo al hardware, reduciendo los costos en el centro de datos y habilitando nuevas formas programáticas para implementar rápidamente nuevas Cargas de Trabajo.

Los sistemas virtualizados aún requerían cierta sobrecarga de mantenimiento y un conjunto de habilidades especializadas para operar y mantener. Con frecuencia las empresas sufrían la complejidad operativa de mantener cientos o incluso miles de máquinas virtuales a escala. Las mejoras, actualizaciones y el mantenimiento del sistema aún requerían una coordinación y planificación cuidadosas y a menudo, interrumpían las operaciones comerciales. Este modelo volvió a cambiar positivamente cuando se introdujeron "Los Contenedores".

Contenedores (consolidación de la Tercera Plataforma)

Los Contenedores son imágenes preempaquetadas de software (Microservicios), que utilizan fracciones de la capacidad informática y de almacenamiento de las máquinas virtuales, que se pueden implementar instantáneamente en cualquier ambiente de ejecución preparado para contenedores (Docker), a través de la automatización y la orquestación (Kubernetes).

Estas pequeñas unidades de cómputo (Microservicios) permitieron a los desarrolladores probar e implementar código rápidamente en cuestión de minutos en lugar de revisar los cambios de software en un repositorio en días, habilitando un ciclo de prueba y compilación de software automatizado que podría simplemente monitorearse, sin requerir grandes esfuerzos para su administración.

Los Contenedores también permitieron subdividir las aplicaciones en "Microservicios" más pequeños, donde no es necesario que una aplicación completa resida en la misma instancia o sistema operativo, sino solo una fracción que podría satisfacer una demanda comercial conocida. Esta capacidad combinada con el modelo operativo de La Nube "paga por lo que usa", permitió a las empresas pagar realmente solo por los servicios que necesitaban, cuando los necesitaban.

Arquitectura Sin Servidor (Serverless)

Atomizando las aplicaciones aún más, la computación Sin Servidor o la “Función como un Servicio” minimizó aún más la huella de los servicios de aplicaciones, al ejecutar solo pequeñas secciones de código a la vez. La computación Sin Servidor permitió a las empresas consumir fracciones de tiempo computacional y almacenamiento mínimo, simplemente ejecutando su código "bajo demanda" y sin la necesidad de poseer, administrar y dar mantenimiento al resto de la infraestructura subyacente.

En cada paso del camino, la potencia informática se mejoró, se hizo más eficiente y acercó las aplicaciones a su entorno operativo deseado siempre procurando obtener el desempeño y rendimiento correcto, satisfaciendo la demanda correcta del cliente, exactamente al costo y escala correctos.

Sin embargo, la informática Sin Servidor no es la única opción para obtener el mejor rendimiento, al menor costo y con la más óptima escalabilidad. Como ya hemos mencionado en este Blog Tecnológico, existe un riesgo inherente al entregar el control completo del hardware a un tercero y simplemente consumir recursos como un servicio. Una organización que pierde el control de sus datos no es un escenario ideal, por lo que existe una clara necesidad de una solución local que brinde los mismos beneficios que ofrece la computación sin servidor, pero sin los riesgos de seguridad y gobernabilidad.

Esa solución alternativa local es la Hiperconvergencia.

Infraestructura Hiperconvergente

La Infraestructura Hiperconvergente es aquella que gracias a La Virtualización de todos los elementos de los sistemas convencionales otrora "definidos por hardware", ahora son definidos por software. La Infraestructura Hiperconvergente (HCI por sus siglas en inglés) incluye como mínimo, recursos de cómputo (procesador y memoria) , almacenamiento y redes definidos por software . 

La Infraestructura Hiperconvergente normalmente se ejecuta en servidores comerciales listos para usar, dando como resultado los Centros de Datos Definidos por Software (SDDC por sus siglas en inglés) que permiten ofrecer a los Usuarios una Infraestructura como un Servicio (IaaS), en modalidad de Nube Privada. 

Algo muy importante a tomar en cuenta en este momento, es que la Infraestructura Hiperconvergente no sustituye ni a La Virtualización ni mucho menos a los Microservicios que vienen aparejados con Los Contenedores. Digamos que más bien aquí gracias a La Virtualización puede existir la Infraestructura Hiperconvergente, mientras que sobre una Infraestructura Hiperconvergente es posible el ejecutar Microservicios en formato de Contenedores.

Aunque se antoja pensar que la Infraestructura Hiperconvergente es el pináculo de las Tecnologías de la Información, recordemos que ésta permite que las empresas puedan gozar de Infraestructura como un Servicio en Nube Privada y Nube Híbrida (en conjunción con la Núbe Pública). Pero estamos muy seguros de que este es un escalón más a ambientes de cómputo cada vez más eficientes, flexibles y bajo demanda.

¿En qué estado se encuentran actualmente sus Tecnologías de la Información?

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í.