Categories
54cuatro

Patrones de Arquitectura Serverless

Acerca de la arquitectura Sin Servidor

Hace un tiempo hicimos una entrada respecto a patrones de arquitectura para microservicios, la cual tuvo gran repercución, motivo por el cual traemos esta entrada referente a la arquitectura serverless.

Cuando hablamos de arquitectura serverless o “sin servidor” nos referimos a diseños de aplicaciones que utilizan un Backend como Servicio de terceros (ej, Auth0) o que incluyen código propio que se ejecuta en contenedores efímeros administrados por un tercero, en plataforma que denominamos “funciones como servicio” (FaaS).

Lógicamente estos contenedores son auto-administrados por el proveedor, en general Cloud Providers, pero de cara al cliente una plataforma serverless evita tener que gestionar infraestructura en su formato tradicional.

Existen aplicaciones para lograr correr Serverless on-premise, proyectos como Fission o Kubeless, permiten armar la infraestructura sobre Kubernetes; pero el gran crecimiento de estas soluciones esta dado por los proveedores como #AWS, #Azure y #GCP.

FaaS que delega un parte de la arquitectura en Backend como Servicio (#BaaS)

Este tipo de arquitectura en gran parte esta siendo impulsada por los microservicios, permitiendo generar una reduccion significativa de las ingenierias, delegando muchas partes de la arquitectura en terceros. Por ejemplo:

En el gráfico podemos observar un sistema típico de autorización/autenticación de un sitio web en un formato tradicional con los usuarios generados en la misma base de datos operativa, contra un sistema que delega la autorización/autenticación en un sistema de un tercero (#AWS #Cognito en el ejemplo). En el ejemplo tenemos 2 patrones. La validación de usuarios pasa a ser un microservicio, y su funcionamiento es completamente delegado a un tercero que nos brinda su backend como un servicio. En lineas generales la arquitectura de microservicios requiere de la creación de un #API gateway.

Pero sigamos avanzando y veamos otro formato de #FaaS o Serverless.

El otro formato al que se suele hacer referencia cuando se menciona #serverless se trata de ejecutar código backend sin administrar servidores y las corridas se efectúan durante un periodo de tiempo. En este caso, el código que uno realiza, es ejecutado por una plataforma de terceros, básicamente cargamos el código de nuestra función al proveedor, y el proveedor hace todo lo necesario para aprovisionar recursos, instanciar VM, crear #containers, administrar procesos, y ademas de gestionar la performance y asegurar los servicios. Las #funciones en FaaS generalmente se activan mediante tipos de eventos. Ej: recibir una petición http, detectar un objeto en un storage, tareas programadas manualmente, mensajes (tipo MQ), etc.

Functions as a Service: Evolution, Use Cases, and Getting Started | Oracle  Developers Blog

Precaución con el concepto de Stateless o Sin estado

Se suele decir que las FaaS son #stateless o “sin estado”. Este concepto hace referencia a que al ser código que se ejecuta de forma efímera, no existe almacenamiento disponible, de manera que cualquier función que requiera mantener persistencia debe externalizar la persistencia fuera de instancia FaaS. En Stateless cada operación se realiza como si se está haciendo por primera vez. Cuando una función requiere persistencia debemos acudir a capas adicionales de infraestructura como bases de datos de caché, bases de datos relacionales y/o storages de archivos y objetos y de esa forma pasamos a ser #stateful, lo que significa que se controla la historia de cada transacción pasada y que ellas pueden pueden afectar a la transacción actual.

Tiempo de ejecución

Otro concepto importante cuando hablamos de serverless tiene que ver con el tiempo de ejecución de las funciones. En la arquitectura sin servidor, las funciones suelen estar concatenadas y orquestadas donde cada tarea es dependiente de otra, y esto hace que si alguna se demora o falle, pueda afectar toda la sincronización configurada. Este motivo es suficiente para determinar que funciones de larga duración no son apropiadas en este modelo.

How to Reduce Website Execution Time?

En linea con esto, existe otro concepto llamado “arranque en frío” y que tiene que ver con el nivel de respuesta de una función ante su desencadenador.

Como mencionamos, el desencadenador o trigger es lo que dispara la ejecución de una función y la función luego se ejecuta durante un periodo de tiempo determinado, esto hace que aplicaciones con muchas lineas de código, que llaman librerías, o cualquier motivo que genere que el inicio sea “pesado”, no sean recomendables para entornos FaaS.

Ventajas y Desventajas de FaaS

Sin dudas adoptar serverless es algo que esta de moda, y que trae sus grandes ventajas. En la parte de arriba hemos recorrido grandes ventajas y hemos detectado situaciones donde no es conveniente usar funciones. Pero como resumen podemos resaltar que trae grandes ventajas a nivel costos, dando como resultado una fuerte reducción de los mismos. Adicionalmente permite optimizar ejecuciones y simplificar gran parte de la administración de infraestructura requerida para ejecutar código.

En contrapartida, la arquitectura serverless requieren de cierta maduración por parte de los desarrolladores (y sus productos) ya que todo el despliegue se debe hacer bajo modelos CI/CD en lo que actualmente se esta dando a conocer como #NoOps (voy a patentar el termino YA*OPS, yet another * ops :)) donde se busca poder ir a producción sin depender de un equipo de Operaciones.

Y finalmente, es importante mencionar que al subir código a proveedores de nube se genera un alto nivel de dependencia sobre ellos, algo poco recomendado claramente.

Patrones de arquitectura

Es el titulo de la nota, pero hasta ahora no hicimos foco sobre patrones. Los patrones de arquitectura serverless aun no tiene un marco definido. Lo que se viene delimitando como mejores practicas tiene que ver con temas a considerar previo a crear una plataforma serverless. Por ejemplo:

  • ¿Cuantas funciones se crearán?
  • ¿Que tan grandes o pesadas serán?
  • ¿Como se orquestarán las funciones?
  • ¿Cuales serán los disparadores de cada función?

Gran parte de la estrategia serverless viene adoptada de las arquitecturas de microservicios y de eventos; y en gran parte los conceptos ‘Event Driven’ y ‘API Driven’ conforman el núcleo de arquitecturas serverless. Y esto hace que también debamos preguntarnos:

¿Como generamos una arquitectura híbrida que considere API, Funciones, PaaS, IaaS, etc.?

La CNCF y los proveedores de nube vienen trabajando a gran velocidad para responder estas consultas y establecer un marco arquitectónico a considerar, algo que será muy bienvenido por todos, ya que nos permitirá tener referencias por ejemplo para lograr neutralidad sobre dónde y cómo implementar nuestras apps sin caer indefectiblemente en el ‘vendor lockin’ o como generar una estrategia multicloud en arquitecturas FaaS.

Conclusión

Durante la nota explicamos ventajas, desventajas y consideraciones en cuanto a montar servicios corriendo serverless. Sin dudas es una tendencia que cada día crece mas y se encuentran nuevos beneficios. En nuestra consideración permite crear grandes productos, pero siempre hablando de productos digitales nuevos, no creemos que refactorizar aplicaciones existentes y/o migrar a serverless sea hoy una estrategia viable. No es imposible, pero si algo arriesgado. La recomendación es comenzar con piezas pequeñas, integraciones y ejecuciones controladas. Para otro tipo de aplicaciones mas complejas, los esquemas de microservicios sobre contenedores son una buena alternativa a la que incluso aun les queda mucho por recorrer.

Si esta pensando en trabajar con serverless y necesita ayuda, escribanos desde el siguiente formulario:

Contactate
Categories
54cuatro

Transitando la adopción de arquitecturas serverless

La tecnología serverless fue la que mayor crecimiento expone desde el 2018 hacia hoy. #AWS y luego #Azure fueron dos grandes promotores de la tecnología #serverless. Al dia de hoy existen múltiples alternativas, incluso para correr serverless sobre on-premise.

¿De dónde viene la tecnología sin servidor?

En primer lugar, tenemos que hablar de Virtualizacion. La virtualización de servidores fue el paso inicial, que se basaba en correr múltiples servidores en un mismo hipervisor. Con el avance de la nube publica, las empresas utilizaron #IaaS (infraestructura como servicio), que básicamente es arrendar servidores y mover la carga de la infraestructura a la nube, pero los equipos aún tenían que lidiar con la configuración del servidor. Mas tarde apareció en escena PaaS (Plataforma como servicio). Los proveedores de #PaaS ofrecían una pila de aplicaciones más completa, como sistemas operativos y bases de datos para ejecutarse en la nube y ser administrados por el proveedor. Pero eso no fue suficiente. Luego surgió la tendencia de crear contenedores, una tendencia que sigue en alza, pero que significa de todas formas llevar a cabo configuraciones.

#Serverless o #FaaS (función como servicio) representa un nuevo enfoque para el desarrollo de aplicaciones. En pocas palabras, FaaS es una forma de computación sin servidor que utiliza una infraestructura completamente administrada por un proveedor para cargar funciones y ejecutarlas mediante “pago por solicitud”, y logrando que los desarrolladores y equipos de operaciones se abstraigan totalmente de las instalaciones de sistemas operativos, servidores de aplicaciones, librerías, etc.

Arquitectura Serverless

La arquitectura “sin servidor” aplica a una capa de servicios, por tanto, los diseños de arquitectura deben contemplar las capas de datos e integración como parte de la misma. En líneas generales, las capas de presentación (web, mobile) y las de aplicaciones son las mas factibles de llevar a modelos serverless, con los siguientes beneficios:

Menores costos y escalabilidad. En comparación con el enfoque tradicional, reduce los costos de operaciones y mantenimiento del servidor. En comparación con otros tipos de computación en la nube, la mayoría de los proveedores de FaaS trabajan con el modelo de precios de pago por solicitud. Esto significa que solo paga por el tiempo que se invocó una función y por la cantidad de invocaciones.

Capacity planning. Puede asignar una cierta cantidad de memoria y CPU para una función, y escalarla según sea necesario hacia arriba y hacia abajo. Incluso apagarse apagarse cuando no sea necesaria.

Desarrollo e implementación más rápidos. En lugar de escribir una estructura monolítica, FaaS ofrece una alternativa más flexible. Los desarrolladores pueden escribir código para un conjunto de funciones, en lugar de toda la aplicación monolítica, y cargar bits de código en el servidor. Eso hace que toda la estructura sea fácil de corregir, actualizar y agregar nuevas funciones.

Proveedores de arquitectura serverless

#AWS es quien introdujo la tecnología con mayor fuerza. #Lambda se convirtió en sinónimo de serverless, manteniendo la posición de producto líder en el mercado con la más amplia gama de servicios disponibles. #Azure Functions fue el siguiente oferente de esta tecnología en la nube, ofreciendo un conjunto de servicios similar a Amazon pero con un enfoque orientado hacia familia de lenguajes y herramientas de #Microsoft.

Luego #Google en #GCP, #IBM, #Oracle, #Huawei lograron implementar soluciones serverless en sus nubes. Todos los proveedores mencionados ofrecen servicios similares, suficientes para lanzar una aplicación en una infraestructura administrada.

En cuanto a la compatibilidad de lenguajes, Azure y Lambda admiten más idiomas que otros proveedores, y en cuanto a performance, no existe una diferencia crítica entre el rendimiento de las FaaS de cada provider.

Como monitorear servicios sin-servidor

El monitoreo es necesario para controlar las aplicaciones que corran en formato serverless, teniendo en cuenta ademas que toda la infraestructura es administrada por un proveedor. Entonces, para ver qué sucede exactamente con su aplicación y aplicar métricas, cada servicio tiene que ofrecer herramientas de monitoreo / registro. Esto le permite una descripción general de los recursos asignados y utilizados, detectar errores, monitorear registros, etc. Un factor fundamental a monitorear tiene que ver con la concurrencia, entendiendo por concurrencia a la ejecución paralela de diferentes funciones en un período de tiempo determinado, esto permite determinar la tasa simultaneidad que tolera cada aplicación, y que viene determinada por configuraciones a realizar en el proveedor del servicio FaaS.

¿Puedo tener Serverless en mi datacenter?

Si. Por ejemplo Kubernetes ademas de funcionar como herramienta para automatizar la implementación, la administración y el escalado de aplicaciones en contenedores, tiene un marco nativo sin servidor para la implementación de código llamado Kubeless.

Apache OpenWhisk es otra plataforma de código abierto que ejecuta funciones, pero administra la infraestructura, los servidores y el escalado mediante contenedores Docker. Tambien existe una herramienta open source llamada Fn project. Es una plataforma sin servidor de código abierto que se puede ejecutar en cualquier lugar, en la nube o en on premise.

En cuanto a herramientas comerciales, #RedHat posee #Openshift Serverless, una herramienta serverless de nivel empresarial que brinda portabilidad y uniformidad a todos los entornos híbridos y multicloud basada en Knative.

Conclusión

La tecnología Serverless permite acceder a una forma de trabajar, con mayor foco en el desarrollo, delegando la administración de la infraestructura a un tercero.

¿Ya habías oído de Serverless? ¿Tu empresa se encuentra en proceso de adopción?

    Por favor, demuestra que eres humano mediante la selección la estrella.

    Categories
    54cuatro

    Gestionando los legados

    No esta mas el que lo desarrolló. Esta hace muchos años y nadie sabe como funciona. No tenemos soporte del proveedor.

    Te parecen conocidas estas frases? Son algunas de las muchas que se escuchan dia a dia en las organizaciones ante la imposibilidad de actualizar sus sistemas legados.

    ¿Qué son los legados?

    Podriamos definirlos como esos programas que nadie quiere tocar, nadie sabe quién lo escribió y que absolutamente nadie quiere correr el riesgo de reemplazarlo.

    Podemos citar muchos casos de software legado que actualmente es de vital importancia en las organizaciones, por ejemplo los core banking o tasadores de Telcos.

    ¿Y porque nos encontramos con esta situación? Principalmente estas situaciones se dan cuando un software pierde su ciclo de actualización constante, y ante esa situación se comienza a perder conocimiento, se empiezan a ir los recursos claves que lo mantienen y ante esa situación cada dia se aísla mas del dia a dia. Para evitar que un software quede obsoleto, se requiere mejorarlo gradualmente y llevarlo a estándares de forma continua.

    ¿Cómo gestionar una aplicaciones legacy?

    Reescribir el código (#rewrite): esta opción es compleja, porque básicamente se basa en rearmar el programa con las mismas funcionalidades, pero con tecnología y practicas apropiadas al momento actual. La mayor complejidad de esto es tener que mantener dos sistemas similares funcionando, y posteriormente ir pasando “carga” del viejo al nuevo o directamente volcar todo el trafico de un sistema a otro en un formato “big bang”.

    Refactorizar el código (#refactor): esta opción se basa en reemplazar las funcionalidades del sistema antiguo, gradualmente. Esta estrategia consiste en relevar cada función, interface, clase, modulo, etc del sistema antiguo y construir una nueva pieza de software de ese elemento particular. Durante el refactoring, es posible detectar funcionalidades que ya no son necesarias, y a ellas se las deja “morir por inanición”.


    ¿Reescribir o Refactorizar?

    Lógicamente es necesario analizar cada situación. No es lo mismo Reescribir todo un Core Bancario, que Refactorizar una aplicación para que deje de usar #MySQL para usar #MongoDB.

    Se debe tener en claro cual es el aporte de valor de cada estrategia de cara al negocio. Posteriormente es bueno efectuar un assessment que permita situar el nivel de complejidad de la operatoria.

    • Relevamiento del software, interfaces, integraciones, etc.
    • Identificar la complejidad de las tareas
    • Identificar los riesgos
    • Definir con que enfoque se planeará la modernización de aplicaciones, apostando a disminuir el riesgo y los costos.

    Planeando la nueva arquitectura

    ¿Estamos rediseñando una aplicación monolítica? ¿Es SOA? ¿Es Rest? ¿Crearemos #API? ¿Vamos a la nube? ¿Adoptaremos microservicios? ¿Usamos contenedores? ¿#Serverless, eso que es?

    No es lo mismo pasar de .NET a .NET Core, que modificar un desarrollo en Cobol.

    Es muy importante definir cual será el diseño futuro que “absorberá” a nuestro legado. Y de esa forma planificar cuales serán los pasos apropiados. Si de una app de baja complejidad tipo monolito vamos a ir a un esquema de #microservicios o #serverless es una buena oportunidad para reescribir desde cero. Pero si el sistema heredado en cuestión es el core de su negocios, no puede darse el lujo de correr riesgos innecesarios, y para este caso, es preferible optar por una refactorización progresiva. De igual forma, si las personas que hicieron originalmente al sistema legado ya no están en la compañía, tampoco tiene sentido refactorizar y será más fácil reescribirlo.

    What is a Mainframe Computer? - A Guide from IBM Mainframes

    Como vemos, no existe una tabla que resuelva las decisiones mágicamente. A veces, en ciertas oportunidades la refactorización de código es la mejor opción, por seguridad o por practicidad. Pero la refactorización de código en otros casos puede brindar una ganancia rápida en términos de capacidad de mantenimiento y rendimiento, construyendo nuevamente desde 0.

    Existe un tercer modelo que podemos denominar Rehosting, y consiste en realizar un proceso llamado ‘Lift & Shift‘. Esta actividad tiene como finalidad levantar una aplicación legada y moverla a un nuevo entorno, ya sea #cloud, o #container, o #serverless. Esta opción es muy interesante para mover aplicaciones sin tener que esforzarse mucho en hacer una reescritura sustancial, en líneas generales, este tipo de procesos son de mucha utilidad para reducir la obsolescencia de hardware, pero como contra, es importante destacar que no tiene el valor que se encuentra en reestructurar la aplicación.

    Desde 54cuatro estamos apoyando a las organizaciones a disminuir los riesgos que conllevan estas decisiones, a través de nuestros servicios de consultoría en Arquitectura con profesionales especializados en enfoques la modernización de aplicaciones que tienen en cuenta componentes de plataforma, arquitectura aplicativa y el diseño de API. Necesitas apoyo? Escribinos.

    Contactate
    Categories
    54cuatro

    Usar Bases Relacionales para Analítica

    Desafío planteado

    El cliente nos indica que tiene 2 bases de datos, una Oracle 11g y otra MSSQL2016 donde se guarda informacion de dos sistemas corporativos de tipo BSS, y ademas junto con esa data necesitaban enriquecer la info con algunos archivos que reciben en formato CSV de algunos proveedores, y que para poder analizarlos ejecuta algunos procesos manuales, suben todo a una base de datos intermedia y desde ahí hacían tableros de BI.

    Este proceso corría una vez por dia, involucraba la participación de una persona y no cumplía con los tiempos requeridos por el negocio.

    Nuestro cliente quería evaluar cuidadosamente si nuestra propuesta de inteligencia empresarial hacia sentido para ellos, motivo por el cual propusimos hacer este desarrollo como PoC (prueba de concepto), sin involucrar el armado de un datawarehouse ya que contaban con uno on-premise y tampoco quería instalar servidores ni adquirir nuevas licencias, de manera que teníamos que desarrollar una solución consumiendo de servicios de Nube.

    Solución Propuesta

    Durante la charla propusimos hacer uso de servicios serverless en la nube, Funciones en #AWS o #Azure, donde un script se ejecute para extraer la info, procesarla y dejarla disponible para analizar. Una especie de #ETL #serverless.

    Otra alternativa era armar una infraestructura de eventos con #Kafka o #NiFi. Pero como la solución tenia que ser bajo la premisa de no instalar equipamiento finalmente desistimos de esta opción.

    El boceto cuando armamos la call de Preventa

    Implementación

    Lo primero que hicimos fue eliminar los procesos de ETL que corrían hoy con SSIS, y la base intermedia desde donde conectaban la herramienta de BI.

    Posterior a eso, realizamos el desarrollo de código Python que se ejecuta sobre Azure Functions para tomar los CVS y Parquet de proveedores, extraer la información y llevarla a Data Lake Storage.

    Otra parte corre en Azure Data Factory, un integrador de datos con conectores pre-compilados que nos servían para tomar la info desde las bases relacionales y llevar los datos de manera automatizada, simplificando mucho la extracción de la info y el movimiento hacia Azure Data Lake Storage donde almacenamos lo que llegaba. A eso le sumamos Azure #DataBricks donde corremos la preparación de los datos.

    Databricks es una herramienta de Azure basada en #Apache #Spark que permite configurar de manera simple flujos de trabajo optimizados, dejando la data lista para que DBA, Data Scientist o incluso Analistas de Negocios, dispongan de la información para sus labores.

    Finalmente toda la capa de visualización fue armada en PowerBI, desde donde concentrábamos reportes según el perfil del usuario visualizador.

    Toda la solución lógicamente tiene componentes de seguridad, como Active Directory para la autenticación.

    Entre el assessment, la planificación, y ejecución del proyecto fueron 5 semanas de trabajo donde obtuvimos como resultado un producto de analítica casi en tiempo real, con un costo de menos de 500 USD mensuales pero que generaba insights claros de negocios donde antes no existían.

    Los resultados fueron excelentes porque dieron visibilidad de operaciones comerciales desconocidas. Esta buena recolección de resultados mostraron un ROI muy interesante que motivó avanzar en el proyecto a una Fase 2, que consistió en generar experimentos de Machine Learning organizados desde Databricks y que nos permitieron identificar los modelos con mejor rendimiento respecto al esquema de precios de la compañía.

    La combinación de Azure Databricks y Azure Machine Learning nos permitieron generar un ciclo de vida de ML orientado a predecir compras, comportamientos de clientes, y generar una adaptación del esquema de pricing que significó un aumento en las ventas de la empresa.


    Contactate
    Categories
    54cuatro

    Sabes que es #Serverless?

    Sabes que es #Serverless? Tiene beneficios para los #desarrolladores, es escalable, pero también necesita de ajustes en el #código para que pueda ser ejecutado como funciones (#FaaS), ademas en muchos casos el código puede quedar ligado a su #cloud provider.

    Contactate

      Por favor, demuestra que eres humano mediante la selección la casa.