Introducción a Microservicios

NOTA: Este artículo es del 22/9/16 21:40

Para construir aplicaciones orientadas a servicio, los más habitual es crear una aplicación monolítica, bajo la esquema clásico Model-View-Controller, con un único contenedor que incluye tanto la lógica de negocio como la interfaz de usuario.

Cuando estas aplicaciones crecen y abarcan un gran conjunto de diferentes componentes, módulos y pruebas previas al despliegue; aumentan en proporción al crecimiento de la aplicación (aumento en los tiempos de pruebas, conflictos y revisión de código) en detrimento del tiempo de producción para desplegar y actualizar nuevas versiones en producción. Como solución a estos problemas surgen nuevos patrones de arquitectura como el mencionado aquí.  Pero, ¿qué son las aplicaciones basadas en Microservicios?

Una arquitectura basada en microservices divide el front-end y el back-end, por lo que es más fácil de distribuir, basado en los principios Reactivos para la construcción de un servicio aislado escalable, resistente a fallos y que se combina con otros servicios para formar un todo.

Ejemplo de aplicación en arquitectura de Microservicios con JHipster.

Los microservicios son, en definitiva, una extensión de la arquitectura orientada a servicios para contruír sistemas distribuidos de software. La idea nace de mano del Doctor Peter Rodgers en 2005 introduciendo el término Micro-Web-Services en la presentación de la conferencia Cloud Computing Expo. Más tarde, Adrian Cockcroft en Netflix los describiría como "Arquitecturas Orientadas a Servicio de grano fino" y; James Lewis y Martin Fowler terminan por nombrar a este término como Microservicios:

La "Arquitectura Microservicio" ha surgido en los últimos años para describir una forma particular de diseñar aplicaciones de software como suites de servicios con despliegue independiente.
Si bien no existe una definición precisa de este estilo arquitectónico, hay ciertas características comunes en torno a la capacidad de negocio, el despliegue automatizado, la inteligencia en los puntos de control y el control descentralizado del lenguaje de programación y los datos.

Una aplicación con microservicios se basa en que la versión monolítica debe ser separada en proyectos completamente independientes y que estos se comuniquen entre sí, a través de servicios web, donde cada uno realizará su propia lógica de negocio. Una aplicación a modo de pasarela orquesta estos microservicios para proveerlos al cliente a través de una interfaz de usuario o front-end. Cuando se requiera refactorizar código o actualizar la versión de uno de estos microservicios, al ser completamente independientes se pueden lanzar las pruebas y asegurar la calidad. En caso de éxito en las pruebas, puede resultar sencillo desplegar la nueva versión del microservicio en producción sin afectar al resto.

Ver Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned por Ruslan Meshenberg en GOTO 2016:

Los microservicios contemplan las siguientes características y ventajas:

• Facilitan el reemplazo de cada uno de los servicios, sin tener que eliminar todo el conjunto de la aplicación.
• Los servicios se organizan por capacidades, por ejemplo interfaz de usuario, logística, facturación, etc.
• Los servicios se pueden implementar con diferentes lenguajes de programación, bases de datos, hardware y entornos de software.
• La arquitectura es simétrica y no jerárquica.
• Se presta a un proceso de desarrollo de software de entrega continua. Un cambio de una pequeña parte de la aplicación sólo requiere uno o un número pequeño de servicios a ser reconstruidos y desplegados.
• Obliga a crear una estructura modular.

Como desventajas destacan:

• Los servicios constituyen barreras para la información. Se crearán varias fuentes de datos, que requieren comunicarse entre ellas y realizar varias copias, snapshots y recuperaciones.
• La arquitectura introduce una complejidad adicional y nuevos problemas que resolver, como la latencia de la red, formatos de mensaje, equilibrio de carga y tolerancia a fallos.
• Las pruebas y el despliegue son más complicados.
• Entre las llamadas de los microservicios hay un mayor coste en términos de latencia de la red y el tiempo de procesamiento de los mensajes que en las llamadas en una aplicación monolítica.
• Mover responsabilidades entre los microservicios es más difícil. Puede implicar la comunicación entre los diferentes equipos, refactorizar código de una funcionalidad en otro lenguaje o tener que hacerlo encajar en una infraestructura diferente.

Desde el 2015 el término microservices es bastante hype, ¿quién no desearía migrar su aplicación monolítica a microservicios? Si algún lector está pensando en hacerlo, recomiendo el leer el artículo de Arun Gupta Monolithic to Microservices Refactoring for Java EE Applications y ver el siguiente que presenta en la conferencia Devoxx de 2015 "Refactor your Java EE application using Microservices and Containers":

Fuentes:

• http://jhipster.github.io/microservices-architecture/
• https://en.wikipedia.org/wiki/Microservices
• http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html
• http://martinfowler.com/articles/microservices.html
• http://blog.arungupta.me/monolithic-microservices-refactoring-javaee-applications/

Ethereum y la descentralización con Dapps

NOTA: Este artículo es del 4/1/18 14:52.

 Ethereum es una tecnología basada en Blockchain que nació en 2014 y a mediados de 2015 comenzó su lanzamiento en una ICO inicial. Su diferencia principal a Bitcoin es que Ethereum es "turing" completa, es decir, que permite crear aplicaciones a través de su lenguaje de transacciones.

Ethereum es la primera criptomoneda que ha hecho un cambio de paradigma fundamental en lo que la tecnología Blockchain puede hacer. No es sólo una moneda. Es un ordenador programable accesible desde cualquier parte del mundo descentralizado y que puede hacer cualquier aplicación. Ethereum es un sistema que podría construir cualquier número de monedas alternativas, por ejemplo, se puede reconstruir Bitcoin en Ethereum; sin embargo no se podría reconstruir Ethereum en Bitcoin. Es fundamentalmente más potente, como comparar una calculadora con un ordenador.


Sus creadores definen las unidades como el fuel para la creación de estas aplicaciones. Sus posibilidades se extienden desde realizar pagos, al alquiler y creación de contratos digitales a poder realizar nuevas oportunidades de negocio como micro-mecenazgo y aplicaciones móviles o web con los datos descentralizados.

Un ejemplo son las aplicaciones Dapps que están comenzando a crearse. Los desarrolladores no necesitan realizar el desarrollo de un Backend en un servidor central donde guarda los datos del cliente. En su lugar, se ahorran los costes de esto y se puede crear aplicaciones centrándose tan solo en el usuario, es decir, la aplicación móvil o web. Por ejemplo, un desarrollador podría crear un juego para smartphones basado en un modelo de negocio freemium y que los usuarios sean ellos quienes se encarguen de realizar los pagos a través de Ethereum. Este sistema descentralizado se encargaría de gestionar los datos y enviar los pagos a la cartera del desarrollador así como añadir el contenido adicional en la aplicación. Actualmente ya existen proyecto que se pueden encontrar en web como http://dapps.ethercasts.com/

Otra aplicación muy interesante asociada a Ethereum es la creación de DAOs o Decentralized Anonymous Organizacións. Esto permite que un grupo de personas creen asociaciones aportando el fuel necesario en forma de ether (unidad de esta criptomoneda). Para realizar los gastos en forma de ether de esta comunidad necesitaría de la firma digigal de cada uno de los miembros. Esto es muy similar a como funciona Bitcoin con el sistema de multifirma, donde puedes generar las n-de-m claves, es decir, para enviar bitcoins requiere de la firma de n claves de m totales con las que se generó la dirección. Por ejemplo, si tenemos una multifirma 2-de-3, necesitamos firmar al menos con 2 claves privadas de las 3 claves públicas con las que se generó la dirección. En el caso de Ethereum las posibilidades aumentan, puedes decidir hasta cuantas cantidades pueden enviar unos y cuantas otros, limitar el envío de, por ejemplo, un departamento del DAO al mes o decidir para enviar a unos tienen que firmar todos pero a otros solo se requiere firmar por unas personas determinadas.


Homestead

El pasado 29 de febrero de 2016 el equipo de Ethereum publicaba la próxima primera versión estable, llamada Homestead, anunciando que salían del estado beta en los próximos días (hard-fork a partir del bloque 1500000). En su web https://ethereum.org/ se puede acceder a la descarga de la aplicación.


Metropolis

Metropolis es la tercera etapa de Ethereum en un proceso separado de 4 etapas y hay muchas características interesantes que vienen cuando se implementa. Estos son algunos de los principales que tendrán muchas repercusiones.

     Zk-Snarks: Privacidad con la prueba de conocimiento cero del protocolo Zerocash ideado por ZCash.
     Prueba de implementación temprana de Stake. La migración de Prueba de Trabajo a Prueba de Participación llevada a cabo por Vlad Zamfir.
     Flexibilidad y solidez de los contratos inteligentes.
     Abstracción de cuenta.