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

ETL inverso – La integración como motor del cambio

Dentro de lo que llamamos Integración, existen distintos conceptos, distintas arquitecturas e incluso distintas herramientas a considerar.

Elegir una plataforma de integración que permita capturar la data necesaria para ser utilizada es de vital importancia para lograr usabilidad y obtener valor de nuestra información.

Hemos escrito muchas notas en nuestro blog sobre arquitecturas de integración de datos basadas en eventos (Event Stream). En este caso vamos a analizar como el caso de ETL inverso como flujo de eventos es igualmente importante. En los últimos años, con el crecimiento expansivo de la #analítica, han surgido cientas de herramientas de #Integración de Datos, principalmente impulsadas por el #marketing digital.

Herramientas como Fivetran, Hightouch o la #OpenSource Grouparoo permiten crear un pipeline muy simple, de forma declarativa, de donde extraer informacion de varias fuentes y transportarla hacia un destino que permita utilizar esa data para análisis.

Diferencias en los métodos

Los procesos de ETL tradicionales fueron evolucionando. En la actualidad existen múltiples formas de Extraccion. De las mencionadas anteriormente Hightouch permite sincronizar datos con cualquier herramienta SaaS utilizando SQL, donde la sincronización de la tabla se puede modelar como un flujo de eventos. El modelo seria así:

El resto utilizan Conectores prearmados, adecuándose a distintos métodos como conexiones a #API o por medio de SDK, como el caso de Fivetran:

Como se mencionó mas arriba, este tipo de herramientas son impulsada por el marketing digital y suelen tener una fuente determinada de orígenes y destinos, muy relacionados a usar los datos para la mejora de campañas, customer experience, etc.

La integración en otros segmentos

Cuando vamos a un ambiente corporativo donde las necesidades de integración conlleva la extracción de datos para ser usados en casos de uso distintos al del marketing, apelamos por lo general a Extraer, Transformar y Cargar la informacion. Sin embargo, este proceso también ha cambiado mucho los últimos años. Hemos cambiado #ETL a ELT, y aunque la diferencia parezca solo una letra, en la practica el cambio es grande. En un proceso #ELT los datos sin procesar se Extraen (E) del sistema de origen y se cargan (L) en un almacén de datos o data lake y para luego ser transformados (T).

Esta “pequeña” alteración del proceso hace que los equipos de Integración estén adoptando otro enfoque nuevo, llamado “ETL inverso”.

Que es ETL Inverso

En lineas generales, ETL inverso (o reverse ETL) es solo otra canalización de datos. El ETL inverso es lo que hacen las herramientas arriba mencionadas y algunas mas, como Headsup, Polytomic y Seekwell. Básicamente consiste en mover datos desde un almacén de datos a sistemas de terceros para hacer que los datos estén operativos, a través de conectores prestablecidos, tanto para la extracción como el procesamiento e inserción en el destino.

Conclusión

El enfoque ETL inverso está ayudando a redefinir la plataforma de integración de datos al permitir que los equipos de datos creen pipelines de extremo a extremo eligiendo las herramientas que mejor se adapten a sus casos de uso mediante conectores prestablecidos, creando una plataforma que incluya ETL tradicionales, ELT para estructuras de data lake y event streams para plataformas realtime. Las plataformas de integración deben ser lo suficiente flexibles para lograr una canalización que asegure el transito de datos hacia las fuentes o herramientas mas apropiadas para cumplir con los desafíos de negocios que nos propongan, muchas herramientas provistas por proveedores cloud, otras tantas herramientas open source y muchas otras comerciales nos están permitiendo tener un abanico de posibilidades de gran potencia.


Queres saber mas?

Contactate
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?


Contactate
Categories
54cuatro

WebAPI que autentica por token y WebApp que autentica mediante Keycloak

Este desarrollo fue diseñado para un cliente que necesitaba un sistema de #SSO para toda su plataforma de aplicaciones, algunas #API, otras #Rest y otras #SOAP. La gran mayoría de los desarrollos de nuestro cliente eran .NET.

El cliente tenia un desarrollo propio que hacia uso de autenticación y autorización, pero a través de procesos custom. La autenticación usaba usuario y password, se creaba y persistía un #customsession.

El desafio pasaba por comenzar a utilizar un protocolo standard de autorización, el elegido fue oAuth2, protocolo que utiliza #JWT pero configurando tambien SAML para casos donde hubiera necesidad de autenticar y autorizar sobre XML.

Hicimos una #WebAPI que autentica por #Token, y una #WebApp que autentica mediante el form de #Keycloak.

¿Que usamos?

Usamos un stack tecnológico basado en Kubernetes para correr los contenedores del sistema de SSO, y Keycloak como solucion de #IAM (Identity & Access Management).

Video

Esta demo continua el desarrollo efectuado en esta entrada.

En este caso, el principal desafío era implementar una herramienta de autenticación común para todas las app de la empresa. Implementar una solución de administración de identidades tiene como objetivo mejorar la seguridad, pero al mismo tiempo se logra un aumento significativo de la productividad debido a la reducción de las tareas redundante y el re-aprovechamiento de código. Adicionalmente se genera una disminución en los costos.

Beneficios

Desde una plataforma IAM se puede lograr la administracion de usuarios internos y externos, como asi tambien las cuentas de servicios que usan las herramientas y software. Adicionalmente las apps que validan por token pueden hacerlo a traves de la misma herramienta. Es decir, tenemos una plataforma unificada que nos permite:

  • ABM de cuentas de usuario
  • Manejo de contraseñas
  • Inicio de sesión único (SSO)
  • Control de acceso basado en roles (RBAC)
  • Gobernanza de acceso
  • Auditoria y Cumplimiento

Algo destacado es que estos sistemas permiten desarrollar capacidades de autogestión que permite lograr que el usuario tenga una determinada autonomía para recuperar passwords, generar nuevos usuarios, etc.

Resumen

Como conclusión, podemos destacar que un sistema de IAM emplea la tecnología para apoyar la transformación digital. Un software que brinda facilidad de administración, un incremento importante en la seguridad, optimización de los tiempos de desarrollo y satisfacción a los clientes de la empresa.


Si necesitas ayuda, solicita asesoramiento con tu proyecto desde aqui mismo:

Contactate
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

Open Banking en Latam

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 #finteches 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.


Contactate
Categories
54cuatro

DevOps – Los desarrolladores están en el centro de la innovación

No solo sus competidores tradicionales lo reconocen: hay nuevos competidores que comienzan a lanzar #software innovador, trabajando dentro de su sector, pero al revés.

¿Usted elegiría software creado por un puñado de desarrolladores aislados o software creado por miles de personas que trabajan en colaboración para construir algo más sólido? 

Innove a gran escala. Confíe en lo que entrega.

Microsoft #Azure es la nube con servicios de desarrollador integrados y #GitHub construye sobre esta base para convertirse en la Plataforma #DevOps central de #Microsoft.

Aproveche Microsoft DevOps con GitHub para entregar innovación rápida y eficiente. ​

Innovación de producto

Herramientas de administración confiables y escalables en todos los niveles, además de una comunidad diversa detrás de todo

Rapidez de entrega

Para innovar, las empresas deben moverse rápidamente.

Flexibilidad y control

Cualquier desarrollador, cualquier #nube. Use las herramientas que elija, solo traiga el código.

Seguridad

Un líder confiable en seguridad, el mejor.

Acelere la entrega con #DevOps.

Su producto necesita llegar rápidamente a los clientes
y mantenerse disponible.

  • Objetivos y herramientas compartidos
  • Colaboración
  • Automatización de procesos
  • Entrega y mejora continuas

Implementación continua y conforme con la normativa

Servicios integrados de #seguridad, #monitoreo y administración de nivel empresarial

GitHub: El desarrollador de plataformas
nro 1 en el planeta

  • Mayores contribuciones: 1,100 millones en 2018
  • Más desarrolladores: 33 millones
  • Mayor crecimiento: 8 millones de nuevos desarrolladores en 2018
  • Más Repos: 96 millones
  • Mayor actividad: 200 millones de PR, 800 millones de solicitudes diarias de #API 
  • Más estudiantes: 1.1 millones
  • Más organizaciones: 2.2 millones
  • Mayor seguridad: 5 millones de alertas de vulnerabilidad en 2018

Desea crear su plan de desarrollo para implementar DevOps, contactenos

Contactate
Categories
54cuatro-EN

Some loose ideas about containers

It is not new that the containers are already an industry standard, enable agile developments, improve time to market, improve #analytics and generate a quickly verifiable ROI.

We are in a #HYPE moment of the #Microservices era. And we see a lot of adoption of this architecture but there is a long way to go, and there are still many who could not make any progress in this regard and we are already talking about #ServiceMesh, a new component that facilitates communication.

But what is Service Mesh?

Service Mesh is a layer that improves the format in which applications built on Microservices communicate with each other. Previously in #Monolithic or #SOA developments, calls were made within each application or between layers. But in the new scheme, calls are replaced by calls made via #API communications.

This has significant advantages, as it allows developers to focus on business logic and not have to work on the communications layer. But there is a lack of standardization of API communication, as there is no defined protocol for API creation.

This is when Service Mesh becomes important. Why?

Because it is a mesh of services that stands above microservices, being a low latency communications solution that gives us discovery for new services, and with it the possibility to create rules of load balancer, authentication, encryption, among other things , and also allowing us to have monitoring to ensure the availability of our APIs.

There are many Service Mesh on the market such as #Istio or #Envoy, and from #OpenShift version 4 there is the OSMO (Openshift Service Mesh Operator) which enables the possibility of better tracking, routing and optimization of application communication.openshift y service mesh

If you need to modernize the architecture write or call me, so we can determine the level of maturity if your company to adopt microservices, the level of practice Agile / DevOps and with an assessment we can accompany you to the next level.

Posted by our Sales Director, Rodrigo Yañez in https://www.linkedin.com/pulse/algunas-ideas-sueltas-sobre-containers-microservicios-rodrigo-ya%C3%B1ez/

Get in touch

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

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