Arquitectura Limpia

 

En esta ocasion escribire sobre arquitectura limpia, algo no nuevo, pero si en tendencia. Dicha arquitectura reutiliza el mismo enfoque de sus predecesoras (hexagonal, onion, etc) pero le agrega ciertas capacidades como son:

•   Introduce el concepto de "entidades" en vez de "modelos de dominio", sin embargo siguen representando la informacion core del negocio.
•   Adiciona el concepto de "Streaming Architecture", cuyo objetivo es exponer lo mas explicito posible lo que aplicacion hace. De hecho refuerza el concepto de casos de uso para sean estos los que reflejen de forma clara y concreta el alcance de la solucion. 

Como ventaja podemos encontrar las siguientes:

•   Separacion en capas: Define la separacion en componentes de negocio y la infraestructura, lo cual ofrece un bajo acoplamiento y otorgando escalabilidad y mantenibilidad del codigo.
•  Regla de dependencia: Define que las dependencias solo pueden provenir de afuera hacia adentro, lo que hace que las capas interiores desconozcan como se exponen los datos al exterior, reforzando de esa forma su autonomia.

 Como componentes o capas de la arquitectura limpia tenemos lo siguiente :

 

• Entidades: Son el conjunto de modelos o entidades core de la aplicacion. Estan muy relacionados al  concepto de dominios si se usa DDD (Domain-Drive Desgin).  
• Casos de Uso: Son las funcionalidades que expondra la aplicacion, en esta capa solo se lista el "que" mas no el "como", solo interactuando con las entidades para lograr tal fin.
• Adaptadores de interfaz: Son el puente entre los casos de uso y el mundo exterior. Aca se define la forma de como se comunicaran con la infraesctructura.
• Infraestructura: Representan los agentes externos como pueden ser las base de datos, los frameworks, interfaz web, los manejadores de colas, etc.

A continuacion algunos ejemplos de su implementación:

En el primero, podemos observar que la infraestructura corresponde a un proveedor de nube y contamos con dos tipos de adaptores, uno para la exposicion "publica" de los servicios expresados en casos de uso y otra para conectarse a repositorios. Y vemos como las capas inferiores (casos de uso y entidades) son independientes de dicha integracion.  

En el segundo, podemos observar que la infraestructura corresponde a un ambiente onpremise y contamos con dos tipos de adaptores, uno para la exposicion "publica" de los servicios expresados en casos de uso y otra para conectarse a un repositorio mas un manejador de colas. Y vemos como las capas inferiores (casos de uso y entidades) son independientes de dicha integracion.  

Conclusiones:

Hemos visto muchas de las ventajas que nos proporciona adoptar este tipo de arquitectura, sin embargo, sugiero tomarlo como referencia y adaptarlo a que nos haga sentido y util, segun el contexto y la necesidad. En las referencias incluyo algunos scaffold de guia para poder implementarlos en nuestros proyectos.

Referencias:

https://www.sam-solutions.com/blog/building-microservice-with-onion-architecture/

https://nescalro.medium.com/entendiendo-a-la-arquitectura-limpia-7877ad3a0a47

https://dev.to/dyarleniber/hexagonal-architecture-and-clean-architecture-with-examples-48oi

https://www.thoughtworks.com/insights/blog/architecture/demystify-software-architecture-patterns#:~:text=In%20short%2C%20the%20key%20difference,UI%20to%20the%20outer%20circle.

https://medium.com/@edamtoft/onion-vs-clean-vs-hexagonal-architecture-9ad94a27da91

Scaffold - Clean Archicterure NodeJS

https://github.com/jbuget/nodejs-clean-architecture-app

Scaffold - Clean Archicterure Java y kotlin

https://github.com/bancolombia/scaffold-clean-architecture

 

Guía para elaborar un documento de arquitectura

En este oportunidad, escribo el presente articulo con la finalidad de socializar los pasos a seguir (a tomar como referencia) cuando se plantea un arquitectura propuesta ya sea en un entorno onpremise, cloud, hibrido u otro. Muchas veces cuando no se cuenta con una metodología o marco de apoyo, creemos que erróneamente que lo primero y lo único del proceso es diseñar los diagramas utilizando diferencias modelos de vistas, y es que los diagramas son solo parte final de dicho proceso.

Otro punto a considerar es que lo que se vaya a proponer este muy alineado a los objetivos de negocio y resultados clave que la compañía quiere lograr, en ese sentido toca en este etapa socializar y realizar el levantamiento de información que te ayude con ese objetivo. Para realizar todo el proceso me apoye en las siguientes metodologías domain-driven design y atribute-driven design a modo de referencia y sigue a continuación los pasos: 

Primero: Opcional colocar un alcance a alto nivel y si se puede incluir un mapa de proceso (as-is) que represente el proceso actual que se quiere mejorar junto con los objetivos de negocio e indicadores clave que se quiere lograr.

Segundo: Mapear los objetivos técnicos, tanto generales como específicos.

Tercero:  Definir los dominios principales, genéricos y de soporte. Los principales son los que serán parte del core de la solución, los dominios genéricos será reutilizables en la solución, con potencial en convertirse en transversales en la organización,  y finalmente los de soporte suelen ser habilitadores externos que usara la solución pero no corresponde a la autoría de la organización.

Tercero: Definir los bounded context los cuales vienen a representar subdominios, ahora mas aterrizados, agrupados y relacionados.

Cuarto: Listar el lenguaje ubicuo a usar para tener alineado el significado de los términos según el contexto de la solución.

Quinto: Definir los drivers de arquitectura o atributos de calidad y validar su orden de priorización de acuerdo a los objetivos de negocio identificados previamente. Dichos atributos de calidad se basan en la norma ISO-25000.

Sexto: Definir los tácticas (generalmente técnicas o estrategias arquitectónicas) que influyan en el logros de los atributos de calidad mapeados previamente.

Séptimo: Listar las restricciones de arquitectura, acá se definen todo lo que se tiene que usar si o si y no es negociable que pueden impactar en las decisiones de arquitectura que se sugieran.

Octavo: Definir los riesgos del proyecto que se den durante el proyecto, el cual requiere tomar o redefinir los atributos y las decisiones de arquitectura.

Noveno: Sugerir y proponer las decisiones de arquitectura que deberá estar técnicamente fundamentadas y que incluya otras aproximaciones documentadas con los riesgos que implique.

Decimo: Finalmente elaborar los diagramas según el modelo de vista que se escoja o genere mas valor y que incluya todo lo definido anteriormente.

Referencias:

https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf

https://iso25000.com/index.php/normas-iso-25000/iso-25010

https://sites.google.com/site/softwarearchitectureinpractice/

http://www.cs.unibo.it/~cianca/wwwpages/as/9.pdf

  

  

CSFLE (Client Side Field Level Encryption) Framework

 Hola Comunidad, en esta oportunidad hablare sobre el CSFLE (Client Side Field Level Encryption) framework para la encriptación de datos. Dicho framework brinda el cifrado como decifrado de la información en reposo usando una DEK (Data key Encryption), la cual a su vez (dicha llave) es encriptada usando un CMK (Customer Master Key) implementada por el cliente mediante un KMS (Key Management Service) local o de un tercero.

Existen diferentes mecanismos o estrategias de asegurar la data, ya que se pueden realizar en diferentes niveles. El framework CSFLE es el mas completo ya que abarca o comprende todas las áreas de encriptación como muestra a continuación:

Fuente: https://visweshwar.medium.com/client-side-field-level-encryption-csfle-on-mongodb-community-ed-using-java-spring-a6489a5c9146

A la fecha del presente articulo, la versión 4.2 MongoDB implementa dicho framework usando la librería libmongocrypt. 

La etapa de encriptación se divide en 2 etapas:

• La primera corresponde a la creación de la CMK y DEK, y la encriptación de esta ultima en un Key Vault.
• La segunda corresponde al uso de la DEK (que primera tendrá que ser desencriptada usando la CMK), para encriptar los datos sensibles en la mongo.

Los pasos de la primera etapa se resume a continuación:

                                      

Fuente: https://visweshwar.medium.com/client-side-field-level-encryption-csfle-on-mongodb-community-ed-using-java-spring-a6489a5c9146

1. Primero es necesario crear la CMK usando un KMS  que puede ser implementado de forma local o mediante un cloud provider (AWS o Azure por ejemplo), la cual servirá para encriptar la DEK. 
2. Segundo se crea la DEK usando la librería libmongocrypt el cual usa la estrategia envelope encryption.  
3. Finalmente, se encripta la DEK usando la CMK y se almacena en un Key Vault.

Los pasos de la segunda etapa se resume a continuación:

Fuente: https://visweshwar.medium.com/client-side-field-level-encryption-csfle-on-mongodb-community-ed-using-java-spring-a6489a5c9146

1. Primero es necesario acceder a la DEK almacenada en la Key Vault. 
2. Segundo es necesario desencriptar la DEK usando la CMK almacenada por el KMS elegido.
3. Finalmente, usamos la DEK para encriptar o desencriptar los datos sensibles de la aplicación en cuestión.

Con respecto a los algoritmos de encriptación usados, se maneja un esquema hibrido basado en MAC junto a uno determinístico o aleatorio. La librería por ahora solo soporta AED_AES_256_CBC junto con HMAC-SHA-512 MAC.

Otro punto es que la versión community de MongoDB maneja una encriptación manual mientras la versión enterprise y Atlas de MongoDB automatiza el proceso de encriptación usando el proceso Mongocryptd.

Referencias:

https://visweshwar.medium.com/client-side-field-level-encryption-csfle-on-mongodb-community-ed-using-java-spring-a6489a5c9146

https://visweshwar.medium.com/mongodb-client-side-field-level-encryption-using-java-spring-part-2-community-edition-manual-2e9775e8c169

https://www.mongodb.com/docs/manual/core/csfle/

https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/#mongo.jsonSchema.encrypted-fields

http://mongodb.github.io/mongo-java-driver/3.12/driver-async/tutorials/client-side-encryption/

https://www.mongodb.com/developer/languages/csharp/use-azure-key-vault-mongodb-client-side-field-level-encryption/

https://github.com/mongodb-university/docs-in-use-encryption-examples/blob/main/csfle/java/azure/reader/src/main/java/com/mongodb/csfle/makeDataKey.java

https://www.mongodb.com/docs/manual/core/csfle/tutorials/azure/azure-automatic/#std-label-csfle-tutorial-automatic-azure

Management Redis

Hoy escribiré un poco acerca de Redis y su administración. Redis (Remote Dictionary Server) es un software de código abierto, el cual usa una estructura de datos en memoria (clave-valor) y es comúnmente usado para la capa de cache de las aplicaciones por su versatilidad y rapidez.

A continuación una arquitectura simple de un clúster Redis con 3 nodos master, cada uno con su replica.

A continuación algunos tips en cuanto a la administración de Redis a tomar en cuenta:

-Usa la herramienta de análisis latency doctor (>latency doctor) para el monitoreo e información de los problemas de la latencia existentes y consejos sobre sus posibles soluciones.

-Usa el comando monitor (>redis-cli monitor) para visualizar cada comando procesado por el servidor REDIS (usar por precaución por tema de rendimiento de memoria).

-Usa el comando stats (>redis-cli --stat) para monitorear en tiempo real el comportamiento de las instancias Redis, en cuando al uso de memoria, conexiones de clientes entre otras estadisticas.

-Si quieres aplicar un política de rotación (algoritmo) de claves almacenadas en base a la memoria alcanzada puedes usar como ejemplo:

    maxmemory 2mb
    maxmemory-policy allkeys-lru

Donde ya no seria necesario configurar un TTL (expire) para las claves del lado de la aplicación, sino que todas la claves será eliminadas utilizando un algoritmo LRU siempre que alcancemos el limite de memoria de 2mb.

Los diferentes algoritmos o políticas de rotación son las siguientes :

1. allkeys-lru mantienes las claves usadas recientemente; elimina las claves usadas menos reciente.
2. allkeys-lfu mantienes las claves de uso frecuente; elimina las menos frecuente.                       
3. volatile-lru elimina las claves menos usadas recientemente con el campo "expired" establecido en true.
4. volatile-lfu elimina las claves utilizadas con menos frecuencia con el campo "expired" establecido en true.
5. allkeys-random elimina aleatoriamente las claves para hacer espacio a los nuevos datos agregados.                    
6. volatile-random elimina aleatoriamente las claves con el campo "expired" establecido en true.                          
7. volatile-ttl elimina las claves usadas con menos frecuencia con el campo "expired" establecido en true y el valor de tiempo de vida restante (TTL) mas breve. 

-Para aplicar alta disponibilidad puedes usar un Redis cluster o un Redis sentinel, cada uno con 1 o mas replicaciones.

-En cuanto a las replicas tomar en cuenta las siguientes consideraciones:

• Cada master puede tener múltiples replicas.
• Cada replica puede conectarse con otra replica asociado al mismo master, en una estructura tipo cascada.
• Durante la resincronización (inicial o parcial) de cada replica, no bloquea la operatividad del master.
• Durante la resincronización (inicial o parcial) de cada replica, esta puede seguir operando (en un hilo distinto) con la antigua data.
• Las replicas pueden ser usada para alta disponibilidad o escalabilidad.
• Para alta disponibilidad como para las replicas es importante en lo posible tener activado la persistencia de la data, o al menos tener el auto-reinicio desactivado.

-En cuanto a la seguridad se sugiere usar Redis ACL o Redis TLS.

-Adicionalmente en cuanto a la optimización puedes usar:

• Benchkmark: Usar benckmark (>redis-benchmark), utilidad que simula la ejecución de comandos realizados por N clientes al mismo tiempo que envías M consultas en total.
• Latency issues: Usar el comando latency (>redis-cli --latency) para medir la latencia del servidor en milisegundos y/o la herramienta latency doctor anteriormente descrito, como algunas opciones de verificación.
• Memory optimization: En cuanto a la optimización de memoria dado que se trata de un tema de CPU/memoria, una opcion es ajustar la cantidad máxima de elementos y el tamaño máximo de cada elemento par tipos de datos especiales codificados utilizando las siguientes directivas:
• has-max-ziplist-entries 512
• has-max-ziplist-value 64
• zset-max-ziplist-entries 128
• zset-max-ziplist-value 64
• set-max-intset-entries 512

Mas información se puede encontrar en : https://redis.io/docs/

OAUTH 2 y OpenID Connect

 Hola suscriptores y lectores en general, en esta oportunidad les contare mi interpretación sobre dos frameworks de seguridad basados en la autorización y autenticación como lo son Oauth2 y OpenID Connect.

Comenzaremos con Oauth2, es un framework de autorización que plantea un mecanismo seguro de autorización a recursos mediante el uso de un servidor de autorización.  Es decir una aplicación cliente delega la autorización a un tercero para que esta (aplicación cliente) pueda tener acceso a ciertos recursos (mediante consentimiento) de un determinado usuario, llamado propietario del recurso (owner).

Existen diversos mecanismos (flujos) llamados grants por la cual podemos asegurar dicha autorización como son los siguientes: 

• Client credentials
• Resource Owner
• Implicit Flow
• Code authorizacion
• Code authorizacion + PCKE
• Hybrid Flow entre otros

A continuación explicaremos alguno de ellos:

Client credentials, usado generalmente para que lo use una aplicación cliente sobre un backchannel (canal seguro entre el cliente y el servidor de autorización). Ejemplo: la aplicación cliente X necesita acceder o conocer los twits (recurso) realizados por una determinada persona. Uso recomendado para autorizaciones entre backends.

Resource Owner, usado generalmente para que lo use una aplicación cliente legacy sobre un frontchannel (canal expuesto entre la aplicación y el servidor de autorización) exponiendo las credenciales del usuario. Ejemplo: la aplicación cliente legacy X necesita acceder a los datos tributarios (recurso) de sus empleados. Uso recomendado cuando no sea posible usar un mecanismo de redireccionando.

Implicit Flow, usado generalmente para que lo use una aplicación cliente con soporte a navegador sobre un frontchannel (canal expuesto entre la aplicación y el servidor de autorización)  y adicionado un callback URL, el cual sirve para redireccionarte de regreso a la aplicación cliente. Ejemplo la aplicación cliente X te direcciona a la aplicación Facebook para que el usuario se autentique y otorgue consentimiento de obtener los contactos (recurso) a la aplicación cliente X.

Code Flow,  usado generalmente para que lo use una aplicación cliente con soporte a navegador sobre un frontchannel (canal expuesto entre la aplicación y el servidor de autorización)  y adicionado un callback URL, a diferencia del Implicit Flow, luego de redireccionarte de regreso se recibe un code que sirve para realizar otra llamada mediante un canal backchannel al servidor de autorización para recién recibir el Acces token. Ejemplo la aplicación cliente X te direcciona a la aplicación Facebook para que el usuario se autentique y otorgue consentimiento de obtener los contactos (recurso) a la aplicación cliente X.

Code + PCKE Flow, usado generalmente para que lo use una aplicación cliente con soporte a navegador sobre un frontchannel (canal expuesto entre la aplicación y el servidor de autorización)  y adicionando un callback URL, a diferencia del Implicit Flow, y adicionando un desafío, a diferencia del Code Flow, luego de redireccionarte de regreso se recibe un code que sumado al resultado del desafío sirve para realizar otra llamada mediante un canal backchannel al servidor de autorización para recién recibir el Acces token. Ejemplo la aplicación cliente X te direcciona a la aplicación Facebook para que el usuario se autentique y otorgue consentimiento de obtener los contactos (recurso) a la aplicación cliente X.

Por otro lado, tenemos a OpenID Connect un protocolo de autenticación, el cual agrega una capa sobre Oauth2 para incluir un mecanismo de autenticación. Es decir a parte de delegar la autorización al recurso, nos interesa ahora autenticar al dueño (owner) del recurso. Para ello se adiciona un componente a la información devuelta por el Servidor de Autorización que es el Id Token (expresado en JWT), el cual generalmente sirve para que el cliente pueda validar la identidad del owner que accederá al recurso. A continuación un ejemplo usando como flujo oauth2 el Code Flow.

Referencias:

https://datatracker.ietf.org/doc/html/rfc6749

https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth

https://auth0.com/docs/get-started/authentication-and-authorization-flow

https://www.youtube.com/watch?v=t18YB3xDfXI

https://www.youtube.com/watch?v=nNVlewjKQEQ

https://auth0.com/docs/get-started/authentication-and-authorization-flow

Oracle GroundBreaker Tour Lima 2019

 Que tal seguidores, en esta oportunidad tuve la oportunidad de asistir al evento Oracle GroundBreakers Tour 2019 América Latina - Perú, antes conocido como el Oracle Technology Tour (OTN tour) , realizado en la Universidad de Lima el miércoles 28 de agosto del 2019.

El evento fue publicado en la pagina de PEOUG http://www.peoug.org/ogbtour2019/ , donde actualmente han colocado un vídeo y fotos del evento. La agenda del evento lo han retirado pero lo pueden descargar desde: https://docs.google.com/viewerng/viewer?url=http%3A%2F%2Fwww.peoug.org%2Fwp-content%2Fuploads%2F2019%2F08%2FOGB_Tour_2019_Agenda.pdf&hl=es&urp=gmail_link


Bien, la primer charla a la cual asistí, fue la de Alexi Lopez (Java Champion - Java Tools & Frameworks) con el tema Microservicios para desarrolladores JEE, en el cual hablo sobre Microprofile, específicamente sobre la versión 3.x y su compatibilidad con JAVA EE8, así como ciertas mejoras que trae consigo en comparación con su versión anterior,como son la adopción de health check y metrics version 2.0, el cual te ofrece información mas precisa de la salud de tus microservicios, los cuales muchas veces dependen de otros microservicios o recursos externos (Base de datos por ejemplo), entre otras nuevas características que comparto en las referencias bibliográficas.  Para los amantes de Spring Boot, dejo como tarea para el lector hacer un benchmarking con Spring Admin o Spring Actuator.

Luego comento sobre la integración con Prometheus, una herramienta de monitoreo Open Source capaz de leer las métricas y mostrar estadísticas en un entorno mas intuitivo. Dejo un ejemplo de integración en los links de la referencias bibliográficas.

Luego otro punto que menciono que me pareció interesante, fue sobre la economía de las APIS, haciendo referencia, que ya es una tendencia y que muchas empresas ya la ven como un negocio, exponiendo sus APIS para que puedan ser consumidos por otras aplicaciones o usuarios finales, para que finalmente, luego de un determinado uso, se pague según la cantidad de usuarios que la consuman.

Luego realizo un pequeño tutorial, con microprofile sobre PayaraMicro, una versión minimalista de Payara Server, cuyo tamaño es de solo 70 MB.

Finalmente hablo sobre las ventajas de usar Oracle Application Container Cloud y
Developer Cloud Service ambos servicios en la nube de Oracle Cloud (también llamados PAAS - Plataform as a Service), el primero mas parecido a una infraestructura como servicio lightweight donde puedes desplegar desde aplicaciones basadas en plataforma JAVA SE como muchas otras mas. Y la segunda orientada mas a la integración y despliegue continuo de aplicaciones entre otras características, para los amantes de AZURE, parecido a AZURE DEVOPS. Dejo algunos links de tutoriales en las referencias bibliográficas.

Oracle Application Container Cloud

Developer Cloud Service

Otra charla que me pareció interesante, fue la de Monica Godoy (Oracle Forms & APEX Developer) juntamente con Alexis Sanchez (Java Champion - Java Tools & Frameworks), con el tema Oracle APEX como frontend para tu Java backend, básicamente Alexis desarrollo unos APIS Rest usando donde uso tecnologías como JAX-RS, CDI (Contexts and Depedency Inyection), Hibernate/JPA, Payara micro, para luego crear un Uber JAR para empaquetar tanto la aplicación como las dependencias, listo para ser desplegado en Oracle Application Container Cloud. Finalmente, Monica explico, mediante una demo, la características de Oracle APEX posee para crear aplicaciones escalables, seguras, rápidas y de bajo costo. La demo consistía en que a partir de los endpoints creados por Alexis, puedas crear regiones CRUD en cuestión  de minutos. Tutoriales y documentación al respecto lo pueden encontrar en https://apex.oracle.com/es/.

Otro punto interesante que menciono, fue sobre ApiAry de Oracle, una plataforma colaborativa para documentar APIS, del estilo de swagger, raml o blueprint, incluso diría con algunas características adicionales interesantes, también cuenta con un plan free para los que quieran probarla,  mas detalle lo pueden encontrar en : https://apiary.io/

Otra charla que me pareció interesante fue la de Cecilia Pereira (Sales Engineer SOLA - QUEST SOFTWARE) con el tema Administre su entorno de BD en devops, protegiendo sus datos sensibles, y digo interesante por la novedad de aplicar la tendencia Devops ya no solamente en un ambiente de desarrollo de software sino también en  un ambiente de administración de Base de Datos. Comento, y era de esperarse, sobre Toad Devops Toolkit de Oracle como una de las herramientas que te ayuden a lograr ello, la cual se integra muy bien con otras herramientas de integración y despliegue continuo como son Jenkins, Bamboo o Team Foundation Server. Cabe aclarar, que este es un concepto nuevo, y seguramente sera una tendencia que no tardara en volverse una practica, habrá que ver como las empresas responden y se adaptan a ello, ya que hablamos que la data sea la misma en todos los entornos. Otras herramientas Open Source que también realizan lo mismo son Liquidbase y Flyway, para los que quieren tener variedad al elegir que herramienta usar.

Bien siguiendo con las charlas, otra que me pareció interesante fue la de Alexis Lopez (Java Champion - Java Tools & Frameworks)  y Jose Diaz (Java Champion)  con el tema Java continua siendo libre, y es que nos aclararon sobre la tendencia en cuanto a  los próximos lanzamientos de JAVA SE y si el soporte dejara de ser gratuito. Bueno nos afirmaron que las actualizaciones gratuitas finalizaron con JAVA SE 8 (ya estaba enterado de aquello) y que posterior a ello implicaría un costo su uso en un entorno de producción si se opta por adquirir cada actualización (release) que se vaya lanzando.

Otro punto a considerar es la periodicidad (semestral) con la que dichas versiones se vienen lanzando, comparado con versiones anteriores (en la que esperabas como mínimo 3 años). Incluso hace unos días a la fecha de escribir el presente post, fue lanzado la versión JAVA SE 13, la que pueden descargar de la pagina oficial de ORACLE.

La recomendación que nos hicieron es que trabajemos con la versión que tenga LTS (Long Term Support), que considera un soporte extendido, a pesar que nuevas versiones puedan ser lanzadas. Pero tranquilo también hay alternativas como OpenJDK con licencia GPL, el cual ofrece soporte y actualizaciones gratuitas de diferentes empresas como Amazon, Azul, RedHat entre otras, sin embargo con algunas limitaciones, pero digamos que ya es algo.

Con respecto a Java Web Start y JavaFX, no es desconocido que Oracle les quitara el soporte, aunado a eso que se ha anunciado que serán removidos de la distribución lanzada con JAVA SE 11, por lo que es conveniente considerar otras alternativas a ello, para  la primera podríamos considerar IceTea-Web o karakun como opciones interesantes, y para la segunda OpenJFX llegaría al rescate.


La penúltima charla a la cual asistí fue la de Jose Diaz (Java Champion) con el tema  Microprofile y Quarkus para Arquitecturas de Microservicios, en cual menciono las ventajas al considerar otros frameworks alternativos a Spring Boot o TomEE para la implementacion de microservicios, el framework que menciono fue Quarkus.

Quarkus ofrece significativas ventajas en cuanto al consumo de memoria RAM y startUpTime.

 Incluso realizo una demo, donde integrado con GraalVM (Maquina virtual poliglota) lo hace una opción interesante a considerar. Les dejo el link del código fuente de la demo, para que lo puedan clonar https://github.com/joedayz/quarkus-persons

Finalmente, como ultima charla, Jose Diaz (Java Champion) con el tema Despliegue de aplicaciones en kubernetes con Herramienta Devops en Multinube, nos comento en la charla que actualmente en Farmacias Peruanas, lugar donde labora, utilizan Azure Devops, dicha herramienta esta compuesta por Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans y Azure Artifacts, de los cuales actualmente utilizan los 3 primeros, pero ya estaban pensando adquirir todas las funcionalidades.

Nos explico mediante un ejemplo, en una campaña realizada para Inkafarma, que tan practico es actualizar la pagina web de Inkafarma, y que en minutos se vea el cambio en producción, mostrando el entorno visual, e intuitivo con las que cuenta las herramientas de Azure Devops. Otra cosa que me pareció interesante es que no te amarra con aplicaciones desplegadas solo en Windows Azure, sino que puedes integrarlo con otros proveedores en la nube como GCD (Google Cloud Plattform)  o IBM Cloud, incluso con entornos OnPremise.

Actualmente, podemos usar Azure Devops gratuitamente con el plan básico, que incluye hasta 5 usuarios como máximo y las 3 primeras herramientas, mas de eso requiere un costo de suscripción. Seria interesante,  poder utilizar este tipo de herramienta que como se expuso es versátil y trabaja bajo un enfoque ágil.


Conclusiones

En general, me pareció un evento bien organizado, donde el contenido de cada charla, estuvo alineado a los avances y demanda actual del mercado, en lo que respecto a tecnología de productos Java y Oracle. Los ponentes también de altísimo nivel, dando la talla a este evento que se realiza cada año, en varias ciudades del mundo.

Finalmente, como reflexión, nos queda siempre estar al tanto sobre las novedades del mundo tecnológico y analizar sobre alternativas a cada producto y/o herramienta que usemos, que quizás no sean tan conocidas, pero que definitivamente tendrán un impacto significativo en cuanto al consumo de recursos que usemos y al valor agregado que le demos al negocio.



Fotos del evento:

Referencias Bibliográficas

https://jaxenter.com/microprofile-3-0-arrives-with-some-breaking-api-changes-159267.html
https://blog.payara.fish/announcing-the-release-of-eclipse-microprofile-3.0
https://blog.payara.fish/consuming-microprofile-metrics-with-prometheus
https://www.ttandem.com/blog/la-economia-de-las-apis-ya-esta-aqui/
https://docs.payara.fish/documentation/microprofile/
https://www.oracle.com/technetwork/es/articles/cloudcomp/oracle-application-container-cloud-3402775-esa.html#intro
https://docs.oracle.com/en/cloud/paas/developer-cloud/csdcs/use-projects.html#GUID-3E4D9A4B-315C-4761-B518-108D04C50CC5
https://apex.oracle.com/es/learn/tutorials/
https://www.javiergarzas.com/2014/10/y-que-pasa-con-la-integracion-continua-de-bases-de-datos.html
https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html
https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244
https://www.aspera.com/en/blog/oracle-will-charge-for-java-starting-in-2019/
https://karakun.com/openwebstart/
https://shadow-soft.com/openjdk-support/
https://www.baeldung.com/quarkus-io
https://medium.com/@Gladiator444/quarkus-io-moving-from-200mb-to-1mb-10-seconds-to-100-milliseconds-bc0889a3050
https://brunobat.com/2019/03/12/tomee-vs-spring-boot-vs-quarkus/

JCONF 2019

En esta oportunidad les iré comentando sobre algunas anotaciones que realice durante el JCONF 2019 Perú http://jconfperu.org/ , en sus anteriores ediciones conocida también como JAVA DAY PERU.

La primera presentación Arquitectura de APIS por Jose Luis Bugarin (Arquitecto Empresarial), muy buena exposición, hablo sobre el framework GRPC (google remote procedure call) y sobre su ventajas para el consumo de microservicos APIs GRPC usando tecnología Google, a traves de una demo, que ya comentaremos mas adelante.

Otro concepto que menciono y el cual vengo escuchando casi seguido es sobre los serverless, que viene del concepto serverless computing o en español, computación sin servidor, que básicamente es modelo de ejecución de computación en la nube, en la cual el proveedor de la nube ejecuta el servidor y administra dinamicamente los recursos de la maquina. Un ejemplo de proveedor en la nube puede ser AWS, Azure, Google Cloud, etc.

Olvide mencionar que Jose Luis trabaja en una entidad financiera, y durante de la charla, nos comento que estemos alerta con el concepto de open banking, la cual las fintech ya están sacando provecho. Sobre este termino,  según lo que leí, es un tipo de estrategia dentro de la tan ya mencionada transformación digital, que permite "la liberación" de información que permita personalizar los servicios financieros a medida del usuario. Otro concepto que leí fue el siguiente "Open Banking es la posibilidad de crear nuevos negocios y ecosistemas digitales de APIs ofrecidas por los bancos". Un ejemplo que menciono fue TUNKI de interbank. Bueno en general hay mucho sobre esta estrategia seguro por explotar, pero ahondar ahora sobre aquello, nos tomaría el resto de la publicación, así que lo dejare como tarea de investigación.

Menciono sobre Swagger como editor y documentador de API REST, el cual es open-source y RAML otro editor parecido, con ciertas peculariedades, se lo dejo al lector, realizar una comparación entre ambos editores, incluso como aporte personal podría adicionar a blueprint también en la lista. También hizo hincapié sobre la importancia el testeo de la seguridad de las APIs.

Otro punto que hizo mencion fue sobre las herramientas de API Managment, algunas open source como WSO2 o KONG, esta ultima incluso usa IA (inteligencia artificial) para el analisis de las APIs. Y otras de pago como API Azure Management, no ahondare mucho sobre el funcionamiento de cada una de ellas, pero veo necesario mencionar que seria buena practica tener en tu empresa una herramienta como las que he mencionado que se encargue de administrar, publicar, y monitorerar tus APIs, dejo en las referencias algunos links que detallan el uso y caracteristicas de algunas de ellas.

Otro tema que menciono fue la metodologia de generacion de APIs, un tema que dejo en el tintero de cara a lo que se viene, del cual me viene a la mente tener un marco de referencia del cual me baso para desarrollar mis APIs que podria involucrar las fases de definicion, diseño, implementacion, validacion y documentacion por poner un ejemplo, incluso me atreveria a decir, que estariamos hablando ya de una gobernanza de APIs. Tambien menciona la regla 3 30 3 para APIS, de la cual no encontre informacion en español, igual les dejo las referencias en ingles que encontre, pero que resumiria como tienes 3 segundos para identificar si la API es relevante para tu negocio, unos 30 segundos para probarla, y unos 3 minutos para volverla a ejecutar.

Otro desafio en relacion a la APIs, a parte de su gestion y gobernanza, que ya comentamos anteriormente, tiene que ver con su seguridad, y dependiendo en la arquitectura en la cual esten diseñadas, por ejemplo una aquitectura basada en microservicios, tendra un tratamieno complejo distinto, de las medidadas de seguridad que ya conocemos (Autenticacion, politicas de seguridad, entre otras), y es ahi sobre surge Service Mesh (malla de servicios), como este es un topico complejo de digerir cuya solucion surge cuando tenemos muchos y diferentes microservicios implementados con  diferentes tecnologias y desplegados de diferentes maneras, en la cual se ve realmente necesario abordar su comunicacion asi como asegurar los canales de comunicacion entre ellos, una implementacion open source de este servicio es Istio, dejo algunos link de referencia que ahonda sobre este tipo de infraestructura de software.

Luego nos recomendo leer el libro Enterprise Integracion Patterns de Gregor Hohpe y Bobby Woolf, donde explica los 4 principios de integracion entre otras buenas practicas, dejo el enlace en la referencia.

Finalmente, realizo una demo sobre sobre el framework GRPC (Google Remote Procedure Call) de Google para construir microservicios basado en API grpc sobre protocolo HTTP/2, cuya sintaxis usada en Proto3, asi como nos hico incapie de las ventajas en performance que ofrece este framework, como meno consumo de CPU y ancho de banda, mejor latencia, entre otros, comparados con el consumo de API Rest que conocemos hoy en dia.

Otra ponencia fue la del Josh Long de la empresa PIVOTAL, con el tema de la Revolucion Reactiva, autor de diferentes libros como CLOUD NATIVE JAVA o REACTIVE SPRING, para los fans de java y sobre todo de SPRING, fue importante ver como un guru mostraba las tendencias y los beneficios que trae consigo la programacion reactiva  de la mano con Spring 5, a traves de Spring Web Flux. Les dejo una enlace de su playlist en youtube donde encontraran tutoriales y Spring tips bit.ly/spring-tips-playlist, la integracion con kotlin, spring cloud, entre otros.

Les dejo el link de su presentacion publicada en Speaker Deck : https://speakerdeck.com/joshlong/the-reactive-revolution

 Otra exposicion que me parecio interesante, fue la de Construyendo aplicaciones modernas con Micronaut, de Edgar Rios (Senior Backend Developer), el cual lo presente como una alternativa interesante  sobre a diferencia de Spring Boot, la inyeccion la realiza en tiempo de compilacion entre otras ventajas alguna recogidas de otros frameworks como Grails o Spring Boot, en cuanto a rendimiento y tiempo de arranque. Les dejo un link en la referencia como comparativa, y como tarea al lector evaluar cual les convendria al momento que tengan que desarrollar microservicios e integrarlo con cualquier IaaS del mercado.

Otra exposicion bastante interesante fue Sebastian Daschner (Java Champion de Alemania), con el tema Java EE, Jakarta EE, Microprofile, Or Maybe All Of Them?, comento las ventajas de usar MicroProfile y el soporte que tiene para implementar microservicios, la integracion con Open Liberty, Payara entre otros, asi como con las herramientas de monitoreo como Prometheus y Grafana. Les dejo alguna documentacion que encontre en los links de la referencia.

Tambien recomendo el libro Arquitecting Modern Java EE Applications el cual es autor.

Por ultimo, y no menos importante fue la presentacion de Mark Heckler de la empresa PIVOTAL al igual de Josh Long, que nos hablo sore Spring Cloud Stream, y sobre las novedades acerca de las plataformas de mensajeria en una arquitectura distribuida y su integracion con Apache kafka y RabbitMQ.

Tambien realizo una demo al igual Josh Long, usando Spring Cloud Stream, Spring WebFlux. Dejo su presentacion publicada en Speaker Deck https://speakerdeck.com/ por aqui, https://speakerdeck.com/mkheck/bebiendo-del-stream-como-usar-las-plataformas-de-mensajeria-para-escalamiento-y-rendimiento donde coloca el codigo del ejemplo subido en GitHub.


 Conclusiones:

Fui un evento muy particular, con mucha informacion que digerir, sin embargo, el networking, la calidad del contenido de exposicion de cada ponenete, lo valio. Creo que en la actualidad estamos inundados de mucha tecnologia, herramientas, framework, esta en ti decidir cual vale la pena usar en tu empresa, en base al valor agregado y las circunstancias de la misma.
Otro punto a considerar para los que usan la plataforma JAVA en su organizaciones es que la mayoria de las demos fueron construidas con JAVA 11, y tambien hubo una exposicion sobre la tendencia de las versiones del JDK de Java de Heather Vancura Presidenta y Directora de JCP (Java Community Process), ya comentare un poco mas a detalle sobre ese tema en un posterior post.

Fotos del Evento:

Referencias:

https://unpocodejava.com/2019/01/23/que-es-grpc/
https://serverless-stack.com/chapters/es/what-is-serverless.html
https://bbvaopen4u.com/es/actualidad/cinco-ejemplos-de-como-el-open-banking-mejora-la-experiencia-de-cliente
https://blog.vsoftconsulting.com/blog/is-raml-or-swagger-better-for-building-apis
https://enmilocalfunciona.io/wso2-api-manager/
https://www.bbva.com/es/tyk-kong-analizamos-estos-dos-api-gateways/
https://medium.com/codenares/kong-el-king-de-los-microservicios-f54d9d307e69
https://apiaddicts.org/slides/slide/mada-metodologia-agil-de-desarrollo-de-apis-13/pdf_content
https://www.paradigmadigital.com/dev/por-que-hace-falta-gobernar-las-apis/
https://www.pullrequest.com/blog/focus-on-improving-your-api-docs/
https://nordicapis.com/5-reasons-why-developers-are-not-using-your-api/
https://www.aplyca.com/es/blog/service-mesh
https://www.paradigmadigital.com/dev/consolida-arquitectura-microservicios-service-mesh/
https://medium.com/zenta-group/service-mesh-potenciando-la-estrategia-de-api-management-439cac88ad15
https://camel.apache.org/manual/latest/enterprise-integration-patterns.html
https://unpocodejava.com/2019/01/23/que-es-grpc/
https://medium.com/@walkingtreetech/spring-boot-vs-micronaut-the-battle-unleashed-2682354a88e9
https://walkingtree.tech/micronaut-potential-poster-boy-microservices/
https://microprofile.io/
http://www.clubdetecnologia.net/blog/2017/que-es-eclipse-microprofile/
https://www.jcp.org/en/home/index