Zimki PaaS<\/a><\/noindex> en 2006, y aproximadamente al mismo tiempo Google App Engine ofreci\u00f3 una soluci\u00f3n muy similar.<\/p>\nDe hecho, lo que ahora llamamos un modelo \u00absin servidores\u00bb es m\u00e1s antiguo que muchas tecnolog\u00edas que ahora se denominan \u00abnativas en la nube\u00bb, y que ofrecen casi lo mismo. Como se ha mencionado, los modelos sin servidores son esencialmente solo una extensi\u00f3n del modelo comercial de SaaS, que ha existido durante varias d\u00e9cadas.<\/p>\n
Tambi\u00e9n hay que reconocer que el modelo sin servidor no es una arquitectura FaaS, aunque existe una relaci\u00f3n entre ambos. FaaS es, en esencia, la parte centrada en el c\u00e1lculo de la arquitectura sin servidor, pero no representa todo el sistema en su totalidad.<\/p>\n
\u00bfCu\u00e1l es todo el alboroto? Bueno, dado que la velocidad de penetraci\u00f3n de internet en los pa\u00edses en desarrollo contin\u00faa creciendo r\u00e1pidamente, tambi\u00e9n aumenta la demanda de recursos computacionales. Por ejemplo, en muchos pa\u00edses con sectores de comercio electr\u00f3nico en r\u00e1pido crecimiento, simplemente no existe la infraestructura computacional para las aplicaciones en estas plataformas. Ah\u00ed es donde entran las plataformas sin servidor de pago.<\/p>\n
Problemas de los modelos sin servidor<\/h1>\n \nEl problema es que los modelos sin servidor tienen... problemas. No me malinterpretes: no digo que sean intr\u00ednsecamente malos o que no proporcionen un valor significativo para ciertas empresas en ciertas circunstancias. Pero la afirmaci\u00f3n central de la 'revoluci\u00f3n' \u2014que la arquitectura sin servidor reemplazar\u00e1 r\u00e1pidamente a la tradicional\u2014 nunca se materializar\u00e1.<\/p>\n
Aqu\u00ed est\u00e1 el porqu\u00e9.<\/p>\n
Soporte limitado para lenguajes de programaci\u00f3n<\/h3>\n \nLa mayor\u00eda de las plataformas sin servidor permiten ejecutar solo aquellas aplicaciones que est\u00e1n escritas en lenguajes espec\u00edficos. Esto limita gravemente la flexibilidad y adaptabilidad de estos sistemas.<\/p>\n
Se considera que las plataformas sin servidor soportan la mayor\u00eda de los lenguajes principales. AWS Lambda y Azure Functions tambi\u00e9n proporcionan un shell para ejecutar aplicaciones y funciones en lenguajes no soportados, aunque esto a menudo implica costos en rendimiento. As\u00ed que para la mayor\u00eda de las organizaciones, normalmente esta limitaci\u00f3n no importa demasiado. Pero aqu\u00ed est\u00e1 el asunto. Se supone que una de las ventajas de los modelos sin servidor es que los programas poco conocidos o poco utilizados se pueden ejecutar de manera m\u00e1s econ\u00f3mica, dado que solo pagas por el tiempo que est\u00e1n activos. Y los programas poco conocidos o poco utilizados suelen estar escritos en... lenguajes de programaci\u00f3n poco conocidos o poco utilizados.<\/p>\n
Esto socava una de las ventajas clave del modelo sin servidor.<\/p>\n
Dependencia del proveedor<\/h3>\n \nEl segundo problema con las plataformas sin servidor, o al menos con la forma en que se implementan actualmente, es que generalmente no son similares entre s\u00ed a nivel operacional. Pr\u00e1cticamente no hay estandarizaci\u00f3n en la escritura de funciones, despliegue y gesti\u00f3n. Esto significa que la migraci\u00f3n de funciones de una plataforma a otra toma un tiempo extremadamente largo.<\/p>\n
La parte m\u00e1s dif\u00edcil de la transici\u00f3n a un modelo sin servidor no son las funciones computacionales, que generalmente son solo fragmentos de c\u00f3digo, sino c\u00f3mo las aplicaciones est\u00e1n conectadas a sistemas externos, como el almacenamiento de objetos, la gesti\u00f3n de identidades y las colas. Las funciones se pueden mover, pero el resto de la aplicaci\u00f3n no. Esto es lo opuesto a las plataformas prometidas que son baratas y flexibles.<\/p>\n
Algunos argumentan que los modelos sin servidor han surgido recientemente y que no ha habido tiempo para estandarizar su funcionamiento. Pero no son tan nuevos, como ya he se\u00f1alado, y muchas otras tecnolog\u00edas en la nube, como los contenedores, ya se han vuelto mucho m\u00e1s accesibles gracias al desarrollo y la amplia adopci\u00f3n de buenos est\u00e1ndares.<\/p>\n
Rendimiento<\/h3>\n \nLa capacidad de c\u00f3mputo de las plataformas sin servidor es dif\u00edcil de medir, en parte porque los proveedores tienden a mantener la informaci\u00f3n en secreto. La mayor\u00eda afirma que las funciones en plataformas remotas y sin servidor funcionan tan r\u00e1pido como en los servidores locales, excepto por algunos problemas inevitables de latencia.<\/p>\n
Sin embargo, ciertos hechos sugieren lo contrario. Las funciones que no se ejecutaban previamente en una plataforma espec\u00edfica o que no se han ejecutado durante un tiempo requieren algo de tiempo para inicializarse. Probablemente esto se deba a que su c\u00f3digo se ha trasladado a alg\u00fan medio de almacenamiento menos accesible, aunque, como en el caso de los benchmarks, la mayor\u00eda de los proveedores no te informar\u00e1n sobre la transferencia de datos.<\/p>\n
Por supuesto, hay varias formas de sortear esto. Una de ellas es optimizar las funciones para cualquier lenguaje de nube en el que opere tu plataforma sin servidor, pero esto socava un poco la afirmaci\u00f3n de que estas plataformas son 'flexibles'.<\/p>\n
Otro enfoque consiste en asegurar que los programas cr\u00edticos para el rendimiento se ejecuten regularmente para que se mantengan \"frescos\". Este segundo enfoque, por supuesto, contradice un poco la afirmaci\u00f3n de que las plataformas sin servidor son m\u00e1s econ\u00f3micas, ya que solo pagas por el tiempo de ejecuci\u00f3n de tus programas. Los proveedores de la nube han implementado nuevas formas de reducir los inicios en fr\u00edo, pero muchos de ellos requieren \"escalado a uno\" (scale to one), lo que socava el valor inicial del FaaS.<\/p>\n
El problema del \"inicio en fr\u00edo\" se puede resolver parcialmente ejecutando sistemas sin servidor internamente, pero esto conlleva costos propios y sigue siendo una opci\u00f3n de nicho para equipos bien dotados de recursos.<\/p>\n
No puedes ejecutar aplicaciones completas<\/h3>\n \nFinalmente, quiz\u00e1s la raz\u00f3n m\u00e1s importante por la cual las arquitecturas sin servidor no reemplazar\u00e1n los modelos tradicionales en el corto plazo es que (por lo general) no se pueden ejecutar aplicaciones completas sobre ellas.<\/p>\n
M\u00e1s bien, no es viable desde el punto de vista de costos. Es probable que tu exitoso monolito no valga la pena transformarlo en un conjunto de cuatro docenas de funciones, conectadas por ocho gateways, cuarenta colas y una docena de instancias de bases de datos. Por esta raz\u00f3n, las soluciones sin servidor son m\u00e1s adecuadas para nuevos desarrollos. Pr\u00e1cticamente ninguna aplicaci\u00f3n existente (arquitectura) se puede trasladar. Puedes migrar, pero tendr\u00e1s que comenzar desde cero.<\/p>\n
Esto significa que, en la gran mayor\u00eda de los casos, las plataformas sin servidor se utilizan como complemento a los servidores internos para realizar tareas que requieren un alto poder de c\u00f3mputo. Esto las distingue enormemente de las otras dos formas de tecnolog\u00edas en la nube: contenedores y m\u00e1quinas virtuales, que ofrecen un enfoque integral para la ejecuci\u00f3n de c\u00e1lculos remotos. Esto ilustra una de las dificultades de la transici\u00f3n de microservicios a sistemas sin servidor.<\/p>\n
Por supuesto, esto no siempre representa un problema. La capacidad de utilizar recursos computacionales enormes de manera ocasional, sin tener que comprar hardware propio, puede aportar beneficios reales y duraderos a muchas organizaciones. Sin embargo, si algunas aplicaciones se encuentran en servidores internos y otras en arquitecturas de nube sin servidor, la gesti\u00f3n alcanza un nuevo nivel de complejidad.<\/p>\n
\u00bfViva la revoluci\u00f3n?<\/h1>\n \nA pesar de todas estas quejas, no tengo nada en contra de las soluciones sin servidor como tales. Lo juro. Simplemente, los desarrolladores deben entender \u2014 especialmente si est\u00e1n explorando modelos sin servidor por primera vez \u2014 que esta tecnolog\u00eda no es un reemplazo directo de los servidores. En su lugar, consulte nuestros consejos y recursos sobre la creaci\u00f3n de aplicaciones sin servidor<\/a><\/noindex> y decida la mejor manera de aplicar este modelo. habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041a\u043b\u044e\u0447\u0435\u0432\u044b\u0435 \u043c\u043e\u043c\u0435\u043d\u0442\u044b \u0412\u043e\u0442 \u0443\u0436\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043d\u0430\u043c \u043e\u0431\u0435\u0449\u0430\u044e\u0442, \u0447\u0442\u043e \u0431\u0435\u0441\u0441\u0435\u0440\u0432\u0435\u0440\u043d\u044b\u0435 \u0432\u044b\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u044f (serverless) \u043e\u0442\u043a\u0440\u043e\u044e\u0442 \u043d\u043e\u0432\u0443\u044e \u044d\u043f\u043e\u0445\u0443 \u0431\u0435\u0437 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0439 \u041e\u0421 \u0434\u043b\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041d\u0430\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438, \u0447\u0442\u043e \u0442\u0430\u043a\u0430\u044f \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0440\u0435\u0448\u0438\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438. \u041d\u0430 \u0441\u0430\u043c\u043e\u043c \u0434\u0435\u043b\u0435 \u0432\u0441\u0451 \u0438\u043d\u0430\u0447\u0435. \u0425\u043e\u0442\u044f \u043c\u043d\u043e\u0433\u0438\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e\u0442 \u0431\u0435\u0441\u0441\u0435\u0440\u0432\u0435\u0440\u043d\u0443\u044e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044e \u043a\u0430\u043a \u043d\u043e\u0432\u0443\u044e \u0438\u0434\u0435\u044e, \u0435\u0451 \u043a\u043e\u0440\u043d\u0438 \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0432\u043f\u043b\u043e\u0442\u044c \u0434\u043e 2006 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043f\u043e\u044f\u0432\u0438\u043b\u0438\u0441\u044c Zimki PaaS […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97706","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t