Meetup de verano de Arquitectura en Mar del Plata

Ayer 19 de Febrero nos encontramos en ArqConfMDQ para compartir el 3er encuentro de Arquitectura de Software, el primero de este año. Fue una gran experiencia, tuve la oportunidad de conocer gente nueva y de compartir con amigos este momento.

El evento fue muy interesante, en un ámbito distinto al de los anteriores. Este ArqConfMDQ se realizó a metros de la playa, en un bar, Bruto Mar del Plata. El lugar es espectacular, muy bien decorado y extraordinariamente bien atendido todos tuvimos oportunidad de disfrutar de alguna bebida mientras participábamos de las charlas.

 

bruto

Por qué lo hicimos ahí, primero por lo interesante del marco, disruptivo, cómodo, distinto, segundo porque nos invitó la Secretaría de Tecnología e Innovación de General Pueyrredón. Este es un proyecto de  que brinda espacio de co-working en la ciudad de Mar del Plata.

El evento comenzó con una presentación de ADD (Architecture Driven Design) aplicado, como continuación de charlas anteriores donde vimos de que se trata y las herramientas disponibles. Pueden ver Taller de Arquitectura de Software en ATICMA y 1er Encuentro de Arquitectura de Software en Mar del Plata en referencia al material.

Allí vimos como dos empresas muy importantes a nivel local Deitres Infosis a partir de una necesidad particular, donde se propusieron partir de bases sólidas abren ese esfuerzo a la comunidad para compartir la experiencia y beneficiarse con ella.

Este proyecto es una plataforma que permite gestionar miles de millones de mensajes entre componentes de IOT y aplicaciones. Pueden sumarse al proyecto, esperamos participación, ejemplos de uso, propuestas e incluso roadmap.

Acá va el material.

La segunda charla fue aún más emocionante, hablamos de una caso de arquitectura cloud native aplicado. Impresionante, un hermoso ejemplo de cómo aprovechar y potenciar desarrollos a partir de los servicios cloud. Con un breve recorrido de los conceptos básicos de cloud que rápidamente se sumergió en el mundo de CI/CD (Continuous integration / Continuous Delivery ). Lo que más me gustó?, las gráficas de los servicios de Amazon (awsgeek.com), que buenas e ilustrativas, una perlita que nos trajo Esteban.

Periodic-Table-of-Amazon-Web-Services

 

 

Acá les dejo el material.

Los esperamos en el próximo evento el 19/3. Ya lo anunciaremos en el grupo  de meetup y tweeter.

Saludos a todos!!!

Advertisements

Taller de Arquitectura de Software en ATICMA

El jueves pasado tuve la oportunidad de compartir algo de Arquitectura de Software con distintos profesionales de la industria de Software de Mar del Plata. Fue una muy grata experiencia llena de intercambio en un ámbito muy ameno.

Gracias Aticma por la oportunidad de brindar algo a la comunidad y colaborar con Mar del Plata con algo de conocimiento.

El eje del taller, fue mostrar una metodología de trabajo que nos conduzca para lograr que un diseño cumpla con atributos de calidad específicos. Vimos como esta metodología; basada en la metodología propuesta por el Software Engineering Institute pero ajustada a un contexto Pyme, nos ayuda a relevar los atributos de calidad del software. Paso siguiente, nos guía para lograr el cumplimiento de los mismos en el diseño de la arquitectura  y que al mismo tiempo esté alineado con los objetivos de negocio.

Los puntos destacados son:

Escenarios –> Necesidad de negocio –> Atributo de calidad –> Estrategias de solución

Patrón de arquitectura –> Estilo de arquitectura –> Vistas

Dejo la presentación del taller a disposición, de nuevo muchas gracias.

Presentación

No muestra el puerto de ESP8266 en el menú de Arduino IDE con MAC

Aside

Las placas ESP8266 son placas bastante económicas que nos permiten operar sobre WIFI. Adquirí una para desarrollar un proyecto personal de domótica y me encontré que no podía accederla desde mi computadora (MacBook AIR).

Al conectar por USB no sucedía nada.

 

Screen Shot 2018-07-26 at 12.01.27

Obviamente acudí a google para saber que podía ser y si alguien había encontrado la solución. Había infinidad de tracks sobre el problema y como solucionarlo, todos proponían instalar un driver y rebootear. Esto es cierto pero en parte.

Lo realmente cierto y en el caso particular de MAC (no probé en distribuciones de linux) es que hay que deshabilitar drivers ya existente para que tome los nuevos que instalamos. Esto no lo dice fehacientemente en ningún lado.

Les comparto los pasos que seguí para lograrlo.

Instalar los drivers: instale 2 drivers Virtual Com Drivers y FTDI. Esto instala los drivers FTDIUSBSerialDriver.kext y usbserial.kext en el directorio /Library/Extensions.

Deshabilita los drivers nativos: en el directorio /System/Library/Extensions encontrarán AppleUSBSerial.kextAppleUSBFTDI.kext, hay que deshabilitarlos usando el comando:

sudo kextunload -b com.apple.driver.AppleUSBFTDI

sudo kextunload -b com.apple.driver.AppleUSBSerial

Habilitar los nuevos drivers:

sudo kextload -b com.FTDI.driver.FTDIUSBSerialDriver

sudo kextload -b com.wch.usbserial

y finalmente

Screen Shot 2018-07-30 at 16.48.43

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

1er Encuentro de Arquitectura de Software en Mar del Plata

El día de ayer tuve la oportunidad de participar en el primer encuentro de Arquitectura de Software organizado por Aticma, Universidad FASTA, Universidad CAECE y Universidad Nacional de Mar del Plata.

Fue para mi un honor volver a mi alma mater y esta vez pararme del otro lado a compartir algo de conocimiento.  Agradezco a Fernando Soriano por la organización del evento y esta estupenda idea. Y a Santiago Blanco, Santiago Urrizola y Carlos Sallago por sumarse al panel de cierre y enriquecer la charla con su experiencia y conocimiento.

Comparto aquí la presentación que acompañó la charla. Esta presentación tuvo como eje central el impacto de la disciplina de arquitectura en el proceso de Ingeniería de Software. Mi intensión fue exponer como la arquitectura de software es un constante trade off que debe permitir a la empresa tomar decisiones de diseño conscientes y metódicas con el fin de lograr sus objetivos. Es menester del arquitecto nunca perder de vista estos objetivos.

La presentación recorre algunos conceptos de arquitectura, su contexto en base a la dimensión de la arquitectura objetivo y el modelo de empresa donde se lleva a cabo.

Una segunda parte abarca someramente técnicas y métodos que respaldan a la arquitectura de software como una disciplina.

Descargar “Presentación 1er encuentro de arquitectura mar del plata”

IT Architectural Meetup @ Buenos Aires

El pasado jueves tuve la suerte de participar de la primera reunión del grupo “Arquitectura IT ¿Cuales son las responsabilidades?”. Fue una gran experiencia y conocí muchas personas nuevas muy agradables.

Este grupo tiene por objetivo compartir experiencias de arquitectura desde muchos puntos de vista. Participaron tanto arquitectos de empresas de verticales bien definidas como telecomunicaciones, banca, y salud y también de empresas de servicios de IT. Esto promovió un ambiente ideal para el intercambio de ideas y perspectivas.

La reunión se llevó a cabo en las oficinas de FluxIT en Puerto Madero, instalaciones muy cómodas y modernas. Que nos permitió llevar adelante debates abiertos así como actividades en grupos reducidos.

Este primer encuentro giró en torno a los bloques de construcción de una arquitectura, Activos, Lineamientos y Servicios. La dinámica fue separarse en grupos uno por cada uno de estos elementos y luego en charla abierta exponer las ideas condensadas. Muy interesante!!!.

En particular participé del grupo de Activos, allí empezamos a esbozar ideas de que era un activo, y sobre todo si ese activo era de arquitectura.

¿Quién es dueño de un activo?

Quién dirige su ciclo de vida, quién lo opera y mantiene, quién lo implementa.

Entre los activos sin duda encontramos todos los documentos generados:

  • Lineamientos
  • Procesos
  • Assessment
  • Catálogos
  • Blue prints

pero también llegamos a la conclusión que son las piezas de software que responden a los requerimientos no funcionales de la arquitectura.

activos

Creo que apoyamos esta última idea más que nada porque encontramos una muy pintoresca fórmula matemática que la representa.

Respecto a este tema tuvimos varias discusiones, ¿debe arquitectura implementar estos activos?, pues depende, depende del grado de madurez del área de arquitectura, de la empresa e incluso de la fortaleza y respaldo con que cuente el área. Si el área es nueva quizás es algo bueno que para lograr presencia se adueñe de estos activos y hasta que se genere un gobierno maduro se apropie de la operación para lograr presencia en los procesos de desarrollo, integración e implementación. A medida que madura iremos logrando mantener esa presencia separandonos de la operatoria. Sin duda es una estrategia y cada cultura empresarial será más o menos propicia a este modelo.

“Todos queremos una arquitectura con los pies en el barro.”

Esta idea fue el eje de las discusión. Todos los que integramos el grupo éramos amantes del código y ninguno reniega de ese primer amor. Fuimos muy críticos de una arquitectura de papel e idílica, sin una fuerte dosis de realidad. Esto fue un factor de peso en las conclusiones del grupo de trabajo.

Los otros grupos tuvieron presentaciones muy buenas, sin poder precisar los ejes de sus discusiones paso a contar algunas de las ideas que compartieron:

lineamientos

Dar lineamientos sin duda es una de las grandes responsabilidades de un equipo de arquitectura. Pero aquí hicimos mucho hincapié en como dábamos esos lineamientos y que llegada lográbamos, así surgieron dos ideas muy importantes:

  • El arquitecto es un agente de venta que debe lograr un convencimiento de que aplicar estos lineamientos es conveniente. Debemos tratar de evitar la imposición.
  • Siempre debemos considerar contextos y circunstancias donde sea posible considerar excepciones a estos lineamientos.

servicios

Cuando giramos hacia los servicios no hicimos más que confirmar, resaltar y poner en negrita el rol de venta de un arquitecto y coincidimos que la comunicación es el eje fundamental del servicio que presta arquitectura. En el día a día muchos son los entregables que genera, ninguno de ellos tiene validez si luego no se capitaliza en los desarrollos y/o implementaciones de IT tanto en la misma empresa (Organización como vertical de negocio), como en una empresa a la cual le brindamos servicios.

Algunas conclusiones

Los servicios que brinda arquitectura produce activos que deben cumplir con los lineamientos que al mismo tiempo son activos que se utilizan para brindar servicios. Independientemente de este divertido juego de palabras esta sesión de filosofía tecnológica dejó algunas ideas interesantes:

  • Creemos firmemente que arquitectura debe gobernar los componentes responden a necesidades de la arquitectura misma.
  • Estos componentes son activos de arquitectura.
  • Los lineamientos deben promoverse no imponerse.
  • Siempre debemos dejar un espacio a las excepciones.
  • Todos los servicios de arquitectura se basan en la comunicación.
  • Todo servicio produce un nuevo activo.
Un interrogante que  quedó pendiente es ¿qué significa ser el dueño de un activo?. A partir de allí surge la premisa “arquitectura en la realidad y no el arquitectos filósofos”.
Lo más importante

Lo cierto es que más allá de la ciencia pase una tarde súper agradable, conocí gente de la cuál aprender y con la cual compartir. Me sentí valorado y en un ambiente de pura honestidad. Este grupo tiene futuro.

Siempre hay cosas para mejorar. De mi parte me gustaría que el grupo se volviera más variado en cuanto a las tecnologías de origen. Estaría bueno incorporar la visión de un arquitecto del mundo SAP o gente del área de infraestructura para nutrir con conceptos de arquitectura de hardware, etc.

El ambiente permitió el humor y nos permitimos jugar y divertirnos, y sobre todo rescato:

formula

De más está aclarar que todos los derechos de esta fórmula están reservados al grupo de discusión de activos del día del evento. 😛

 

 

 

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.