Melpomene - Fotolia

Noticias Manténgase informado sobre las más recientes actualizaciones de productos y noticias de tecnología empresarial.

Proveedores de nube pública se suben al carro de la computación sin servidor

La computación sin servidor está de moda con los proveedores de nube, y herramientas como AWS Lambda pueden cambiar la forma en que se utilizan los recursos –a pesar de que aún es pronto.

Las arquitecturas sin servidor son la última moda entre los proveedores de la nube, pero este enfoque naciente de aprovechamiento de recursos de la nube pública puede ser una tendencia digna de todo el bombo.

Amazon Web Services (AWS) fue el primero en introducir los llamados recursos informáticos sin servidor detonados por eventos específicos con su AWS Lambda en 2014. El servicio se mantuvo prácticamente intacto hasta este año, cuando IBM, Google y Microsoft desplegaron sus propias iteraciones. Todos están tratando de salir adelante de un mercado donde los usuarios descargan cada vez más la responsabilidad de los proveedores de nube, al mismo tiempo que buscan un control más detallado de la asignación de recursos.

La idea detrás de este tipo de servicios sin servidor es que los desarrolladores desplieguen su código sin tener que preocuparse por el reclutamiento, aprovisionamiento o la gestión de los recursos subyacentes. Por supuesto, hay servidores en arquitecturas sin servidor en algún lugar de los centros de datos masivos de los proveedores de nubes públicas, pero tal abstracción permite que tanto el usuario como el proveedor logren una mayor eficiencia y se centren en lo que mejor sabe hacer cada uno.

"En este caso, el bombo se garantiza definitivamente", dijo Dave Bartoletti, analista principal de Forrester Research.

Las aplicaciones están diseñadas tradicionalmente de manera monolítica que envuelve todo el código en una sola pieza grande. Las arquitecturas sin servidor permiten a los desarrolladores cortar su aplicación en piezas más pequeñas y desplegarlas en forma altamente escalable con una infraestructura elástica –incluso con más facilidad que con los contenedores, dijo Bartoletti.

Un ejemplo común de los méritos de estos modelos de computación sin servidor es subir una foto a un sitio web. Una instancia podría desatarse y un desarrollador podría escribir una gran cadena de código con una serie de responsabilidades, incluyendo el lanzamiento de una carpeta, cambiar el tamaño de las imágenes, hacer una copia de seguridad y asegurar que la imagen se carga correctamente.

Alternativamente, el desarrollador podría escribir un fragmento de código y utilizar una función Lambda para ver un directorio, ejecutar el código y subir la imagen. El usuario sólo paga por los milisegundos en los que se ejecuta esta función, en lugar de los minutos u horas que de otra forma requieren las plataformas en la nube para ejecutar una instancia.

Entonces, la computación sin servidor no se trata tanto de la tecnología sino de los precios y el embalaje, explicó Andrew Reichman, director de investigación en 451 Research. Tiene el potencial de cambiar cómo se utilizan los recursos, vinculando más estrechamente la plataforma de infraestructura y el desarrollo de aplicaciones, existente en algún lugar entre la infraestructura como servicio (IaaS) y la plataforma como servicio (PaaS).

"Es un gran paso para alquilar [un servidor] por horas o minutos, pero siendo realistas, incluso eso es menos detallado que lo que necesita", dijo Reichman. En última instancia, los usuarios quieren "hacer el cómputo que necesitan y de hecho pagar por él cuando [ellos] en realidad lo utilicen, en lugar de pagar y quedarse esperando un trabajo."

Puede ser difícil saber qué servidor elegir para un trabajo debido a la incertidumbre en torno a la demanda, dijo Reichman. A pesar de que puede que no sea un compromiso típico de cinco años en un centro de datos privado, los desarrolladores están siendo forzados a tomar una decisión en un servidor para programar sus cargas de trabajo.

Google, Microsoft e IBM siguen el ejemplo de Amazon

Lambda sigue siendo el mejor ejemplo del potencial de la computación sin servidor debido a la considerable ventaja de Amazon en el mercado, el historial más largo y la reputación entre los usuarios. Google comenzó con las pruebas alfa de Cloud Functions en febrero, pero ha sido hermético sobre ello. IBM siguió en marzo al añadir OpenWhisk a sus PaaS con la oferta de Bluemix, a pesar de que el servicio se encuentra enlistado en la categoría de experimentales. Microsoft cerró el aluvión de comunicados a finales de marzo por la adición de Azure Functions, actualmente en la vista previa.

Pero las arquitecturas sin servidor no comenzaron con Lambda –de manera similar a como los contenedores existían mucho antes de Docker. De hecho, algunos proveedores de la nube han renombrado servicios existentes como ‘sin servidor’ en medio de toda esta tendencia. En su reciente conferencia de usuarios en San Francisco, Google citó al menos cuatro productos sin servidor de Google Cloud Platform, incluyendo App Engine, su oferta PaaS introducida por primera vez en 2008.

Amazon no ha revelado la tasa de crecimiento de Lambda, y todavía está visto como un servicio para los pioneros, pero está siendo implementado por clientes de alto perfil como Netflix, Capital One y MLB. Los casos de uso populares incluyen funciones para el procesamiento de datos sin servidor, en coordinación con Simple Storage Service a través de una puerta de enlace (Gateway) API para ejecutar microservicios para aplicaciones web, como un medio para usar los dispositivos de la internet de las cosas (IoT) como una plataforma de desarrollo así como proveer un tejido de enlace para los innumerables entornos de AWS.

La revolución x86 permitió el diseño de aplicaciones perezosas porque la eficiencia era irrelevante cuando un servidor estaba sentado ocioso el 90% de las veces, pero ahora, las arquitecturas sin servidor están revirtiendo el curso y profundizan en la optimización, dijo Reichman. De alguna forma recuerda a los primeros días del mainframe con la utilización de tarjetas perforadas y la programación de tareas a ejecutar, agregó.

Aún es pronto

Herramientas como Lambda son difíciles de entender para muchos profesionales de TI, especialmente para aquellos que evalúan principalmente entre precio frente al rendimiento en las nubes locales o las nubes públicas, dijo David Pippenger, ingeniero senior de operaciones del servidor en GREE Inc., una compañía de juegos basada en San Francisco.

Hay algunos casos de uso muy fáciles, pero el potencial real se encuentra en el camino, Pippenger añadió.

"Toda la analogía sobre la nube es como girar el dial para obtener más agua –nos estamos acercando cada vez más a eso."

GREE ha utilizado Lambda, pero la compañía todavía se está acostumbrando al servicio. La compañía de juegos originalmente pensaba usarlo como disparador durante una migración de Amazon Relational Database Service (RDS) para DynamoDB, pero finalmente desechó ese plan. RDS estaba en una nube privada virtual, y el número de pasos adicionales necesarios para asegurarse de que la transferencia era segura durante el uso de Lambda sobre la internet pública lo hizo prohibitivo, dijo Pippenger.

Aunque algunos de los controles de acceso de seguridad al parecer han mejorado, son ese tipo de ejemplos los que ponen de relieve su infancia. "Aún no está listo para el prime time", dijo Pippenger.

Lambda sólo es compatible con ciertos tipos de eventos, y mientras el gran punto de venta es ser capaz de simplemente escribir código y avanzar, hoy en día, sólo es compatible con Node.js, Python y Java. Para obtener más casos de uso de producción, sería útil ver más lenguaje de los acuerdos de nivel de servicio en torno a las garantías de latencia, dijo Reichman.

Antes de evaluar un enfoque de computación sin servidor, las empresas deben encuestar a sus desarrolladores para entender lo mucho que sus aplicaciones actuales podrían beneficiarse; no hay necesidad de perder tiempo haciendo una tarea que puede ser mejor manejada por un microservicio, dijo Bartoletti. Para las nuevas aplicaciones, los desarrolladores deben estar buscando en arquitecturas de microservicios, pero proceder con cautela debido a la complejidad añadida con los procesos que se dividen en trozos más pequeños que pueden correr por todo el lugar.

No es fácil realizar una adaptación posterior para las aplicaciones heredadas y debe limitarse a las empresas que trabajan en un modo DevOps con arquitecturas de nube nativas, dijo Reichman.

"Si usted tiene una aplicación que es en realidad una obra de infraestructura, entonces esto es irrelevante para usted", dijo.

Investigue más sobre Tendencias de cómputo empresarial

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Close