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?

    Please prove you are human by selecting the house.

    Categories
    54cuatro

    Que es DevOps

    Esta nota fue publicada originalmente en Linkedin

    Ya es sabido que es #DevOps. Un movimiento cultural combinado con una serie de prácticas de desarrollo de software que permiten entregar productos finales de forma rápida.

    DevOps tiene pilares fundamentales como son la comunicación, responsabilidad, respeto y confianza de los miembros de un equipo.

    El uso de herramientas y flujos de trabajo aptos para DevOps puede ayudar a su equipo a trabajar de una manera más DevOps “friendly”, pero es crucial crear una cultura que respalde el ideal del movimiento.

    Analizando algunos ideales, entendemos que el foco está en el producto. Un equipo DevOps trabaja sobre el rendimiento del producto en todo su ciclo de vida, discutiendo los requisitos, las características, los cronogramas, los recursos y la cantidad de datos que podrían surgir, y genera objetivos conjuntos.

    Esos Objetivos medibles comunes pueden ser:

    • Reducir el tiempo de time-to-market.
    • Aumentar la disponibilidad.
    • Reducir el tiempo necesario para implementar.
    • Aumentar el porcentaje de defectos detectados en #testing antes de pasar a producción.
    • Hacer un uso más eficiente de la infraestructura.
    • Proporcionar el rendimiento y la experiencia del usuario al gerente de producto.

    Estos objetivos tienen un impacto monetario en su negocio, ya que le cuesta mas horas-hombre cuando el software tarda mas días de lo planificado en ser liberado. Le cuesta ingresos cuando el producto no está disponible para el uso de sus clientes. Aumenta su costo operativo por ejecutar su infraestructura de manera poco eficiente.

    Tomando lo que sabe sobre estos valores, puede poner un valor monetario para mejorar cualquiera de ellos.

    Su #stakeholder estará interesado en los objetivos mensurables que haya desarrollado.

    Los objetivos nos permiten fijar metas.

    Recuerde que DevOps es un nombre inapropiado: lleve DevOps más allá de los desarrolladores y las operaciones, para incluir aseguramiento de la calidad, servicio al cliente, personal comercial y liderazgo ejecutivo si es posible.

    ¿Necesitamos ser 100% Devops?

    Tal vez no. DevOps es arriesgado para aplicaciones heredadas y organizaciones establecidas. Quizás deba mantener estos dos modos de operación separados según la aplicación. Tal vez necesitamos un sistema híbrido como el modelo definido por Garnet como IT Bimodal.

    #Gartner describe a #IT-Bimodal de la siguiente manera: es la práctica de administrar dos modos separados y coherentes de entrega de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y la precisión. El modo 2 es exploratorio y no lineal, destacando la agilidad y la velocidad. ¿Necesitamos ser 100% DevOps? Quizás no, pero de una forma u otra, se necesita hacer cambios, fundamentalmente romper con los silos y mejorar la productividad.

    (Producto = Tiempo + Recursos)

    Hay dos formas de aumentar la productividad. Disminuir los tiempos o aumentar los recursos.

    Se alienta a los sectores de desarrollo a reducir los tiempos de desarrollo. Y se alienta a los sectores de Operaciones a mantener la productividad. Estos incentivos no son compatibles entre sí.

    DevOps debería ayudar al negocio de la compañía a actuar por igual sobre los responsables del tiempo y los recursos.

    El desafío para cualquier compañía es tener diferentes equipos que funcionen como uno solo.

    Y en ese marco es importante gestionar el Estancamiento y Obsolescencia. Las organizaciones deben asegurarse que los sistemas de información con los que trabajan estén en un proceso continuo de actualización de los componentes. Es por ello que se debe crear un plan de obsolescencia.

    La tendencia actual de IT, es tener todo definido como servicio. #IaaS, #PaaS, #SaaS. Todo será definido por el software. Los sectores de infraestructura deben superar el desafío de la transformación. El modelo de infraestructura actual está orientado a servicios y no a la granja de servidores. “El software se está comiendo el mundo”.

    ¿Cómo llevar un desarrollo obsoleto y estático a un modelo DevOps?

    Una forma de actualizar una aplicación obsoleta es dividir las funciones en microservicios. Un microservicio debe hacer una sola cosa, pero debe hacerlo bien.

    Los microservicios son simples, fáciles, pero es necesario mantenerlos estrechamente controlados y tomar precauciones para que no haya creación descontrolada de microservicios en toda la compañía.

    Tener una entrega continua ayuda a las empresas a mantenerse alineadas con el objetivo de tener un producto de acuerdo con los requisitos del mercado, gracias a la reducción del tiempo de lanzamiento al mercado.

    Y si algo funciona, hay que seguir mejorandolo. No importa qué tan bien funcione un sistema, siempre se puede mejorar. Mejorar y aprender nos ayuda a tener un sistema “vivo” que se adapta mejor a las demandas del negocio.

    Mucho se habla acerca de Herramientas DevOps. Pero… ¿Cuáles son herramientas DevOps?

    • Cualquiera que nos permita automatizar
    • Cualquiera que maneje configuraciones
    • Cualquiera que realice implementaciones automáticas
    • Cualquiera que maneje registros
    • Cualquiera que monitoree desempeño y capacidades

    No existe un método de implementación de herramientas DevOps. Cada uno debe crear su propia caja de herramientas, pero debe centrarse en la automatización. Es importante lograr que cualquier tarea repetitiva sea automatizada. Automatizar aumenta las capacidades de los sistema, reduce las fallas, reduce el tiempo de ejecución y principalmente, puede medirse.

    Que se puede automatizar?

    • Creación de #nubes y #VM
    • #Despliegues de la aplicación
    • Planificación de capacidades
    • Control de Intentos de acceso no permitidos
    • #Backup/#Restore
    • Gestión de configuración
    • Gestión de #parches
    • Actualizaciones de #CMDB (Y acá existe algo importante para mencionar. No importa cuán malo sea tu CMDB, necesitas tener una)

    Lograr el despliegue automático tiene grandes implicancias en la reducción del time-2-market, en reducir la fricción entre desarrollo y operaciones, permite un rollback de manera rápida y disminuye en gran medida los downtimes provocados por fallas.

    Para el control de funcionamiento y fallas, es necesaria una gestión inteligente de eventos ayuda a identificar problemas, errores y posibles desviaciones en el funcionamiento de un sistema. Esta informacion, junto a la medición de rendimiento nos permite medir la capacidad de los recursos para cumplir los objetivos establecidos y saber qué tan bien estamos utilizando nuestros recursos. Y junto con saber sobre la utilización de los recursos, es importante realizar la planificación de capacidades de nuestra plataforma. Conocer el uso de los recursos (y optimizarlos), proponer alternativas tecnológicas, analizar el cumplimiento de SLA, listar riesgos y principalmente aumentar la alineación entre negocios y tecnología.

    DevOps nos permite aumentar el ROI. Porque? Porque en muchas casos nos permite reutilizar infraestructura o aprovechar las ventajas de plataformas más elásticas que se adaptan mejor a la estrategia de la empresa. La nube ofrece un concepto de “pago por uso”, lo que se traducido a gastos permite un ahorro en costos y convertir CAPEX en OPEX.

    ¿Que se puede esperar a corto plazo en materia de DevOps?

    Creo que es importante llevar la conversación de DevOps más allá del ámbito técnico. Participar a la cadena de negocios completa para entregar valor de extremo a extremo. Esto incluye grupos como marketing, ventas, finanzas, legales, recursos humanos y más. Involucrar a estos grupos tan pronto como sea posible en el proceso ayudará a las organizaciones a construir mejores soluciones, al tiempo que evitarán los retrasos que se suelen generar por la burocracia del propio funcionamiento de silos verticales tradicionales.

    Actualización 31/05/2019: esta nota fue publicada en #Infotechnology, mi ultima nota como #CTO de #Nubiral antes de emprender www.54cuatro.com

    [popup_anything id=”2076″]