Etiqueta: microservicios

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.

[popup_anything id=”2076″]
Categories
54cuatro

Open Banking en Latam

Open Banking

Entrada publicada en Medium.

El dinero es una parte central de la sociedad y de la vida de las personas. Es posiblemente uno de los inventos mas perdurables e innovadores de la historia, junto con la domesticación del perro, y además es la convención social de las mas valoradas. Siempre hemos tenido dinero en diferentes formas, piedras, monedas, billetes, y actualmente bitcoins.

Image for post
Photo by Marcelo Moura – FreeImages

El dinero debe cumplir con 3 funciones:

  • Ser una herramienta de intercambio, para efectuar pagos/transacciones.
  • Tiene que ser una herramienta de resguardo de valor/ahorro manteniendo su valor.
  • Tiene que ser una herramienta de paridad para comparar el valor de productos y servicios.

Gracias a Internet estamos viviendo una época de transformación nunca antes vista, solo comparable con invenciones como la rueda, el papel, la electricidad, el motor a vapor, y la penicilina. Y tenemos que entender como gran invento innovador fue el motor de grandes cambios sociales, de igual manera que lo que esta pasando en la actualidad con la forma de comprar, de consumir contenidos, y también por las finanzas.

Ante la proliferación de monedas como Bitcoin, billeteras electrónicas y otros tantos nuevos productos surge la duda… ¿Qué es Open Banking?

Podemos decir que #OpenBanking es un concepto por el cual las instituciones financieras acuerdan con sus clientes compartir la informacion de estos últimos con otras entidades por medio de mecanismos denominados #API, que permitan a todas las entidades conocer los datos financieros de una personas y de esa manera poder generar productos y ofertas personalizadas.

Open Banking mejorará la capacidad de hacer más actividades financieras desde el smartphone, aumentará la capacidad de manejar mejor los servicios financieros no bancarios puesto que mejorarán la innovación en los servicios y principalmente habrá mayores alternativas de servicios y de mayor calidad dada la competencia entre instituciones.

Pero veamos…. ¿Que es una API?

El término API es dado a una interfaz de programación de aplicaciones. Es una autentica navaja suiza dentro del desarrollo de software. Se trata de un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre dos aplicaciones de software a través de un conjunto de reglas. Podemos hablar de una API como una especificación formal que establece cómo un módulo de un software se comunica o interactúa con otro para cumplir una o muchas funciones. Todo dependiendo de las aplicaciones que las vayan a utilizar, y de los permisos que les dé el propietario de la API a los desarrolladores de terceros.

¿Cómo se benefician los clientes de un banco?

El objetivo principal es que el cliente tenga muchas opciones para elegir, y de esa forma el cliente final gana al obtener mejores ofertas y productos por parte de los bancos.

El desafío mas grande que tienen los bancos (y las #fintech) es generar confianza en los consumidores. La decisión más importante para los consumidores es probablemente a quién confiarle su dinero.

¿Y en el otro extremo, como se benefician los bancos?

Los bancos están trabajando muy fuerte en la modernización de sus sistemas core hacia esquemas full API descomponiendo sus sistemas monolíticos en componentes reutilizables (#microservicios), principalmente aprovechando esquemas de arquitectura basados en API. Para Open Banking, existen 2 tipos de API principalmente, una para obtener información de las personas y sus movimientos bancarios y otra para mover dinero en torno a pagos.

Por tal motivo, los bancos tienen que adecuar sus sistemas para que terceros puedan utilizarlos, lograr tener un banco programable. Es la colaboración llevada al sector de las finanzas. Ceder datos para que terceros desarrollen funcionalidades que antes los bancos guardaban para si mismos.

Como contrapartida, los los bancos tienen una mayor actividad bancaria.

Es importante aclarar que ser un proveedor de datos vía API no garantiza el éxito, los bancos además de adecuaciones tecnológicas tienen que hacer un cambio de mindset, y abrirse a buscar partners que cubran nichos con servicios especializados por ejemplo en cuanto a scoring.

¿Cuál es la situación de los países latinoamericanos?

Muchos paises están avanzando en la reglamentación de Open Banking. Ya hay una Ley Fintech en México, existen regulaciones en Brasil, en Chile ya se definen algunas reglamentaciones de servicios financieros basados en estándares de Open Banking, en Colombia el gobierno comenzó a trabajar con algunos hitos para un mayor desarrollo del sistema financiero. En Perú y Argentina no existen reglamentaciones aun, pero los expertos creen que pronto habrá avances en este sentido.

Mexico, Brasil, Chile, Colombia, Peru y Argentina son de los paises con mayor crecimiento de fintech, y seguramente la implementación en Open Banking sea recibida con buenos ojos por parte de los clientes. Existen buenas practicas como PSD2 y GDPR que dan marcos de buenas practicas por donde comenzar a delinear el futuro.

Vale destacar el caso de PSD2.

#PSD2 es una directiva europea que busca regular la competencia y fomentar la innovación en los mercados de pagos, aumentando la seguridad de los pagos y el acceso a las cuentas.

La normativa estipula dos tipos de entidades financieras:

  • PISP (Proveedores de Servicios de Iniciación de Pagos): quienes ofrecen la posibilidad de iniciar pagos a través de plataformas propias y conectar estas a los bancos para finalizar el pago.
  • AISP (Proveedores de Servicios de Información de Cuenta): que recogen información financiera del cliente de uno o varios bancos y la presentan de manera conjunta al cliente.

Las entidades no tienen que esperar a tener la reglamentación para comenzar a trabajar, basados en la experiencia europea ya se pueden iniciar actividades que permitan esperar la reglamentación en una posición muy competitiva.

Cada invento que marco un quiebre en su era, catapulto la generación de innovaciones sociales, bienvenidos a la era “Open Banking”.

Les dejo mi participación en el webcast de Open Banking para Jiran Consultores de la Ciudad de México.

[popup_anything id=”2076″]
Categories
54cuatro

Patrones de Arquitectura para Microservicios

Acerca de los microservicios

Los #microservicios, son un estilo arquitectónico que estructura una aplicación como una colección de servicios. La arquitectura de microservicios permite la entrega rápida, frecuente y confiable de aplicaciones grandes y complejas.

Al trabajar con microservicios es común que las transacciones tarden mucho en ejecutarse debido a una gran distribución de aplicaciones como bases de datos y servicios que hacen más complejo mantener la consistencia de los datos (ACID). Recordemos que en un entorno de base de datos, ACID es un estándar de las base relacionales, que cumple estos requisitos: Atomicity — Atomicidad: Se ejecutan todas las instrucciones o ninguna, Consistency — Consistencia: Asegura que el estado final sea un estado válido y consistente. Isolation — Aislamiento: Sólo se puede acceder por un agente a la vez, a la información a ser modificada. Durability — Durabilidad: La información modificada tiene que quedar persistida en el repositorio.

Las transacciones locales de ACID tampoco ayudarán si la comunicación ocurre entre servicios separados con múltiples bases de datos.

Patrón de diseño SAGA

SAGA es un modelo de arquitectura publicado originalmente por el departamento de informática de la universidad de Princeton en 1987. Pueden descargar el paper original aquí.

De acuerdo a la descripción del modelo, SAGA es una secuencia de transacciones locales donde cada transacción actualiza los datos dentro de un solo servicio.

Hay un par de formas diferentes de implementar una transacción de saga, pero las dos más populares son:

  • Eventos / coreografía: cuando no hay coordinación central, cada servicio produce y escucha los eventos de otro servicio y decide si se debe tomar una acción o no.
  • Comando / Orquestación: cuando un servicio coordinador es responsable de centralizar la toma de decisiones y la secuencia de la lógica de negocios de la saga.

Vamos a usar estas imágenes de https://microservices.io para graficar cada modelo y que se entienda como funcionan:

Modelo EVENTOS
Modelo ORQUESTRADO

Ejemplo de una plataforma de stream de datos con Apache #Nifi

Beneficios de usar SAGA como patrón de arquitectura

Los eventos / coreografía es una forma natural de implementar el patrón de Saga, es simple, no requiere mucho esfuerzo para construir. Es un patrón muy atractivo para casos donde la transacción de su aplicación implica de 2 a 4 pasos. Este enfoque puede volverse confuso rápidamente si sigue agregando pasos adicionales en su transacción, ya que es difícil rastrear qué servicios escuchan qué eventos. Ademas las pruebas serían difíciles de implementar usando este diseño, para simular el comportamiento de la transacción, debe tener todos los servicios corriendo.

SAGA es un modelo muy util que permite que una aplicación mantenga la consistencia de datos en múltiples servicios sin usar transacciones distribuidas.

Prueba de Concepto

En #github, #Microsoft tiene una solución que simula un escenario de transferencia de dinero, donde se transfiere una cantidad entre cuentas bancarias a través de operaciones de crédito / débito y se genera un recibo de operación para el solicitante. Es una referencia de implementación del patrón #Saga a través de un enfoque de orquestación en una arquitectura sin servidor en #Azure. La solución aprovecha Azure #Functions para la implementación de los participantes de Saga, Azure Durable Functions para la implementación del Saga orchestrator, Azure Event Hubs como plataforma de transmisión de datos y Azure Cosmos DB como servicio de base de datos.

Repo disponible en: https://github.com/Azure-Samples/saga-orchestration-serverless

Architecture Overview
[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

Es el momento de DataOps. Conoce los detalles

#DataOps , es una metodología surgida de las culturas #Agile que busca cultivar prácticas y procesos de gestión de datos para mejorar la velocidad y precisión de los análisis, incluido el acceso, calidad, automatización, integración y modelos de datos. 

#DataOps se trata de alinear la forma en que administra sus datos con los objetivos que tiene para esos datos.

No esta mal recordar parte del Manifiesto DataOps:

  1. Personas e interacciones en lugar de procesos y herramientas
  2. Soluciones de analítica eficientes en lugar de documentación comprensiva
  3. Colaboración con el consumidor en lugar de negociaciones contractuales
  4. Experimentación, interacción y retroalimentación en lugar de un diseño extensivo directo
  5. Titularidad multidisciplinar de las operaciones en lugar de responsabilidades aisladas.

Vamos a poner un ejemplo claro de DataOps aplicado a la reducción de la tasa de rotación de clientes. Puede aprovechar los datos de sus clientes para crear un motor de recomendaciones que muestre productos que sean relevantes para sus clientes, lo que los mantendría comprando por más tiempo. Pero eso solo es posible si su equipo de ciencia de datos tiene acceso a los datos que necesitan para construir ese sistema y las herramientas para implementarlo, y puede integrarlo con su sitio web, alimentar continuamente nuevos datos, monitorear el rendimiento, etc. Para eso necesita un proceso continuo que requerirá incluir información de sus equipos de ingeniería, TI y negocios.

Para poder implementar soluciones que aporten valor, es necesario de la gestión de datos saludables. Una mejor gestión de datos conduce a mejores datos, y más disponibles. Más y mejores datos conducen a un mejor análisis, lo que se traduce en mejores conocimientos, estrategias comerciales y una mayor rentabilidad.

DataOps se esfuerza por fomentar la colaboración entre científicos de datos, ingenieros y expertos de TI para que cada equipo trabaje sincronizado en aprovechar los datos de la manera más adecuada y en menor tiempo.

DataOps es una de las muchas metodologías nacidas a partir de DevOps. El éxito de #DevOps radica en eliminar los silos de la TI tradicional: uno que maneja el trabajo de desarrollo y otro que realiza el trabajo operativo. En una configuración de DevOps, la implementación del software es rápida y continua porque todo el equipo está unido para detectar y corregir problemas a medida que ocurren.dataops

DataOps se basa en esta idea, pero aplicándola en todo el ciclo de vida de los datos. En consecuencia, los conceptos de DevOps como CI/CD ahora se están aplicando al proceso de producción de ciencia de datos. Los equipos de ciencia de datos están aprovechando soluciones de control de versiones de software como GitHub para rastrear cambios de código y tecnología de contenedores como Kubernetes y Openshift para crear entornos para Análisis y despliegue de modelos. Este tipo de enfoque de ciencia de datos y DevOps a veces se denomina “análisis continuo”.

Ahora bien. Hasta acá toda la teoría. Pero… ¿Cómo empiezo a implementar DataOps?

Aquí es donde debes comenzar:

  • #Democratice sus datos. Elimine las barreras burocráticas que impiden el acceso a los datos de la organización, cualquier empresa que se esfuerza por estar a la vanguardia necesita conjuntos de datos que estén disponibles.
  • #Aproveche las plataformas y las herramientas de código abierto. Plataformas para movimiento de datos, orquestación, integración, rendimiento y más.
  • Parte de ser ágil es no perder el tiempo construyendo cosas que no tiene que hacer o reinventar la rueda cuando las herramientas que su equipo ya conoce son de código abierto. Considere sus necesidades de datos y seleccione su pila tecnológica en consecuencia. 
  • #Automatizar, automatizar, automatizar. Este viene directamente del mundo de DevOps, es imprescindible que automatice los pasos que requieren innecesariamente un gran esfuerzo manual, como pruebas de control de calidad y monitoreo de canalización de análisis de datos.
  • Habilitar la autosuficiencia con #microservicios. Por ejemplo, dar a sus científicos de datos la capacidad de implementar modelos como #API significa que los ingenieros pueden integrar ese código donde sea necesario sin #refactorizar, lo que resulta en mejoras de productividad.
Si quiere saber mas, recomendamos entrar a nuestro grupo de Linkedin, DataOps en Español.
[popup_anything id=”2076″]
Categories
54cuatro

Preciado Time to Market (en español)

Este articulo fue publicado en linkedin 

#Agile, #DevOps, #Cloud, #Microservicios, pusieron en foco optimizar el Time to Market (o sus derivados #TTM, #T2M, #Time2Market).

¿Pero que es realmente Time to Market y porque es tan importante?

El TTM se relaciona directamente con la velocidad con la que un producto puede ser lanzado o en el caso de la tecnología, en la rapidez con la que se puede entregar valor (ya sea un nuevo producto, una nueva característica de algo existente, una mejora, etc).

El TTM es importante por motivos varios. En la actualidad, los clientes, tanto internos como externos, se han vuelto más exigentes. Exigen mayor calidad y mayor velocidad. Es también importante porque la agilidad con que se crean nuevos productos, se agregan nuevas características o se genera valor es un diferencial respecto a competidores más lentos, por lo tanto, una ventaja competitiva.

Focalizando en lo que hace a productos tecnológicos, años atrás cuando el modelo de desarrollo estaba basado en una metodología de cascada, los ciclos de vida de desarrollo eran muy altos, lo que generaba cancelaciones de proyectos, mayor tasa de errores, y hasta la depreciación de lo que se estaba construyendo antes de conocer la luz. Todo esto representaban perdidas económicas significativas.

En la actualidad, con metodologías ágiles de trabajo y la automatización de las cadenas de desarrollo, se logró que la entrega de software sea más rápida y regular, lo que genere una ventaja competitiva, aumentando la calidad y optimizando tiempos, algo que se torna importante tanto para el #Time2Market como para la optimización del #ROI, promueve la mejora continua y por lo tanto existe un notorio aumento del rendimiento y la rentabilidad.

Optimizar el TTM trae aparejado aspectos muy positivos. Al tener toda nuestra cadena de desarrollo automatizada, es más simple recolectar los resultados del testing, e incluso del feedback de los usuarios, lo que permite no solo mejorar la calidad del software sino incluso re-adaptar las estrategias empresariales. También, a partir del desarrollo SOA y ahora Microservicios, se logró reducir la tasa de errores, ya que desarrollos chicos suelen tener menos complicaciones que aquellas implementaciones gigantes (monolíticas) que requerían muchos cambios, muchas personas, mucha burocracia.

Resumiendo: la capacidad de entregar desarrollos de forma ágil, cumpliendo con estándares de calidad, eficiencia y seguridad, nos permite crear valor en las compañías, mejorar los costos operativos y marcar diferenciales competitivos de mercado que se terminan traduciendo en mejor imagen de la compañía, mayores ventas y ahorros operativos.

Entonces… ¿Es importante mejorar el time to market? ☺

[popup_anything id=”2076″]

54cuatro © 2024. All rights reserved.