2do Encuentro de Arquitectura de Software en Mar del Plata

Agenda del evento

La idea va tomando cuerpo, se llevó a cabo un segundo encuentro y hubo una gran audiencia. No era para menos, recibimos a Alejandro Bianchi presidente de Liveware, un experto en Arquitectura de Software; a Ignacio Peña VP of Technology de Globant y a Diego García. CTO. de Lateral View.

Este encuentro tuvo como epicentro Arquitectura y Agile, dos conceptos muy fuertes en el desarrollo de software, que según con quién hablemos, pueden verse como complementos o contrapuntos. Con las charlas que presenciamos, vimos como con todo lo que sucede en el marco de la arquitectura, ese balance entre ambos conceptos es un trade-off más con el que tenemos que lidiar y no existen recetas; existe conocimiento y experiencia.

Abrió el evento Alejandro, su presentación tuvo una parte introductoria de lo que encierra la disciplina de arquitectura, algunos de los conceptos que siempre repetimos como los atributos de calidad, epicentro del diseño de arquitectura. Pero rápidamente ubico a la arquitectura en el contexto actual, cuales son las tecnologías que hoy marcan tendencia y determinan el rumbo de las industrias nuevas y tradicionales. Internet de las cosas, cloud computing, microservicios, blockchain y sobre todo el concepto de digitalización de la empresa.

Por qué decimos “sobre todo”, porque la digitalización hoy domina el mercado, digitalización desde un concepto mucho más amplio que cambiar papel por bytes, es digitalización como una nueva propuesta de valor.

Este marco nos lleva a que IT debe desarrollar nuevas habilidades, nuevas capacidades y Alejandro propone como tesis que el rol del arquitecto en este marco es esencial y crítico.

Es así que la presentación pasa por como se mixan las habilidades blandas del arquitecto con técnicas, la negociación constante entre la metodología y las demandas actuales de vertiginosidad, ciclos de vida más cortos y agilismo. Es importante incorporar el concepto de que tanto para Agiles como para la Arquitectura prima por sobre todas las cosas la satisfacción del cliente. Es allí donde Alejandro nos muestra coincidencias muy claras entre principios del agilismo y la arquitectura.

La presentacion abarcó también un tema importante como la deuda técnica y su gestión. Tema que hemos hablado en el evento anterior y recalcamos siempre. La deuda técnica existe, debe ser gestionada pero por sobre todas las cosas buscamos que sea algo conciente, debe ser una decisión tomada no una situación encontrada.

Nos quedamos con gustito de más, se mencionó devops y es un tema que nos interesa, esto es simplemente una captura de lo que fue la charla; acá les dejo la presentación de Alejandro para que puedan desmenuzarla aún más.

Presentacion Alejandro Bianchi

Luego de la presentación de Alejandro presentamos el grupo ArqConfMDQ, fundamentalemente con el objetivo de poner una visión en común:

En ArqConfMDQ queremos fomentar el conocimiento aplicado al diseño de software. Buscamos compartir experiencias que ayuden al desarrollo profesional de las personas y empresas de la región. El marco de esta comunidad comprende fomentar estándares, buenas prácticas, novedades, debatir sobre ideas, herramientas y técnicas. También esperamos que sea un lugar para juntarnos a estudiar nuevas metodologías, colaborar y probar tecnologías existentes y socializar soluciones. Un lugar en el que el conocimiento se comparta para lograr un mundo mejor para todos.

con un interés:

Lograr un desarrollo del conocimiento en Arquitectura de Software que contribuya el posicionamiento de Mar del Plata como polo tecnológico en el plano internacional.

Este meetup propone diferentes dinámicas en sus actividades:

  • Encuentros
  • Charlas
  • Talleres

Luego vimos la presentación de Nacho Peña de Globant que con su estilo tan particular e histriónico compartió su experiencia en aplicaciones con un ciclo de vida hiper explosivo Nos conto como las decisiones de arquitectura se sopesan con los tiempos requeridos por la dinámica de este tipo de aplicaciones. Vimos como obviamente se puede acelerar ese ciclo a partir de tomar riesgos, y como la disponibilidad de recursos y la posibilidad de realizar inversiones de riesgo compensan la vuelta atrás de esas decisiones. Fue una charla muy entretenida y nos dió una mirada super práctica.

Finalmente presentó su caso Diego García de Lateral View.  “Funciones Lambda: el futuro ya llegó”. Más que interesante, mientras recorría su proyecto fue compartiendo las decisiones de arquitectura que tomó en cada etapa, aciertos errores pero lo más interesante fue lo innovador de su solución y el debate que despertó en conceptos que hoy se discuten mucho, serveless, microservicios, SAAS vs PAAS… otro debate que da para un meetup dedicado.

Les dejo la presentación de Diego y el link a su proyecto

Funciones Lambda- el futuro ya llegó

https://github.com/diego1686/newsletter-subscription

Espero que sea de utilidad y no duden en comentar o compartir sus opiniones y/o dudas.

Un placer haber participado en la organización del evento, nos vemos en el próximo meetup de ArqConfMDQ!!!

2018-06-18 at 2.09.38 PM (1).jpeg   07706a59-7dfb-4d68-8423-56a3e6eb6355.jpg535ba8ff-3285-4f3a-a5a1-2e1763f432ea.jpg    da038ea4-caee-4e2e-bb40-5bd39508514d.jpg2018-06-18 at 2.09.37 PM.jpeg   20180614_180034.jpg

Advertisements

CQRS perspective over Infinispan and A-MQ in English

Every time we take a new step to the application integration we find stoppers, but there are many technologies that help us support a vision.

When we are considering an integration strategy there are two main paradigms to support it, SOA (Service oriented architecture) and EDA (Event Driven Architecture). Both paradigms represent a new situation that the areas of Development and Operations area must face. Sharing data is no longer a concurrence problem over the data base, neither it is an over night replication; now every process must be considered as a potencial user that needs data managed by other application.

The problem

The definition of service owners reveals a problem:

Administration of the integration Impact .

 

Does a transactional system have the responsibility over the system´s needs?

Is the consumer responsible for the use of the services he does?

Can it be managed by the governance?

An alternative

Although the governance sets rules to keep a healthy coexistence, there is an alternative that allows us to separate those responsibilities. This could be done by applying a pattern called CQRS (command query responsibility segregation). I heard about this concept in a Greg Young´s article “CQRS, Task Based UIs, Event Sourcing agh!”

Now, it could be simple to ask developers to design, build and support a second data structure… (you could try, although I´m not so sure they will do it) but what´s up with legacy applications or applications not developed by us? Modifying them could be very costly or even impossible but we can take advantage of integration interfaces or extension points which let us use…. events!!!

How can we apply this pattern?

We can extend the pattern and delegate the responsibility on another application. This application should be focused on the roll of a service provider and its design should prioritize scalability.

How can we have scalability in the data layer? Betting on innovation using state of the art technologies like In-memory databases for whom scalability is the fortress. In my experience, I used Infinispan. It has a small learning curve and it is easy to scale on it. The latest versions are very robust and finally, bugs on the transaction manager and locks problems in the synchronization between instances have been fixed.

This allows us to have a database with full horizontal scalability with a data design oriented for service provision.

This database receives the information thought events (event sourcing pattern), these design advantages are:

  • Decoupling
  • Data federation from several sources

the disadvantages are:

  • Temporal inconsistence from the source. We need to manage the latency between the original transaction and the time needed to process the event.

Infinispan

Infispan is an in-memory database under the key/value scheme. Its power resides in the access speed to the data, not only because of the in-memory feature, but also for the direct access by keyword. Access through keyword represents a clear advantage if the keyword search criteria for the services we expose match those ones used when storing the data.
Infinispan can be used both as an API or as a server.
In this type of architecture, we see ISPN as a concurrence point of many applications where one writes and the rest read, for there are a series of services exposing the information.
As API, we experience:
  • Less network usage.
  • More flexibility for the processing of combined data.
  • The processing capacity and storing scalate together.
  • There is no need to overload the ESB for data processing or generate an extra layer.
As a server, we observe:
  • Integration via hotrod.
  • Flexibility in the infrastructure scalability.
  • Problems, restarting or deployment of new versions of the service layers are events completely independent from the persistence layer in Infinispan.

Integration of Application Legacy

    • If we are dealing with a commercial application, we need to analyze its integration points. In case of not having any, we still have the possibility (although not pleasant) of implementing a mechanism of pooling the database (trigger, pooling daemon, etc) to retrieve any changes.
        • How can we guarantee the notification of the totality of the changes?
          1. We can make the persistence of the event part of the transaction.
          2. We can define some mechanisms for manual/automatic retrieval for the persistence of the event.

 

From the moment we have the data loading mechanism, the memory cluster configuration is completely independent:

  • It can be replicated or distributed, depending on the amount of data to store, the robustness we want to confer to it and the data reloading time.
  • The cache store guarantees the option of recovery from a node/complete cluster crash or error. It is often inefficient or even impossible to do this from the origin    

Event bus

In spite of looking for alternatives, I always come to the same conclusion, the best way of implementing the Event Bus is by way of a JMS platform. The Bus must act as a buffer of events allowing a certain level of elasticity for the consumers and achieving both that the event persistence has a minimum impact on the performance and resource cost for the producer.

In order to guarantee the arrival of the events into the Bus, we have two strategies:

  1. The publisher application incorporates the publication as part of the transaction, meaning that
    • If the Event Bus is not available, the transaction can’t take place.
    • The transaction takes longer.
  2. The publisher application has a mechanism of persistence and retrieval, requiring of:
    • Bigger infrastructure
    • More responsibilities for the application.

Whichever strategy we choose, the objective is to guarantee a higher platform availability and scalability. This will allow to support an increase in the traffic through the platform and its availability time.

JMS strategy:

Public-Subscriber scheme: It allows scalability in the message traffic and permits incorporation of consumers without restarting or configuring the infrastructure.

Durable Subscribers: this feature guarentees the preservation of the messages until the consumer retrieves them.

Persistent Messages: this feature preserves the messages even in the event of platform restart.

The strategy consists in putting together a pub-sub scheme where a publisher sends a message on a specific topic and n subscribers retrieve it. This allows scalability with the subscribers at the time of registry when they subscribe to the topic with the same client ID. Being persistent allows us to guarantee the arrival of the message.

Conclusion

The Application integration through services and/or events generates impact problems among applications. Responsibility segregation is a good strategy at the time of facing the trouble of administrating the integration impact. In-memory databases and JMS are technologies that provide the adequate functionalities for the implementation of a CQRS architecture, allow to decouple consumers from producers and have structures designed for query.

My personal experience with Infinispan for information retrieval services and JBoss A-MQ for messaging administration has been more than satisfactory, allowing me to have a 7×24 infraestructure with message delivery guaranty and to provide high traffic services, reducing response times by 10-100 times.

Great PaaS comparison between OpenShift and Google AppEngine

Trabajando con un equipo de profesionales me encontré con la necesidad de entender las diferencias y beneficios de dos de las tecnologías de Paas más importantes del mercado.

Dentro de ese trabajo se analizó uno de los aspectos  por los cuales las soluciones de cloud son las adecuadas, la elasticidad, es decir la capacidad de ajustar la infraestructura a la demanda que tiene el software en un determinado momento.

Este trabajo se basó en plantear una serie de escenarios y comprobar el comportamiento del servicio. Se obtuvieron métricas de comportamiento y capacidad por instancia y tiempos de disponibilidad de nueva infraestructura por ende el tradeoff e estas tecnologías reside (dejando de lado temas de compatibilidad de frameworks y/o lenguajes y limitaciones funcionales) entre costo y tiempo de puesta a disposición.

A futuro vamos a complementar este análisis con qué tecnologíaas se adaptan mas a una y otra plataforma, el concepto de cartridge y comparación de las APIs.

Espero les guste…..   https://arquitecturacdt.wordpress.com/about/elasticidad-en-cloud-computing/

 

 

 

 

 

CQRS perspective over Infinispan and A-MQ

Cuándo avanzamos hacia la integración de sistemas son muchas las barreras con las cuales nos encontramos y son muchas las tecnologías a las cuales podemos acudir para dar sustento a la estrategia. Los paradigmas ideales sobre el cuál se basa una estrategia de integración son SOA (Service oriented architecture) y EDA (Event Driven Architecture). Ambos paradigmas presentan una situación nueva a la cuál administradores y desarrolladores deben enfrentarse. Compartir datos ya no es concurrir en una base de datos, replicaciones nocturnas o procesar ETLs. Ahora cuando desarrollo mi aplicación debo pensar también que mi universo de usuarios se expande a todos los procesos de la compañía que necesitan de la información administrada por mí.

El problema

El definir un responsable de la información presenta un problema:

La administración del impacto de la integración.

  ¿Es responsabilidad de un transaccional servir de sustento a otro para brindarle servicio? ¿Es la aplicación consumidora del servicio responsable del uso que hace? ¿Puede el gobierno controlar y limitar eso?

Una alternativa

Independientemente de que el gobierno permita establecer reglas de convivencia existe la posibilidad de deslindar esas responsabilidades.  Casualmente a través de un patrón arquitectónico que se basa en la segregación de responsabilidades CQRS. Fue a través de un artículo de Greg Young que me encontré con este concepto. Ahora, sería simple pedirle a las aplicaciones que diseñen, armen y mantengan una segunda estructura de datos (no tanto que lo hagan), y ¿qué pasa con las aplicaciones no desarrolladas por nosotros?, ¿qué pasa con las aplicaciones ya productivas?. Aquí el planteo que nos hacemos es que modificarlas tiene un impacto muy alto o es imposible hacerlo. pero puedo aprovechar puntos de integración como….. eventos.

¿Como aplicamos este patrón?

Podemos extender el patrón y delegar la responsabilidad en una aplicación externa. Esta aplicación debería estar enfocada puramente en la consulta y tener la capacidad de escalar fuertemente en ese aspecto.
¿Como escalaríamos en datos?, apostando a la innovación y aprovechar una tecnología como bases de datos en memoria para la cual la escalabilidad es una fortaleza. En mi experiencia he usado Infinispan, es fácil de usar y realmente permite la escalar muy fácilmente. Las últimas versiones corrigieron problemas de manejo transaccional y solucionaron problemas de locks en la sincronización de instancias. Esto me permite tener una base de datos con plena capacidad de escalamiento horizontal estructurada de tal manera que puedo satisfacer las necesidades de consulta. La alimentación de la estructura de consultas se realiza mediante eventos lo que comúnmente se denomina event sourcing, las ventajas claras de este diseño son:

  • Componentización de datos que permite armar estructuras a partir de múltiples orígenes
  • Desacople total

Como todo tiene sus desventajas

  • Inconsistencia temporal, es decir podemos tener lecturas durante un período de tiempo.

Infinispan

Infinispan es una base de datos en memoria bajo el esquema clave/valor. Su poder reside en la velocidad de acceso a los datos no solo por estar en memoria si no por el acceso directo por clave. El acceso por clave representa una clara ventaja si los servicios que exponemos tienen en cuenta que la clave de búsqueda corresponda con la clave de almacenamiento del dato.
Infinispan puede utilizarse como API o como servidor.
En esta arquitectura vemos ISPN como un punto de concurrencia de muchas aplicaciones donde una escribe y todas las demás leen. De modo tal que hay una serie de servicios exponiendo la información.
Como API obtenemos
  • Menor uso de la red
  • Mayor flexibilidad para hacer procesamiento de datos combinados
  • Las lógicas de procesamiento de los datos escala con los nodos.
  • No genero carga sobre el ESB o una capa extra para accede a los datos.
  Como servidor obtenemos
  • Integración vía hotrod
  • Flexibilidad en el escalamiento de la infraestructura
  • Problemas, reinicio o deploy de nuevas versiones de la capa de servicios son independientes de la capa de persistencia en Infinispan.

Integración de aplicación legacy

    • Si la aplicación es comercial debemos analizar los puntos de integración que brinde. En caso de no tenerlos existe la posibilidad (aunque desagradable) de implementar un mecanismo de pooling sobre la base de datos (trigger, pooling daemon, etc) que permita informar las novedades.
    • ¿Cómo garantizamos la llegada de la totalidad de las novedades?
      1. Podemos hacer que la persistencia en la plataforma de eventos forme parte de la transacción.
      2. Podemos definir algún mecanismo de reintento manual o automático para la persistencia del evento.

 A partir del momento en que tenemos el mecanismo de carga de los datos, la configuración del cluster de datos en memoria es totalmente independiente.

  • Puede ser replicado o distribuido, dependiendo de la cantidad de datos a almacenar, la robustez que pretendamos y los tiempos de rehidratación.
  • El cache store asegura la posibilidad de recuperación ante caída o error en algún nodo o el cluster completo. Normalmente es ineficiente o imposible hacerlo desde el origen.

Bus de eventos

Por más que evalúo alternativas siempre llego a la misma conclusión, la mejor manera de implementarlo es a través de alguna plataforma JMS. El bus debe funcionar como buffer de eventos permitiendo cierto grado de elasticidad a los consumidores y logrando que la persistencia del evento tenga un mínimo impacto en la performance y costo de recursos del productor.

Para garantizar la llegada de los eventos al bus tenemos dos estrategias:
  1. Quién publica incorpora la publicación como parte de la transacción, lo cual implica:
    • Si el bus de eventos no está disponible la transacción no puede llevarse a cabo
    • La transacción se alarga
  2. Quién publica tiene un mecanismo de persistencia y reintento, esto implica:
    • Mayor infraestructura
    • Aumento de las responsabilidades de la aplicación que publica
Cualquiera sea la alternativa cuanto más podamos garantizar la disponibilidad de la plataforma y su escalabilidad mejor.Esto permitirá soportar el aumento del volumen de mensajería y su tiempo de disponibilidad (availability).
Estrategia JMS:
Esquema public-subscriber: permite escalar en el consumo de mensajes y permite también la incorporar consumidores sin reiniciar o configurar la infraestructura.
Subscriptores durables: garantiza la conservación del mensaje hasta que el consumidor lo tome.
Mensajes persistentes: garantiza la permanencia del mensaje aunque se reinicie la plataforma.
La estrategia consiste en armar un esquema pub-sub donde un publisher envía un mensaje a un tópico y n subscriptores lo toman. Esto permite escalabilidad en los subscriptores al registrarse con el mismo client-id y al ser persistente nos permite garantizar la llegada del mensaje.

Conclusión

La integración de aplicaciones mediante servicios y/o eventos genera problemas de impacto entre aplicaciones. El problema de administrar el impacto de la integración encuentra un buen atenuante en la segregación de responsabilidades. Las bases de datos en memoria y JMS son tecnologías que brindan las funcionalidades adecuadas para la implementación de una arquitectura CQRS y permiten abstraer consumidores de productores y almacenar estructuras de consulta. Particularmente mi experiencia con Infinispan para brindar servicios de consulta y JBoss A-MQ para administrar la mensajería ha sido más que satisfactoria permitiendo tener una infraestructura 7×24 con garantía de delivery de mensajes y brindar servicios de alto volumen reduciendo los tiempos de respuesta entre 10 y 100 veces.