Video de Ejemplo - Tutorial - Cómo crear una Api usando el ApiGateway de Aws.
Hoy en día el término "Software en la Nube" es ampliamente utilizado tanto por clientes como por proveedores de software, mayoritariamente mal utilizado, usándolo solo para hacerse de Marketing para vender software obsoleto y monolítico que realmente no es Software en la Nube, que se piensa que lo es simplemente por el hecho de haber instalado una aplicación en un servidor mal instalado "en la nube" (lease: en la red de algún proveedor de servidores como Amazon AWS, por ejemplo) . Aquí espero aclarar la idea sin mayor profundidad.
Lo que hiciste...no es Software en la Nube.
No es Software en la Nube cuando se ha rescrito el mismo software de escritorio pero ahora para la web con algún Framework como Laravel, YiiFramework, etc.
En este caso el software sigue teniendo una arquitectura monolítica (y no me refiero al Framework, sino a cómo lo subutiliza el desarrollador). La famosa "clase con 500 métodos" o mas, que según su desarrollador "es orientada a objetos" por el hecho de haber creado una enorme clase que se parece mas a un programa hecho con QBasic pero con el término "class" en su cabecera sin el menor control de dependencias ni componentización. Aún así este tipo de aplicaciones son vendidas como tal por el simple hecho de que se esta ejecutando en un VPC de Amazon (por ejemplo).
La causa de esta falla de diseño mal etiquetado como "Software en la Nube" recae en la improvisación del desarrollador, la falta de preparación y estudio, y por sobre todo la falta de capacidad de abstracción y síntesis, esta última es adquirida mediante la lectura por tanto a la generación "Whatsapp" le será muy difícil lograr un real desarrollo en la nube.
Tu LAMP o WAMP tampoco garantizan que realmente sea Software en la Nube.
Muchos desarrolladores consiguen un proveedor de servidores virtuales (una VPC, Linux o Windows, ej: Amazon Ec2) e instalan allí su aplicación web, supongamos que ha sido bien diseñada con algún Framework como YiiFramework o Laravel, me refiero a alguien con experiencia en software y que ha diseñado una aplicación componentizada y realmente orientada a objetos. Aún esto no garantiza que sea Software en la Nube, esto simplemente es una Aplicación Web ejecutandose en el servidor de otra empresa.
El hecho de que el servidor sea "configurable en la nube" no significa que la "la aplicación exista en la nube".
De esto último salen algunas expresiones populares como "El software en la nube solo corre en el computador de otra persona". Lo cual es cierto, debido al mal uso del término "Software en la Nube".
Cómo se hace el verdadero Software en la Nube. Microservices y API Gateways.
En primer lugar, siempre estarán las personas que dirán "si, pero los microservices también se ejecutan en el servidor de otro". Es simplemente una manera que ellos tienen para opacar aquello que no quieren entender.
A pesar que los Microservices son funciones computarizadas que existen en otro servidor podemos decir que no equivale a tener a un servidor VPC dedicado para proveerlas.
La diferencia es que los Microservices que una verdadera aplicación en la Nube utiliza en su conjunto para proveer una solución estan distribuidas y gestionadas por una capa de software que no nos corresponde tocar, si existen en servidores (de Amazon, por ejemplo) pero de una forma virtualizada (utilizando el término "virtual" con real exactitud) en el sentido de que se nos presenta una capa homogenea de funciones disponibles para ser usadas, como si estuvieran en un solo sitio (la parte "virtual") pero en realidad estan distribuidas, gestionadas para manejar carga y disponibilidad.
Por ejemplo, si una aplicación web hecha con Microservices usa diez de estos para proveer la funcionalidad estos podrian estar distribuidos en diferentes servidores, incluso la distribución podria cambiar sin que la aplicación web lo note. El LoadBalancing es casi transparente e implícito. Esto se aleja muchísimo del esquema en donde tenemos un servidor fijo que las provea. La capa que provee los Microservices es dinámica, es componentizada y aislada por fuerza bruta, obligando a tener una arquitectura realmente distribuida en la nube. Aquí nace el verdadero Software en la Nube.
Qué es un Microservice.
Un Microservice es una función que existe en alguna parte en la nube y que realiza una tarea específica. En Amazon AWS se le conocen como AWS Lambda Functions y se accede a ellas mediante un API Gateway o son invocadas por eventos de software (IOT, Database Triggers en DynamoDB, etc).
Por ejemplo, este esquema grafica el uso de una Función Lambda para proveer una LandingPage de un cliente:
En este diagrama he diseñado una API RESTFUL mediante el uso de un API GATEWAY que provee una URL para que un sitioweb pueda pedirle una página dado su ID.
La página es creada por una Función Lambda (GetLandingPage), que a su vez invoca a otros componentes como DynamoDB (para buscar alli los datos de la página, dado su ID) y un "S3 Bucket" de Amazon, de donde se sacan algunas piezas secundarias para su creación.
Qué es un Api Gateway.
Un API Gateway es una capa de software que permite crear interfaces RESTful usadas para invocar funciones. El ApiGateway provee Urls, cada Url puede ser usada para saber cómo invocar a una funcion determinada. El ApiGateway puede manipular lo que la función recibe y lo que retorna, lo cual le da la habilidad de que una sola función pueda servir a diferentes formas de invocación.
Por ejemplo, si la función acá graficada (arriba) es invocada mediante una Url específica entonces devolverá datos Html directos para ser usados en un Browser.
https://198n29j99811.execute-api.us-east-1.amazonaws.com/test/page/5
Si agregamos un argumento en la Url (ejemplo "abc"), entonces el ApiGateway podrá retornar la forma JSON de la data devuelta por la misma función que sirvió a la Url anterior (arriba).
https://198n29j99811.execute-api.us-east-1.amazonaws.com/test/page/abc/5
Ambas Url son consideradas "Resources" en la terminología del ApiGateway, y podrian invocar a la misma función, pero cada recurso retornará algo distinto, incluso podria modificar los argumentos de entrada a la función o la data que esta retorna, como por ejemplo retornar JSON en vez de Html.
La aplicación final hecha con Microservices.
Finalmente tenemos una aplicación web, o una interfaz RESTful (una Api), que esta alojada realmente en la Nube. En este ejemplo no hay servidores VPC ejecutandose en ninguna parte, no tenemos un LAMP o un WAMP corriendo webservices (aunque Amazon los provee de forma dinámica), todas las funciones estan distribuidas, el ApiGateway es provisto por Amazon AWS y junta a todas las piezas. El cliente final ve una aplicación web funcionando sin estar alojada en ningun servidor específico.
Cómo Beneficia al Proceso de Desarrollo de Software
Una persona puede dedicarse a programar solo las funciones (microservices) siguiendo lineamientos del arquitecto de software sin lidiar con interfaces web ni con diseño de Urls. La lógica del negocio reside acá.
Otra persona puede dedicarse a crear la estructura URL mediante la cual se va a acceder a la aplicación web (la interfaz de la Api) sin conocer detalles de cómo las funciones operan. La lógica del negocio se complementa acá.
Un diseñador de interfaces Web podria diseñar la UI, la cual consume los servicios que el ApiGateway le da. Podria usar cualquier framework orientado a diseño de interfaces web que tenga capacidad de lidiar con llamadas RESTful. ¿ Y Dónde se aloja esta "página web" ? Podria ser provista por otra función dedicada a presentar contenido HTML, también gestionada por el ApiGateway. Si piensas que para esto instalarás un servidor LAMP para allí instalar Yii Framework...pues habrás echado al piso el diseño en la nube. En cambio, la arquitectura de los Lambda Services de Amazon AWS permite que puedas crear un directorio con todos los componentes necesarios que al momento de publicar la función estarán disponibles por ejemplo para proveer un web framework de tipo NodeJS o Java.
Un diseñador de pruebas podria usar las mismas Url del ApiGateway para realizar casos de prueba. Las invocaciones podrian ser realizadas dentro de otra función (microservice).
En resumen, toda la aplicación web residirá en Microservices.
Complementos
Como complemento, Amazon AWS provee los siguientes servicios:
1. Lambda Functions (microservices, donde reside la lógica y código)
2. Api Gateway (que provee las URL e invoca a las funciones lambda)
3. S3 buckets (para guardar archivos, imagenes, usados por funciones)
4. DynamoDB (una base de datos NO-SQL, invocada por funciones)
No hay comentarios:
Publicar un comentario