eventos

Los que hayan leído mi último libro ("El Arte del Emprendedor Digital"), habrán comprobado por qué es una buena estrategia desglosar la arquitectura de un proyecto software en componentes (sobre todo si el proyecto es de tamaño medio o grande y va a evolucionar mucho). De este modo (y sin entrar en demasiado detalle), la funcionalidad del sistema está ordenada en responsabilidades independientes, fácilmente localizable y modificable.

La clave está en que cada componente (llámalo módulo si quieres), sea pequeño, se encargue de algo muy concreto y específico, y que cuando haya que afrontar una funcionalidad más amplia, se pueda distribuir ésta en varios componentes que se hablan entre ellos. ¿Cómo? Pues según la tecnología y el framework de trabajo que se haya utilizado para implementar este esquema.

Hub de Libros cuenta ahora mismo con más de ochenta componentes, mientras que un proyecto sencillo en el que he trabajado recientemente, tiene ya unos treinta (muchos de ellos reutilizados de otros proyectos).

Puede parecer que se desmadra un poco la cosa cuando hablamos de decenas de módulos independientes, aunque quizá solo los que (como yo) hayan sufrido en alguna ocasión una solución monolítica con mucha funcionalidad (cientos de miles de líneas de código), podrán comprobar las bondades de esta arquitectura. En otro proyecto diferente que he dirigido en Solid Stack, actualmente cuenta ya con más de cien (y subiendo).

Si te enfrentas a un proyecto con cientos de kloc (1 kloc = mil líneas de código) y en él no hueles nada a componente o módulos independientes, malo.

Ahora bien, en todo sistema grande existe funcionalidad de alto nivel que afecta o utiliza un conjunto de funcionalidades de bajo nivel. Tenemos siempre la tentación de implementarla directamente y por separado, y aunque esté encapsulada en su propio componente, finalmente lo que tenemos es, de nuevo, un componente grande y monolítico, más difícil de cambiar, de probar y de evolucionar, y que es justo lo que queremos evitar.

Existe otro enfoque para implementar esa funcionalidad de mayor nivel basado en eventos, esto es, cuando ocurre algo en el sistema, un componente hace algo en concreto y simple, tan solo emite el evento correspondiente por si hay otra parte del sistema que necesita saber que ese evento se ha producido. La gestión de ese evento ni siquiera se tiene que producir en la misma aplicación, sino que pueden existir auténticas infraestructuras software para gestionar eventos en aplicaciones independientes. Redis, sin ir más lejos, permite un esquema de suscripción/publicación que facilita esa comunicación entre procesos para casos en los que hay que gestionar cientos o miles de eventos por segundo.

Por poner un ejemplo, si cuando un usuario se loguea en el sistema hay que guardar cierta información en el log de actividad, o lanzar un informe para su panel de control personalizado o cualquier otra cosa, todo eso no se debe implementar en el mismo componente que se encarga de la seguridad de los usuarios, éste tan solo emite un evento de tipo "users.userloggedin" (es tan solo un nombre descriptivo), y algo en alguna parte del sistema se encargará de realizar lo que haya que hacer cuando eso ocurre.

De este modo, existen componentes base que implementan funcionalidades muy canónicas, pero también, y como parte de una arquitectura bien estructurada en responsabilidades, existen otros componentes que se encargan de implementar funcionalidad de más alto nivel que afecta a grupos de componentes. ¿Cómo? Gestionando eventos y orquestando la funcionalidad de diversos componentes del primer tipo.

Rara es la funcionalidad de alto nivel que no se pueda implementar de este modo. En ocasiones, toda esa funcionalidad de ese tipo, se incluye en lo que se denomina capa de integración, e incluso se implementa bajo el concepto de flujo de trabajo o proceso de negocio.

La gestión de esos eventos no tiene por qué ser siempre síncrona (retrasando quizá la interacción del usuario con el sistema), sino que se puede plantear hacerla en segundo plano.

Con esta estrategia, todo sigue encapsulado en componentes sencillos, mientras que aquellos que se encargan de integrar funcionalidad más compleja tan solo orquestan los primeros, manteniendo incluso una implementación sencilla: ante el evento tal, hago esto y después lo otro.

Sin duda, la gestión de eventos y su orquestación son herramientas fundamentales para implementar sistemas software grandes.

El pasado 7 y 8 de octubre estuve en uno de los mayores eventos sobre start-ups del sur de Europa, el South Summit, en un auditorio un poco peculiar (la Plaza de Toros de Las Ventas de Madrid). Vinieron muchísimos asistentes de todas partes del mundo y la agenda estaba cargada de interesantísimas charlas con actores de primer nivel, tanto de empresas muy conocidas como inversores de capital riesgo y business angels.

Si bien había empresas ya consolidadas y starts-ups de muchos tipos distintos, la mayoría tenían una base tecnológica que, de una manera u otra, incorporan el software como pieza fundamental. Todavía me preguntan si las ciencias de la computación tienen futuro o no.

Me llamó mucho la atención algunas colas que vi en algún momento de gente que iba a presentar sus proyectos a inversores con el típico pitch que no puede durar más de unos pocos minutos.

Estuvieron desde la deslumbrante Gwynne Shotwell de SpaceX hasta Adeyemi Ajao, actualmente en Workaday y que fue uno de los fundadores de Tuenti (el Facebook español), pasando por Paul Ford de Sendgrid y Jeroen Merchiers de Airbnb, que dio una interensantísima charla de título "Disrupting Markets: The Sharing Economy" junto con muchísimos otros de areas y mercados distintos. 

Gente inspiradora que sin duda tienen muchos fracasos detrás para conseguir cualquier éxito.

Quería hablar un poco de mi experiencia asistiendo al South Summit, pero también reflexionar por qué debemos incorporar en nuestra agenda el salir de la oficina de vez de en cuando para asistir a charlas o reuniones profesionales.

Siempre intento estar un poco al tanto de seminarios y eventos interesantes a los que pueda asistir. Cuesta muchísimo trabajo sacar tiempo de tu día a día y organizarte para asistir a cualquier tipo de charla o sesión. En muchas ocasiones tienes la sensación de que has perdido el tiempo y en otras vuelves encantado por la gente interesante que has conocido o por las inciativas fantásticas que has visto.

Viendo lo que hacen otros, aprendes a encaminar mejor todos tus nuevos proyectos e iniciativas, tanto si te consideras un llanero solitario o un auténtico intraemprendedor que propone mejorar continuamente el camino de la empresa en la que trabajas.

No voy a repetir eso tan manido de que vivimos en un mundo interconectado, aunque no siempre entendemos que esta interconexión no consiste en enviar invitaciones masivas a cuentas de LinkedIn a tipos que crees que te pueden aportar algo. En mi opinión, trabajes desde donde trabajes, forma parte de nuestra profesión asistir a eventos relacionados con tu día a día y puntualmente también a eventos que crees que están un poco fuera de la órbita de tu sector. Terminas conociendo a gente que tiene los mismos problemas que tú pero también a quienes ya han llegado adonde tú quieres llegar (si es que tienes algún tipo de meta profesional, claro) y que todos, absolutamente todos, han avanzando resolviendo problemas, aportando valor a sus clientes y viendo las cosas de otro modo.

¿Habrá alguna relación entre aquellos que consiguen mejores resultados y su asistencia continua a foros, seminarios, eventos, encuentros profesionales, etc.? Estoy seguro de que sí.

Por mi parte intento asistir a todos las citas que veo más o menos interesantes, a veces me resulta imposible por motivos de agenda. En muchas de las que asisto suelo salir de ellas con información interesante y valiosa que mejora la actividad de tu compañía; lo considero también un tipo de formación.

No en vano, también estuve recientemente en Madrid en un seminario impartido por Microsoft para ISVs (independent software vendors) de donde salimos encantados entre otras cosas por la charla que nos dio Omar Mahout, autor del libro Lean Pricing (que por cierto, nos regalaron) y por la apuesta total de esa compañía por Azure y la oportunidad para empresas desarrolladores de software de estar presentes en el Azure Marketplace.

Y es que no es sólo información lo que te traes, también los contactos de compañías y personas con las que puede que en algún momento puedas colaborar; también te traes deberes en forma de muchísima información que después tienes que digerir e investigar más por tu cuenta si es que piensas que le puedes sacar algún provecho.