Get best of the week

Consejos y fuentes para crear aplicaciones sin servidor


Aunque las tecnologías sin servidor han ganado popularidad rápidamente en los últimos años, todavía hay muchas ideas falsas y preocupaciones asociadas con ellas. Dependencia del proveedor, herramientas, administración de gastos, arranque en frío, monitoreo y el ciclo de vida del desarrollo: todos estos temas se discuten activamente cuando se trata de tecnologías sin servidor. En este artículo, veremos algunos de los temas mencionados, y también compartiremos consejos y enlaces a fuentes de información útiles, con la ayuda de los cuales los principiantes pueden crear aplicaciones sin servidor potentes, flexibles y económicas.

Conceptos erróneos sobre las tecnologías sin servidor


Muchos creen que la falta de servidor y el procesamiento de datos fuera del servidor ( Funciones como servicio , FaaS) son casi lo mismo. Por lo tanto, la diferencia no es demasiado grande y vale la pena presentar un nuevo producto. Aunque AWS Lambda fue una de las estrellas en el apogeo de las tecnologías sin servidor y uno de los elementos más populares de la arquitectura sin servidor, esta arquitectura es más que FaaS.

El principio básico de las tecnologías sin servidor es que no necesita preocuparse por administrar y escalar la infraestructura, solo paga por lo que usa. Muchos servicios son adecuados para estos criterios: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase y muchos otros. En general, la falta de servidor significa utilizar todas las capacidades de la computación en la nube sin la necesidad de administrar la infraestructura y su optimización en aras de la escala. También significa que la seguridad a nivel de infraestructura ya no es su problema, sino una gran ventaja, dada la dificultad y la complejidad de cumplir con los estándares de seguridad. Finalmente, no necesita comprar la infraestructura que se le proporciona para su uso.

La falta de servidor puede considerarse un "estado mental": una cierta mentalidad en el diseño de soluciones. Evite los enfoques que requieren el mantenimiento de cualquier infraestructura. Con un enfoque sin servidor, pasamos tiempo resolviendo problemas que afectan directamente el proyecto y brindan beneficios a nuestros usuarios: creamos una lógica empresarial sostenible, desarrollamos interfaces de usuario y desarrollamos API adaptables y confiables.

Por ejemplo, si puede evitar administrar y mantener la plataforma de búsqueda de texto libre, entonces eso es lo que haremos. Este enfoque para crear aplicaciones puede acelerar en gran medida el lanzamiento del producto en el mercado, porque ya no necesita pensar en administrar una infraestructura compleja. Deshágase de las responsabilidades y los costos de administrar su infraestructura y concéntrese en crear las aplicaciones y servicios que sus clientes necesitan. Patrick Debois llamó a este enfoque 'útil', este término se adopta en la comunidad sin servidor. Las funciones deben considerarse como un enlace de conexión para los servicios en forma de módulos desplegables (en lugar de implementar una biblioteca o aplicación web completa). Esto proporciona una granularidad increíble en la gestión de la implementación y los cambios en la aplicación. Si no puede implementar funciones de esta manera, esto puede indicar que las funciones realizan demasiadas tareas y deben ser refactorizadas.

Algunos están confundidos por la dependencia del proveedor en el desarrollo de aplicaciones en la nube. Lo mismo con las tecnologías sin servidor, y esto no es consecuencia de la confusión. En nuestra experiencia, la creación de aplicaciones sin servidor en AWS en combinación con la capacidad de AWS Lambda de integrar otros servicios de AWS, todo esto forma en parte las ventajas de las arquitecturas sin servidor. Este es un buen ejemplo de sinergia cuando el resultado de la combinación es más que la suma de los términos. Al tratar de evitar la dependencia del proveedor, puede encontrarse con problemas aún mayores. Al trabajar con contenedores, es más fácil administrar su propio nivel de abstracción entre los proveedores de la nube. Pero cuando se trata de soluciones sin servidor, los esfuerzos no darán resultado, especialmente si se tiene en cuenta la eficiencia económica desde el principio. Asegúrese de averiguar cómo los proveedores brindan servicios.Algunos servicios especializados dependen de los puntos de integración con otros proveedores, y listos para usar pueden proporcionar conectividad plug-and-play. Es más fácil proporcionar una llamada Lambda desde el punto final de la API de la puerta de enlace que enviar la solicitud a algún contenedor o instancia EC2. Graphcool proporciona una configuración fácil con Auth0, que es más fácil que usar la autenticación de terceros.

Elegir el proveedor adecuado para su aplicación sin servidor es una solución de nivel arquitectónico. Cuando crea una aplicación, no espera que algún día regrese a la administración del servidor. Elegir un proveedor de la nube no es diferente a elegir usar contenedores o una base de datos, o incluso un lenguaje de programación.

Considerar:

  • ¿Qué servicios necesita y por qué?
  • Qué servicios proporcionan los proveedores de la nube y cómo puede combinarlos con la solución FaaS seleccionada.
  • Qué lenguajes de programación son compatibles (con mecanografía dinámica o estática, compilados o interpretados, qué puntos de referencia existen, cuál es el rendimiento en un arranque en frío, qué es un ecosistema de código abierto, etc.).
  • ¿Cuáles son sus requisitos de seguridad (SLA, 2FA, OAuth, HTTPS, SSL, etc.)?
  • Cómo administrar su CI / CD y los ciclos de desarrollo de software.
  • ¿Qué soluciones de clase de infraestructura como código puede aprovechar?

Si expande una aplicación existente y agrega funciones sin servidor de forma incremental, esto puede limitar algo las opciones disponibles. Sin embargo, casi todas las tecnologías sin servidor proporcionan algún tipo de API (a través de REST o colas de mensajes) que le permiten crear extensiones independientemente del núcleo de la aplicación y con una integración simple. Busque servicios con API claras, buena documentación y una comunidad sólida, y no se equivocará. La facilidad de integración a menudo puede ser una métrica clave, y esta es probablemente una de las principales razones del éxito de AWS desde el lanzamiento de Lambda en 2015.

Cuando la falta de servidor es útil


Las tecnologías sin servidor se pueden aplicar en casi todas partes. Sin embargo, sus ventajas no se limitan a una sola aplicación. El umbral de entrada a la nube es tan bajo hoy gracias a las tecnologías sin servidor. Si los desarrolladores tienen una idea, pero no saben cómo administrar la infraestructura de la nube y optimizar los costos, entonces no necesitan buscar algún tipo de ingeniero para esto. Si una startup quiere crear una plataforma, pero teme que los costos se salgan de control, puede recurrir fácilmente a soluciones sin servidor.

Debido al ahorro de costos y la facilidad de escalado, las soluciones sin servidor son igualmente aplicables tanto a los sistemas internos como a los externos, hasta una aplicación web con una audiencia multimillonaria. Las cuentas no se miden en euros, sino en centavos. Alquilar la instancia más simple de AWS EC2 (t1.micro) por un mes le costará € 15, incluso si no hace nada con él (¿quién nunca ha olvidado apagarlo?). En comparación, para lograr dicho nivel de gasto durante el mismo período de tiempo, deberá ejecutar Lambda 512 MB de tamaño durante 1 segundo aproximadamente 3 millones de veces. Y si no utiliza esta función, no pague nada.

Dado que la tecnología sin servidor depende principalmente de los eventos, es bastante fácil agregar infraestructura sin servidor a sistemas más antiguos. Por ejemplo, con AWS S3, Lambda y Kinesis, puede crear un servicio analítico para un sistema minorista antiguo que puede recibir datos a través de la API.

La mayoría de las plataformas sin servidor admiten diferentes idiomas. La mayoría de las veces son Python, JavaScript, C #, Java y Go. Por lo general, en todos los idiomas no hay restricciones en el uso de bibliotecas, por lo que puede usar sus bibliotecas de código abierto favoritas. Sin embargo, es aconsejable no abusar de las dependencias para que sus funciones funcionen de manera óptima y no anulen los beneficios de la enorme escalabilidad de sus aplicaciones sin servidor. Cuantos más paquetes necesite cargar en el contenedor, más tardará el arranque en frío.

Un arranque en frío es cuando primero necesita inicializar el contenedor, el tiempo de ejecución y el controlador de errores antes de usarlos. Debido a esto, el retraso en la ejecución de las funciones puede alcanzar los 3 segundos, y esta no es la mejor opción para usuarios impacientes. Sin embargo, los arranques en frío ocurren en el primer uso después de unos minutos de inactividad. Muchas personas consideran que esto es un inconveniente menor que se puede eludir haciendo ping regularmente a una función para mantenerla inactiva. O incluso ignorar este aspecto.

Aunque AWS ha lanzado la base de datos SQL sin servidor Aurora sin servidorSin embargo, las bases de datos SQL no son ideales para una aplicación de este tipo, ya que al realizar transacciones, dependen de las conexiones, que pueden convertirse rápidamente en un cuello de botella con mucho tráfico en AWS Lambda. Sí, los desarrolladores están mejorando constantemente la Aurora sin servidor, y debe experimentar con ella, pero hoy las soluciones NoSQL como DynamoDB son mucho mejores para los sistemas sin servidor . Sin embargo, es indudable que esta situación cambiará muy pronto.

El kit de herramientas también impone muchas restricciones, especialmente en el campo de las pruebas locales. Aunque existen soluciones como Docker-Lambda, DynamoDB Local y LocalStack, requieren un trabajo minucioso y una cantidad significativa de configuración. Sin embargo, todos estos proyectos se están desarrollando activamente, por lo que es solo cuestión de tiempo antes de que las herramientas alcancen el nivel que necesitamos.

El impacto de las tecnologías sin servidor en el ciclo de desarrollo


Dado que su infraestructura es solo una configuración, puede definir e implementar código utilizando scripts, como scripts de shell. O puede recurrir a soluciones de clase de configuración como código como AWS CloudFormation . Aunque este servicio no proporciona configuración para todas las áreas, le permite definir recursos específicos para usar como funciones de Lambda. Es decir, donde CloudFormation te decepcionó, puedes escribir tu propio recurso (función Lambda), lo que cerrará esta brecha. De esta manera puede hacer cualquier cosa, incluso configurar dependencias fuera de su entorno de AWS.

Dado que todo esto es solo una configuración, puede parametrizar sus scripts de implementación para entornos, regiones y usuarios específicos, especialmente si utiliza soluciones de clase de infraestructura como código como CloudFormation. Por ejemplo, puede implementar una copia de la infraestructura para cada rama en el repositorio para probarlas completamente de forma aislada durante el desarrollo. Esto acelera drásticamente a los desarrolladores que reciben comentarios cuando desean comprender si su código funciona adecuadamente en un entorno en vivo. Los gerentes no deben preocuparse por el costo de implementar numerosos entornos, ya que solo se paga el uso real.

DevOps tiene menos preocupaciones porque solo necesitan asegurarse de que los desarrolladores tengan la configuración correcta. Ya no necesita administrar instancias, equilibradores o grupos de seguridad. Por lo tanto, el término NoOps se usa cada vez más, aunque todavía es importante poder configurar la infraestructura, especialmente cuando se trata de la configuración de IAM y la optimización de los recursos de la nube.

Existen herramientas visuales y de monitoreo muy potentes como Epsagon, Thundra, Dashbird e IOPipe. Le permiten monitorear el estado actual de las aplicaciones sin servidor, proporcionar registros y seguimiento, registrar métricas de rendimiento y cuellos de botella de arquitectura, realizar análisis de costos y pronósticos, y mucho más. No solo brindan a los ingenieros, desarrolladores y arquitectos de DevOps una idea integral de cómo funcionan las aplicaciones, sino que también les permiten a los gerentes monitorear la situación en tiempo real, con costos de recursos por segundo y predicción de costos. Gestionar esto con una infraestructura gestionada es mucho más difícil.

Diseñar aplicaciones sin servidor es mucho más simple porque no necesita implementar servidores web, administrar máquinas virtuales o contenedores, servidores de parches, sistemas operativos, puertas de enlace de Internet, etc. La abstracción de todas estas responsabilidades permite que la arquitectura sin servidor se centre en lo principal: la solución necesidades de negocios y clientes.

Aunque el kit de herramientas podría ser mejor (está mejorando cada día), sin embargo, los desarrolladores pueden centrarse en implementar la lógica empresarial y la mejor distribución de la complejidad de la aplicación en los diferentes servicios dentro de la arquitectura. Las aplicaciones sin servidor son impulsadas por eventos y abstraídas por el proveedor de la nube (por ejemplo, eventos SQS, S3 o secuencias DynamoDB). Por lo tanto, los desarrolladores solo necesitan prescribir la lógica empresarial para responder a ciertos eventos, y no tiene que preocuparse por cómo implementar mejor las bases de datos y las colas de mensajes, o cómo organizar el trabajo óptimo con datos en almacenes de hardware específicos.

El código se puede ejecutar y depurar localmente, como con cualquier proceso de desarrollo. Las pruebas unitarias siguen siendo las mismas. La capacidad de implementar una infraestructura de aplicación completa con una configuración de pila personalizada permite a los desarrolladores obtener rápidamente comentarios importantes sin preocuparse por el costo de las pruebas o el impacto en los costosos entornos administrados.

Herramientas y técnicas para construir aplicaciones sin servidor


No hay una forma específica de crear aplicaciones sin servidor. Además de un conjunto de servicios para esta tarea. AWS es el líder entre las potentes soluciones sin servidor en la actualidad, sin embargo, preste atención a Google Cloud , Zeit y Firebase . Si usa AWS, se puede recomendar el Modelo de aplicación sin servidor (SAM) como un enfoque para recopilar aplicaciones , especialmente cuando se usa C #, ya que Visual Studio es un excelente conjunto de herramientas. SAM CLI puede hacer todo lo mismo que Visual Studio, por lo que no perderá nada si cambia a otro IDE o editor de texto. Por supuesto, SAM también funciona con otros idiomas.

Si escribe en otros idiomas, Serverless Framework es una excelente herramienta de código abierto que le permite configurar cualquier cosa con la ayuda de archivos YAML de configuración muy potentes. Serverless Framework también es compatible con varios servicios en la nube, por lo que se lo recomendamos a aquellos que buscan una solución multi-nube. Tiene una gran comunidad que ha creado un montón de complementos para cualquier necesidad.

Para pruebas locales, las herramientas de código abierto Docker-Lambda, Serverless Local, DynamoDB Local y LocalStack son muy adecuadas. Las tecnologías sin servidor aún se encuentran en una etapa temprana de desarrollo, al igual que las herramientas para ellas, por lo que al configurar escenarios de prueba complejos, tendrá que sudar. Sin embargo, solo expandir la pila en el entorno y probarlo resulta increíblemente barato. Y no necesita hacer una copia local exacta de los entornos en la nube.

Use las capas AWS Lambda para reducir el tamaño de los paquetes implementados y acelerar la carga.

Use los lenguajes de programación correctos para tareas específicas. Los diferentes idiomas tienen sus propias ventajas y desventajas. Hay muchos puntos de referencia, pero JavaScript, Python y C # (.NET Core 2.1+) son líderes en términos de rendimiento de AWS Lambda. La API de tiempo de ejecución ha aparecido recientemente en AWS Lambda, que le permite especificar el idioma y el tiempo de ejecución deseados, así que experimente.

Mantenga el tamaño del paquete pequeño para la implementación. Cuanto más pequeños son, más rápido se cargan. Evite usar bibliotecas grandes, especialmente si usa un par de características de ellas. Si está programando en JavaScript, utilice herramientas de compilación como Webpack para optimizar su compilación e incluir solo lo que realmente necesita. .NET Core 3.0 tiene QuickJit y compilación escalonada que mejoran el rendimiento y ayudan mucho en los arranques en frío.

La dependencia de las funciones sin servidor de los eventos al principio puede complicar la coordinación de la lógica empresarial. En este sentido, las colas de mensajes y las máquinas de estado pueden ser increíblemente útiles. Las funciones de Lambda son capaces de llamarse entre sí, pero solo si no espera recibir una respuesta ("disparó y olvidó"), no desea obtener una cuenta para esperar la finalización de otra función. Las colas de mensajes son útiles para aislar partes de la lógica empresarial, gestionar cuellos de botella de aplicaciones y procesar transacciones (utilizando colas FIFO). Las funciones de AWS Lambda se pueden asignar a las colas SQS como colas de mensajes bloqueados que rastrean mensajes fallidos para su posterior análisis. Las funciones de paso de AWS (máquinas de estado) son muy útiles para administrar procesos complejos que requieren la creación de cadenas de funciones.En lugar de llamar a una función Lambda otra función, las funciones de Paso pueden coordinar las transiciones de estado, transferir datos entre funciones y controlar el estado global de las funciones. Esto le permite determinar las condiciones para los reintentos, o lo que debe hacerse cuando se produce un error específico; en ciertas condiciones, una herramienta muy poderosa.

Conclusión


En los últimos años, las tecnologías sin servidor se han desarrollado a un ritmo sin precedentes. Hay ciertos conceptos erróneos asociados con este cambio de paradigma. Al abstraer la infraestructura y administrar el escalado, las soluciones sin servidor ofrecen beneficios significativos: desde el desarrollo simplificado y los procesos DevOps, hasta grandes reducciones en los costos operativos.
Aunque el enfoque sin servidor no está exento de inconvenientes, existen métodos confiables de patrones de diseño que se pueden usar para crear aplicaciones estables sin servidor o integrar elementos sin servidor en las arquitecturas existentes.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles