¿En qué se diferencian las plataformas informáticas sin servidor como AWS Lambda o IBM OpenWhisk de PaaS?

Simplemente pon:

Son muy parecidos Lambda está diseñado para servir “microservicios” (es decir, marcos de servidores web ligeros como Node.js y SLIMPHP) en lugar de marcos de uso intensivo de recursos (es decir: Apache, Websphere o .NET).

Las soluciones de PaaS son más versátiles: también pueden servir los servicios antes mencionados además de marcos más intensivos en recursos (es decir: .NET, Websphere, Apache, etc.). Además, las soluciones PaaS son configurables para controlar accesorios, como almacenamiento dinámico de red, reglas de escalabilidad de aplicaciones, etc., que Lambda no proporciona.

Tanto PaaS como Lambda tienen la capacidad de escalar automáticamente según sea necesario. Sin embargo, piense en Lamba como un juego de API de servicio web CRUD puro, y PaaS como el siguiente paso cuando esté listo para abordar problemas a gran escala, como cumplir con los SLA con almacenamiento de red dinámico además de su servicio web. Es el siguiente paso de Lambda.

Hay muchas similitudes entre PaaS y “sin servidor” en términos de abstracción operativa y productividad del desarrollador. Por lo general, señalo el comportamiento de las cargas de trabajo como la distinción clave. PaaS está diseñado para aplicaciones de 12 factores, mientras que una plataforma “sin servidor” está diseñada para trabajos / funciones / tareas … cualquiera que sea su término preferido. (El mío es trabajo). Bajando la línea …

• Las aplicaciones se envían a un tiempo de ejecución en vivo, los trabajos se cargan a un estado listo para ejecutar (imagen zip o Docker).
• Las aplicaciones se ejecutan durante mucho tiempo, los trabajos tienen un inicio y finalización discretos.
• Se solicitan aplicaciones, los trabajos se desencadenan por un evento.
• Las aplicaciones distribuyen el tráfico a través del equilibrador de carga, los trabajos a través de la cola de mensajes.
• Las aplicaciones se escalan como instancias / contenedores elásticos, los trabajos se escalan a través de procesos / contenedores concurrentes.

Debido a estas diferencias, la gestión del ciclo de vida de extremo a extremo de las cargas de trabajo requiere un tipo de plataforma diferente al de PaaS.

* Descargo de responsabilidad: trabajo para Iron.io , una plataforma de procesamiento de trabajos sin servidor basada en contenedores. He estado escribiendo sobre este tema por un tiempo ahora. Para una toma rápida, recientemente hice un Q&A publicado en Youtube .

Lo que queda claro es que la computación sin servidor es más un término de marketing que un concepto técnico. Tenga en cuenta que hay servidores reales en el cómputo sin servidor …;)

Lo diferente en el mundo de la computación sin servidor es que usted construye su código contra un conjunto de eventos. Tomemos, por ejemplo, que está creando un sitio web, que los usuarios subirán fotos.

Tradicionalmente, construiría código y lo implementaría en, digamos, el sistema PaaS. En este caso, debe ejecutar el sistema todo el tiempo, independientemente de si los usuarios van a cargar las imágenes o no. Si nota que gastará dinero en alojamiento y, por ejemplo, incluso si el usuario no ha subido ninguna foto durante semanas. Tenga en cuenta que PaaS lo libera de la responsabilidad de administrar las actualizaciones de nivel de SO invitado.

En el mundo de la informática sin servidor, no tiene que preocuparse por ejecutar los sistemas. El código se activará automáticamente cuando ocurra el evento de carga. Entonces, solo está pagando por los segundos exactos / microsegundos que ocurre el evento. Aquí es donde ahorrará una gran cantidad de costos operativos.

Si considera la unidad de trabajo como desarrollador, aún debe escribir el código que gestionará el proceso de carga. Pero está dejando la decisión de cuándo activar su código al proveedor de la nube en cuestión.

En la pila de AWS, Lambda no califica para ser un PaaS, sin embargo, la conversación de beans elásticos sí.

El propósito de lambda es crear aplicaciones más pequeñas y bajo demanda que respondan a eventos, lambda también es más adecuado para crear micro servicios.

Algo de esto fue respondido en mi charla sobre esto. Por favor verifique aquí

https://developer.ibm.com/opente …

Las respuestas anteriores son buenas. Solo quisiera señalar que es un poco más probable que esté sujeto al bloqueo como consumidor de aplicaciones creadas en torno a servicios ‘sin servidor’. Pero tendría confianza en un proveedor de servicios gestionados que pueda cumplir con su SLA.

También podría haber ventajas de precios para los servicios sin servidor. Pero también es un poco temprano de lo que puedo ver para estimar cuánto podría depender ese precio de los servicios ampliados que sus aplicaciones podrían no usar.