¿Cuáles son las deficiencias actuales de la arquitectura sin servidor?

El argumento más convincente contra la arquitectura sin servidor es el bloqueo de proveedores. Esto se debe a que la arquitectura sin servidor utiliza la infraestructura del proveedor de la nube de maneras muy específicas.

Como ejemplo concreto, el producto sin servidor más popular para el uso de código escrito a medida, AWS Lambda logra una eficiencia de costos al dividir la máquina física en segmentos de memoria y tiempo. Pero todavía no hay una especificación abierta para hacerlo en diferentes proveedores.

Otro inconveniente es cuando se usan API alojadas que no ejecutan código personalizado, pero proporcionan características específicas. Ejemplos populares son el redimensionamiento de imágenes y la autenticación, características que pueden incluirse en un Back-end-as-a-Service. Dado que estos se ejecutan en diferentes máquinas propiedad de diferentes compañías, no existe una sólida integración continua (CI) y una historia de prueba para estos. Probar la aplicación es esencialmente una prueba de integración que afecta a los servicios en vivo, incluso si ofrecen entornos de desarrollo. Y, conceptualmente, la aplicación ni siquiera es una pieza única que pueda considerarse como una compilación. ¿Qué es un lanzamiento, en este tipo de arquitectura?

La mayor desventaja de la arquitectura sin servidor es que es innecesaria a partir de 2016.

Desde la perspectiva empresarial, la única parte que gana con la arquitectura sin servidor es la entidad que posee los servidores y, consecutivamente, los datos. Que yo sepa, ninguna empresa ambiciosa hoy en día cedería voluntariamente sus datos a un gigante como Google, Facebook o Amazon. Esas compañías tendrían que pagar diez dígitos para obtener esos datos 🙂

Desde la perspectiva tecnológica, las herramientas de implementación modernas son tan eficientes y tan independientes de la plataforma y del proveedor, que el gasto para capacitar a un equipo de ingeniería sólido con DevOp guy / gal que conoce bien el estado del arte y desplegaría la pila de manera confiable y Personalizable es relativamente bajo. A medida que el equipo crece y una persona DevOp se vuelve esencial, no hay razón para no contratar a un profesional, y todavía no he visto a un DevOp profesional que recomiende Parse o Firebase en lugar de un proveedor de servicios autohospedado o probado en la nube.

Por lo tanto, la principal deficiencia es probablemente en el campo de juego de complejidad adicional añadida. No está roto; no lo arregles

Creo que una posible falla de las plataformas sin servidor está relacionada con la optimización de sus funciones. El punto aquí es que cuán libre es para optimizar sus funciones cambiando toda la estructura que ejecuta su función. En Lambda, por ejemplo, puede optimizar su código, pero si necesita cambiar algo relacionado con los servidores, no puede hacerlo.

He escrito una comparación entre Open source Serverless y Black box:

Sin servidor: AWS Lambda vs Parse Cloud Code | blog back4app

Actualmente, los líderes del mercado en servidores sin servidor son AWS lambda y Heroku y cada uno tiene sus defectos.

Heroku es esencialmente una plataforma sin servidor porque no puede iniciar sesión en el servidor / contenedor subyacente para administrar su infraestructura, sin embargo, sus problemas son dobles. Primero se ejecutan en la infraestructura de otra persona (AWS), lo que significa que sus costos son demasiado altos. En segundo lugar, al controlar todo el flujo de desarrollo, son demasiado prescriptivos, lo que reduce la capacidad de escalar en su plataforma.

Con AWS Lambda, tiene la capacidad de ejecutar código, sin embargo, está trabajando a nivel funcional, o en un entorno encarcelado muy restringido, que es restrictivo. Ciertamente, puede mejorar las herramientas para ver cómo se desempeñan sus funciones, mejorar el monitoreo y, lo que es más importante, mejorar el tiempo de rotación, lo que puede agregar una cantidad considerable de latencia, pero aún estaría en un entorno encarcelado.

Una alternativa es básicamente proporcionar un entorno de kubernetes que le brinde la flexibilidad de sin servidor sin tener que preocuparse por su infraestructura, pero también le permite implementar contenedores completos para que no esté encarcelado y limitado, y por último no necesitará reestructura tu aplicación en funciones a medida que obtienes un contenedor completo para implementar.

Todo eso considerado es importante tener en cuenta que a veces una solución más simple que funciona en una unidad atómica más pequeña es la más exitosa.

El mejor ejemplo de un framework sin servidor que ha funcionado bien al enfocarse en una unidad atómica pequeña y estricta es el almacenamiento de objetos. Esto le brinda la flexibilidad de almacenar contenido estático infinito, accesible desde cualquier lugar, sin tener que preocuparse por quedarse sin espacio, hashing de directorios, redundancia y disponibilidad del activo. Al centrarse en una unidad atómica lo suficientemente pequeña pero crítica, un archivo estático, crea una enorme cantidad de beneficios para tratar con este subconjunto particular de datos.

La desventaja es, por supuesto, que no puede hacer streaming, bases de datos, etc., a través del almacenamiento de objetos, pero para el problema que resuelve, una vez que comienza a usarlo, no ve ninguna razón para volver.

Sin servidor, tal como lo define AWS lambda, es similar porque crea una unidad atómica similar. Por lo tanto, ahora cualquier cola de trabajo donde la latencia no sea crítica puede descargarse aquí y ahorrará una cantidad tremenda en términos de costo y, sobre todo, de gastos generales para garantizar que tenga una potencia de procesamiento que aumente y disminuya con la cola.

Si lo hace más poderoso, entonces aumenta el alcance de la unidad atómica, que en realidad puede contraatacar en términos de adopción, que es donde falló Google App Engine, por lo que, en cierto sentido, a veces el producto peor o más tonto tiene más éxito porque es más fácil comenzar y no requiere cambiar considerablemente su flujo de trabajo existente.

Ambas respuestas anteriores son buenas. El bloqueo de proveedores es una preocupación, pero existen soluciones que permiten a las personas ejecutar sin servidor dentro de sus propios modelos DC o híbridos (iron.io).

“La complejidad aumenta. Cuanto más pequeños tomamos las cosas, más complejo se vuelve todo el sistema. El código por función se vuelve más simple, pero el sistema en su conjunto se vuelve más complejo. Este es el mismo problema con los microservicios. Si divide una aplicación en 10 microservicios, digamos, ¡sabe que tiene 10 aplicaciones diferentes para administrar! Administrar 1 aplicación monolítica fue pan comido en comparación con administrar 10 aplicaciones más pequeñas.

Ahora digamos que divides tu monolito en 100 funciones, bueno … entiendes “.

-Travis Reeder
¿Qué es la informática sin servidor y por qué es importante?

La API de Coherence resuelve muchas de las deficiencias de la arquitectura sin servidor. Es la primera de una nueva generación de plataformas de “Código como servicio” creadas para implementar y ejecutar su código de manera segura más rápido que cualquier otra plataforma.

Estas son un par de formas en que la plataforma “Code as a Service” de Coherence resuelve las deficiencias de las plataformas sin servidor.

1. Centrado en la seguridad: Coherence utiliza sistemas operativos reforzados, SELinux y seccomp para mantener sus datos seguros. Sus trabajos no se ejecutan en el mismo host que otros trabajos, lo que aumenta drásticamente la seguridad
2. Más productivo: las soluciones sin servidor siempre requieren aprender sobre la plataforma específica de ese proveedor y realizar un proceso de integración doloroso. La plataforma “Code as a Service” de Coherence no te hace aprender nada nuevo y es rápido e indoloro.