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:

[popup_anything id=”2076″]
Categories
54cuatro

Como Openshift acelera los negocios

Openshift es la plataforma de #containers de #RedHat que nos permite entregar a los desarrolladores de aplicaciones web espacios de trabajo para que desplieguen sus códigos realizados en distintos lenguajes de programación.

El corazon de la plataforma

Recordemos que esta aplicación de Red Hat esta basada en Kubernetes (K8s), una plataforma de código abierto que fue originalmente diseñada por Google y liberada a la Cloud Native Computing Foundation (#CNCF) y que sirve para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores.

Ventajas de usar Openshift

Deployment evolution

Dentro de #Openshift cada desarrollador se preocupa por el desarrollo de su aplicación, sin tener que conocer que pasa a nivel infraestructura. Mientras se avanza en el desarrollo, se utiliza un repositorio tal como #Github, ese proyecto creado sera luego el que Openshift tomará como código fuente del repositorio, y desde el cual creará una imagen Docker de forma automática. Esa nueva imagen Docker es la que se utilice para desplegar la aplicación.

Ecosistema de Soluciones

Algo verdaderamente potente, es la posibilidad de integrar a Openshift con todo un ecosistema de soluciones open source, muchas de las cuales fueron tuteladas por Red Hat y permiten armar un gran plataforma funcionando de forma conjunta.

Una capa que brinda Red Hat para sumar a esto es su suite de #Middleware, que incluye:

  • Red Hat Runtimes
  • Red Hat #Fuse
  • Red Hat #3scale #API Management
  • Red Hat #AMQ (Broker, Interconnect, Streaming)

Dentro de estas plataformas se encuentran los tradicionales productos como Jboss. En el caso de 3scale es para destacar que es una solucion de #APImanagement completa, es decir, incluye el #APIgateway, el #APImanager y el #APIportal.

Esto es importante de destacar porque un API gateway por si solo no es una plataforma de API management. El gateway sirve para la integración de las API a nivel backend (ver entrada sobre APIs), pero el Manager y el Portal permiten a los usuarios definir los métodos de autenticación (e incluso integrarse con herramientas de SSO –Ver entrada sobre Keycloak-), límites y control de acceso, monetización, así como el análisis del uso de las APIs y un portal para los desarrolladores. 

Recorrido por la herramienta

Beneficios para todos

Desarrolladores

Como mencionamos, los desarrollares se benefician de Openshift al despreocuparse por la infraestructura, simplificar (y robustecer) la seguridad, optimizar la colaboración entre los grupos de trabajo, y finalmente entregar aplicaciones de forma rápida y segura acelerando el time to market.

Administradores de Infraestructura

Openshift permite entregar ambientes de manera mas rápida logrando disminuir los típicos roces que existen entre las áreas de desarrollo e infraestructura. El área de infra como operador de la platafoma lleva el control, visibilidad y administración.

Habilita DevOps

Hemos escrito muchas notas respecto a que es DevOps. Si bien existen muchos condicionantes que se requieren cumplir, recordemos que DevOps tiene como motor de cambio la integración de equipos de Desarrollo y Operaciones, y para lograr esa integración se necesita habilitar la Colaboración, la Automatización y la mejora continua. Openshift permite que los Devs implementen, creen sus pipelines de código (también hablamos de CI/CD en otras notas) mientras que Ops tengan como responsabilidad entregar una plataforma de contenedores estable y escalable para ello.

OpenShift Origin consoles

Por todo lo anterior, y porque permite actualizar aplicaciones legadas a arquitecturas mas modernas, porque le permite a los desarrolladores entregar aplicaciones robustas y funcionales en menor tiempo, es que Openshift permite acelerar los negocios.

Queres saber mas?


[popup_anything id=”2076″]
Categories
54cuatro

DevOps, DataOps… ¿Y ahora? GitOps

Ya hemos hablado de DevOps, de DataOps, y con el correr del tiempo se incorporan nuevos *Ops.

Mas adelante vamos a escribir de #MLOps, pero ahora vamos a ver de que se trata #GitOps.

¿De donde sale GitOps?

Weaveworks on Twitter: "Great article on #GitOps by @wbiller: "GitOps –  Continuous Deployment für Kubernetes". #CICD #kubernetes #k8s  https://t.co/nUi05zj9DR… https://t.co/PH2fn1qZmc"

GitOps surge principalmente de la necesidad de administración de clústeres de Kubernetes y la entrega de aplicaciones. Para esto es necesario usar #Git, la herramienta numero 1 de #desarrollo. GitOps, se basada en usar Git como única fuente de verdad para aplicaciones e infraestructura declarativa, de esta manera, las herramientas de #GitOps como #ArgoCD (la cual pueden ver como funciona en este post) puede alertar sobre cualquier diferencia existente entre Git y lo que está configurado en K8s, y si hay una diferencia, los reconciliadores de Kubernetes actualizan o revierten automáticamente la configuración. El objetivo por cierto es acelerar y simplificar las implementaciones de aplicaciones como las tareas de operaciones en Kubernetes.

¿GitOps es un reemplazo de DevOps?

Nos suelen hacer esta pregunta cuando hablamos de DevOps. Y la respuesta es: NO!

DevOps es una practica que tiene en cuenta factores culturales, de procesos y de tecnología. En DevOps, la cultura es parte fundamental para asegurarse de que las personas se alineen y trabajen de forma fluida. Pero GitOps incluye aquellas mejores prácticas que unifican la implementación, la gestión y la supervisión de aplicaciones, y la administración de clústeres de #containers.

GitOps por tanto, es un complemento de DevOps, con mayor orientación al desarrollo Cloud Native, Container First, o Serverless.

Además del repositorio de codigo, GitOps hace uso de herramientas de IaC (infrastructure as code) con el fin de administrar los despliegues de infraestructura con un control de versionado de la misma. Herramientas como #Puppet, #Ansible o #Terraform, permiten desplegar servidores y orquestar su implementación, pero el crecimiento exponencial del uso de contenedores junto al despliegue de las aplicaciones que corren sobre ellos potenció la necesidad de contar con herramientas que además de la infra puedan orquestar el despliegue aplicativo.

De esta manera, “recetas” de despliegue de infraestructura pueden ser respaldadas en Git para que sus archivos de configuración puedan ser “mergeados” con flujos de trabajo GitOps. Esto genera una super receta que al ejecutarse permitirá desplegar un servidor junto con su aplicación, con un control exacto de versiones.

¿Cuál son sus beneficios?

  • El principal es el de simplificar las administraciones de las implementaciones. La configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).
  • Existe un control de versiones tanto de la infra como de las apps. Cualquier desviación de la configuración de versión es detectada y corregida de inmediato.
  • Todos los despliegues permiten una rápida vuelta atrás, además de dejar un registro de auditoria de sus ejecuciones.
  • Las implementaciones de aplicaciones son rápidas y confiables.

[popup_anything id=”2076″]
Categories
54cuatro

Algunas ideas sueltas sobre containers

No es novedad que los #containers ya son un standard de la industria, habilitan desarrollos ágiles, mejoran el #TimetoMarket, mejoran la analítica y generan un #ROI rápidamente comprobable.

Estamos en un momento HYPE de la era #Microservicios. Y vemos mucha adopción de esta arquitectura pero existe mucho camino por recorrer, y aún hay muchos que no pudieron a avanzar en este sentido y ya estamos hablando de #ServiceMesh, un nuevo componente que facilita la comunicación.

Pero que es Service Mesh?

El Service Mesh es una capa que mejora el formato en que las aplicaciones construidas en Microservicios se comunican entre sí. Anteriormente en desarrollos #Monolíticos o #SOA, las llamadas se hacían dentro de cada una aplicación o en comunicación entre capas. Pero en el nuevo esquema, las llamadas son reemplazadas por se realizan a través de comunicaciones #API.

Esto tiene ventajas importantes, ya que permite a los #desarrolladores concentrarse en la lógica del negocio y no tener que trabajar sobre la capa de comunicaciones. Pero existe un faltante de estandarización de la comunicación API, dado que no existe un protocolo definido para la creación de API.

En este punto es cuando Service Mesh se vuelve importante. Porque?

Porque es una malla de servicios que se para por encima de los microservicios, siendo una solución de baja latencia de comunicaciones que nos brindara descubrimiento para nuevos servicios, y con ello la posibilidad de crear reglas de load balancer, autenticación, cifrado, entre otras cosas, y permitiéndonos además tener un monitoreo que asegure la disponibilidad de nuestras API.

Existen muchos Service Mesh en el mercado como #Istio o #Envoy, y a partir de la versión 4 de #OpenShift existe el servicio OSMO (Openshift Service Mesh Operator) que habilita la posibilidad mejor seguimiento, enrutamiento y optimización de la comunicación de las aplicaciones.openshift y service mesh

Si necesitas modernizar la arquitectura escribime o llamame, así podemos determinar el nivel de madurez si tu empresa como para adoptar microservicios, el nivel de práctica #Agile/#DevOps y que con un #assessment podamos acompañarte al próximo nivel.

Publicado por nuestro Sales Director, Rodrigo Yañez en https://www.linkedin.com/pulse/algunas-ideas-sueltas-sobre-containers-microservicios-rodrigo-ya%C3%B1ez/

[popup_anything id=”2076″]

Categories
54cuatro

Containers vs Virtual Machines

¿Cuál es la diferencia entre los contenedores y la virtualización basada en Hipervisores?

El concepto de contenedor no es nuevo. Desde hace muchos años existe la creación de contenedores en sistemas corriendo #Solaris, #HP-UX o #AIX. Ahora parece que la contenerización sobre Linux llegó para quedarse a partir de buenas herramientas como #Docker o RKT.

Para diferenciar ambos modelos de virtualización podemos aclarar que en un entorno virtual se debe instalar un servidor físico con un #hypervisor, que dentro contendrá máquinas virtuales cada una con su sistema operativo corriendo.

En el caso de un entorno mediante #contenedores, el servidor físico ejecuta un solo sistema operativo que será compartido con la cantidad de #containers creados. Cada container hace uso del núcleo compartido del sistema con modalidad de “solo lectura”.

¿Qué beneficios conlleva compartir el núcleo de un solo sistema?

En la práctica los contenedores son más livianos, fáciles de administrar y consumen menos recursos que una vm.

Mientras que un container solamente lleva instalado sus aplicaciones particulares, una virtual machine lleva encima todo un sistema operativo instalado.

De esa manera, en un equipo físico se pueden agrupar muchos más contenedores que máquinas virtuales.

A nivel funcional, usar contenedores permite mucha flexibilidad para el escalamiento de recursos, y por otro lado la administración se ve simplificada al tener en un solo kernel toda la plataforma de software de base, dependencias y demás componentes.

¿Los contenedores tienen puntos en contra?

La respuesta es sí. Para cada solución que se busque se debe analizar que conviene. Mientras que para algunos entornos es más apropiado un container, en otros casos la vm es lo apropiado.

Los contenedores suelen tener asociada la impresión de que ante una falla en el sistema operativo host, todos los contenedores se ven afectados, lo que es una realidad. A nivel seguridad en caso de verse comprometido un único sistema operativo, se vería afectado la totalidad de los containers.

De todos modos, los containers existen hace mucho tiempo y tienen larga vida por delante. Muchos artículos suelen enfrentar la tecnología de containers contra la tecnología de virtualización sobre hipervisores. En nuestro modo de ver, creemos que no son competencia sino más bien un complemento uno de otro y que incluso podrían optarse por tener ambientes mixtos.

Por mencionar el caso, Microsoft anuncio que la versión de Hyper-V disponible a partir de Windows Server 2016 permitirá la creación de containers, lo que es un claro mensaje que ambas tecnologías pueden convivir y entre ambas poder brindar soluciones a necesidades cada día más complejas.

Gonzalo D’Angelo

[email protected]

[popup_anything id=”2076″]