En los 90 se empezó a trabajar en aplicaciones web: internet explorer (o cualquier navegador web) llamaba a una url, y un servidor en el otro lado respondía a la llamada enviando una página web con todo el contenido a pintar. Al pulsar un botón, o rellenar un formulario: se volvía a llamar a otra url con los datos, y el servidor mandaba de vuelta todo el contenido a pintar. Si no me equivoco, este es el nivel en el que están muchas de aplicaciones web de hacienda. Cada vez que se pulsa en un boton o un enlace, hay que esperar unos instantes a que se vuelva a pintar la página con el contenido actualizado.
Los ordenadores y navegadores crecieron en potencia, y se empezó a usar una técnica llamada Ajax. El navegador llamaba a la url una vez, el servidor contestaba el contenido a pintar y plantillas adicionales para rellenar. Después al pulsar un botón, se enviaba una petición y el servidor respondía sólo con datos estructurados. El navegador re dibujaba sólo las partes necesarias en base a la respuesta. Algunas aplicaciones de la administración estan en este estado: se reduce considerablemente el trafico de red en las secuencias de petición/llamada, y se reduce mucho el efecto de "esperar a que vuelva a cargar la página". Es un modelo que presenta una complejidad muy elevada, porque obliga al servidor a dar respuestas tanto "de contenido completo", como de "datos estructurados".
En torno al 2005 empezó a funcionar Gmail en forma de beta privada; y desencadenó una nueva revolución: la potencia de los ordenadores personales y de los navegadores era más que suficiente para construir una aplicación que se ejecuta en el navegador con todas las plantillas, y llamar al servidor únicamente para recuperar los datos estructurados. Se simplifica el control de acceso a la información, hay una mayor reducción del trafico de red, y la navegación es extremadamente ágil: practicamente desaparecen los tiempos de espera.
Desde esa fecha ha crecido enormemente la construcción de aplicaciones bajo ese modelo: un servidor para procesar los datos, y donde enfocarse en controlar la seguridad y la integridad, y una aplicación de navegador (y posteriormente también aplicaciones móviles) para construir las pantallas. Facebook, Instagram, Twitter, Netflix... los servicios de internet han crecido en torno a ese paradigma.
La última tendencia en estas tecnologías que surgió hace sólo unos pocos años es la llamada "Serverless", aplicaciones web "sin servidor". La estandarización mediante REST de los accesos a los datos esta posibilitando que las aplicaciones de servidor se esten adelgazando a instancias donde básicamente se controla el acceso de los usuarios, y se guardan y recuperan datos para los usuarios. La pregunta que surgió en determinados circulos fué: "¿Porque tener que construir una aplicación específica diferente para hacer en todas ellas los mismo?". En serverless, no se programa en el servidor: se contrata en algún proveedor (firebase, aws, azure) el control de acceso y almacenamiento de datos, y son los clientes de navegador, o de móvil los que reciben la programación al completo.
Mi experimiento
En mi caso tengo mucha experiencia en Java y Angular. Diseñar y desarrollar aplicaciones basadas en microservicios se ha convertido en una tarea relativamente sencilla. El problema con el que me he encontrado, ha sido el elevado consumo de RAM de Java. Un servidor personal para "probar cosas" en el que se quiera contener el coste de alquiler suele estar limitado a 2 o 4 Gb de RAM, y cada aplicación que quiera desplegar ocupa 1Gb: una aplicación para compartir documentos e información geo localizada, una aplicación para llevar inventarios de red, una aplicacón para encuestas/formularios, una aplicación para estimadores de esfuerzo... Al final, en un sólo parrafo ya he listado más aplicaciones de las que puedo desplegar en dicho servidor...
La ventaja de una aplicación para serverless es que me permite desplegar una única aplicación en el servidor, y dentro de esa aplicación exponer conectores para los diferentes proyectos. El control de acceso y la definición de datos se hace usando un esquema sencillo, que se puede publicar fácilmente; y dado que al final siempre estamos delegando toda la lógica de aplicaciones en Angular o las Aplicaciones de móviles no es un cambio demasiado grande.
Penalizo el procesador, haciendo que cada llamada requiera más procesador; pero apenas consumo un Giga de RAM. Si alguna de las aplicaciones que usan el servicio tienen un elevado uso: primero se puede escalar en un servidor cada vez más potente, y llegado el caso tampoco existe ningún impedimiento para volcar las estructuras y crear una aplicación ad-hoc.
Comentarios
Publicar un comentario