La semana del 4 de abril tuve la oportunidad de asistir como asistente/oyente al evento de Software Architecture Conference en la ciudad de Nueva York.
El objetivo de este evento, es mostrar los principales tópicos en el contexto de arquitectura de software.
El primer día asistía a dos talleres prácticos, uno impartido por
Thoughtworks, en el cual nos enseñaron como ir manejando una aplicación que iba desde el modelo monolítico de multicapa a un modelo de microservicios, llevando esto a conceptos de Continuous Delivery (CD), contenedores (Docker). Lo interesante de este taller fue que mostró que los microservicios no solo es el hecho de hacer un componente de software, sino que también se requiere la automatización de la infraestructura sobre la cual se ejecuta, así como tener un pipeline para llevar el ensamblado y despliegue en dicha infraestructura. Esto es muy importante, por que el desarrollo de software bajo este enfoque no sólo se limita a tener el bloque funcional, sino a también codificar la automatización de la infraestructura. En el ejemplo, usamos
Go para manejar el tema de Continous Delivery.
Es interesante como el modelo de múltiples capas es calificado como monolítico. Y la verdad ya lo es. Hace 20 años, dada nuestra capacidad de recursos de cómputo, el modelo era útil e inclusive el dividir en varios componentes una aplicación era demandante en arquitectura física. Hoy ya no, con esquemas de virtualización y de nube una aplicación puede ser procesada en decenas o centenas de servidores.
El otro punto es que el concepto de servidor se está volviendo cada vez menos necesario. El servidor se está volviendo una unidad de procesamiento más, y lo mas importante, no hay que preocuparse por el número de instancias de procesamiento. Es lo que se conoce como serverless computing.
El segundo taller fue después del almuerzo y orientado a Java, y hablar de como integrar Spring con JEE o viceversa, en algunos lados he visto como unas guerras santas entre fanáticos de ambas visiones. Sabiamente los expositores nos explicaron los detalles de como lograr la convivencia de
ambos enfoques. A los que están contaminados aún con los cursos monolíticos, ortodoxos y arcaicos que dan en ORACLE de arquitectura JEE, les invito se vacunen y lean este
libro.
En paralelo hubo otros talleres interesantes, uno de ellos se saturó, pero afortunadamente aquí están las
láminas.
Al otro día, se arrancaron con una serie de platicas (keynotes) bastante interesantes. Una de ellas, sobre
Conversational Commerce, muy interesante.
Después, tome la conferencia sobre como en l
as carreteras de Noruega se está instrumentando para obtener diversas métricas.
La siguiente
plática que tome, fue sobre Internet of Things y los diversos esquemas de integración y comunicación. MQTT , Watson, API management y usando BlueMix
Pasando entonces a la siguiente plática, sobre
Domain Driven Data , que por cierto, me llama la atención como varios arquitectos aún no identifican el concepto de Domain Driven Design y que es un tema que se está mencionando de manera continua para el diseño de microservicios. Aparecieron varios modelos de base de datos NoSQL y el concepto de Command Query Responsability Segregation (CQRS) . Dado el concepto de microservicios, lo que expusieron en esta platica es que ya la arquitectura depende de un solo repositorio de base de datos relacional, sino que puede existir diversos repositorios y de acuerdo al dominio del problema. Lo que si quiero hacer notar es que esto está llevando a un modelo de sistema distribuido donde el
teorema CAP debe ser tomado en cuenta .
Mucha información en menos de un día, verdad? Y aún faltaban dos pláticas mas.
La plática sobre las mejores prácticas para implementar el modelo de arquitectura serverless (aún no me atrevo a dar la traducción en español) que dio el CEO de
iron.io . Lo interesante es que iron.io es una compañía que está apostando bastante al concepto de serverless computing , la idea de microcontainers, procesamiento masivo. Sala llena por cierto.
La última del día fue sobre como usar AWS Lambda para implantar una a
plicación serverless .
Por cierto, si quieren tener una herramienta que les ayude a definir API Webs, revisen
Swagger
Llegó el miércoles, el último día, mas keynotes.
El arquitecto de
HomeDepot platicó la estrategia para ir hacia microservicios. Insisto, no es ahora poner en el mapa de trabajo de TI de las empresas el uso de microservicios, pero si están llegando a un nivel de madurez donde la complejidad de las aplicaciones están generando pesadillas tanto en la ejecución como en tiempo de desarrollo, hay que pensar en un cambio.
Les pongo estas ligas de Martin Fowler, donde habla del concepto de
microservicios y ojo, las
implicaciones. Por favor, comunidad de TI, no caigamos en buzzwords que luego generan los falso profetas (de manera típica, los archienemigos de los arquitectos, ventas).
Uno de ellos fue dado por el director de arquitectura de SalesForce y lo que destaco de esta plática es como la arquitectura se ve beneficiada por incluir conceptos como meta datos, la habilidad de combinar piezas de software y el tratar grandes volúmenes de datos.
Y el último keynote, muy interesante,
la continua repetición del dolor en el desarrollo de software. Uno de los puntos, es que muchas organizaciones se la pasan gastando recursos en hacer mejoras que derivan en un impacto mínimo o nulo. Pongo
la liga del libro de
Janelle Klein. Yo diría, basta de
IT Crowd way of life. Una
manera responsable de pensar en TI
De ahí, ya la primera plática sobre
Unikernels y donde empiezo a oír de Russell Pavlicek, quien busca adelgazar a las Virtual Machines para poder acelerar el tiempo de arranque de instancias, particionar los recursos de acuerdo a los microservicios y no desperdiciar recursos en cargar librerías y procesos innecesarios. Un enfoque es el que está haciendo la comunidad de Xen, con
Mirage OS. Me gusto mucho el enfoque de Russell, práctico.
Otra plática, habla sobre como pensar la arquitectura como un
sistema biológico.
Y lo que esperaba, ver a Adrian Cockfrot en vivo, quien ayudo a Netflix a poder soportar grandes escalas. Su plática fue sobre microservicios.
Continuado entonces una plática sobre la
arquitectura de Netflix sobre nube (AWS)
Y la última del evento, de nuevo fui a escuchar a Rusell Pavlicek, donde su
plática fue sobre el tema de hipervisores.
En resumen, un evento interesante, lleno de diferentes enfoques de arquitectura de software, pero bastante orientado a lo práctico, no a lo abstracto. Los expositores son conocidos en su ámbito, muchos de ellos autores de libros de O´Reilly.
No deja de ser apasionante el arte de la arquitectura de software; dado que todo este cuerpo de conocimiento, toca en lo personal como arquitecto, tratar de sintetizar, tomar decisiones para lograr cumplir con las expectativas técnicas de una solución.
El arquitecto de software no deja de seguir tecleando código o instalando/configurando. Es muy importante que conozca lo que implica sus soluciones.
Ojalá las generaciones actuales que luego se coronan de manera inmediata como arquitectos, entiendan que es una gran responsabilidad portar este titulo.
