La película "2001: Una odisea del espacio", estrenada en 1968, comienza con una memorable escena de simios primitivos merodeando por un desierto, que desemboca en una refriega. Casi al final de la secuencia, un simio coge un hueso y lo utiliza como arma. Su facción aplaude mientras suena música clásica dramática (en concreto, Así habló Zaratustra, Op. 30, de Richard Strauss).
Y de repente, llega un gigantesco bloque negro llamado coloquialmente "monolito". Los simios se sumen en un silencio colectivo y lo contemplan atónitos... Aunque los detalles del resto de la película son irrelevantes aquí, el tema no lo es. En "2001", una IA llamada HAL, instalada para dirigir una nave espacial, se vuelve loca. Lo que hace puede ser una interpretación extrema de lo que filósofos y técnicos de todos los tiempos han especulado que es la más probable de todas las formas posibles de que nuestra especie caiga en desgracia: por las consecuencias imprevistas que conlleva el uso de una nueva tecnología.
No se trata de ser pesimistas, sino de replantearnos la adopción de nuevas tecnologías. Tanto si adoptamos nuevos motores, nuevos procesadores o nuevos patrones de diseño de software, siempre debemos ser conscientes de que nos cogerá por sorpresa precisamente porque se trata de una experiencia nueva para la humanidad, no digamos ya para usted o su equipo, su empresa o incluso su país.
Los 5 factores de la sorpresa del software
En el caso del desarrollo de software y su evolución, muchos acontecimientos de las últimas décadas han alterado el panorama de forma significativa. La propia naturaleza del desarrollo de software ofrece algunas razones para sorprenderse constantemente. Por ejemplo
1. El hardware evoluciona constantemente
Piezas como procesadores y acelerómetros que necesitan controladores especializados
Dispositivos enteros como hardware de computación en nube o smartphones
Software que requiere nuevos procesadores como TPUs y otros chips centrados en IA o nuevas GPUs para juegos de alta resolución
2. Las expectativas de los clientes cambian en función de las posibilidades actuales
5G que permite acuerdos de nivel de servicio más estrictos, lo que obliga a las empresas a actualizar la infraestructura
Integraciones a API como Facebook, Google y Microsoft single sign-on (SSO)
Servicios en competencia que "compiten por la cima" en términos de calidad de servicio
3. Los dominios y paradigmas son cada vez más complejos, lo que aumenta la dificultad del trabajo rápido
Dominios en los que se necesita un diseño de datos muy complejo
Paradigmas de software que permiten satisfacer nuevas características o eficiencias a expensas de la simplicidad técnica
4. Los requisitos de los clientes evolucionan rápidamente, a menudo más rápido de lo que puede desarrollarse el software
5. 5. Las plataformas y las bibliotecas de software se están volviendo tan omnipresentes que los clientes exigen ahora construir sobre una base de componentes de software y no quieren construir un sistema desde cero.
Estos cinco factores en particular provocan muchas incompatibilidades en el panorama del software. Por ejemplo, a veces los desarrolladores pasan años aprendiendo a utilizar herramientas que no saben construir pero que entienden conceptualmente por dentro y por fuera, sólo para que esa herramienta sea sustituida por algo mejor pero más complejo, que también puede utilizar nuevas técnicas de hardware y diseño.
Podría tratarse de una nueva biblioteca de streaming con mayores capacidades, o tal vez un cambio a graalVM para aumentar el rendimiento en tiempo de ejecución. A continuación, no sólo tienen que convencerse a sí mismos de que aprender estas herramientas y sustituir las antiguas merece la pena, sino que también tienen que convencer a sus jefes y ejecutivos de que merece la pena invertir en las ventajas técnicas y de funcionalidad. Hay que dar tiempo a los desarrolladores para que aprendan, y es posible que haya que incorporar a nuevos desarrolladores. Si una empresa vacila aunque sólo sea un año, puede perder el tren por completo y quedarse estancada en la "edad oscura", con clientes que amenazan con marcharse si no se actualizan rápidamente. Esto puede llevar a menudo a un lanzamiento precipitado.
Si esto le parece un problema que quiere evitar, ha venido al lugar adecuado. Al centrarnos en la vanguardia y mantener la mirada vigilante en el filo de la navaja, creemos saber cómo será el desarrollador del futuro próximo.
¿Qué ventajas tienen los desarrolladores del futuro sobre los actuales?
El desarrollador del futuro es, en primer lugar, un desarrollador integral. Polilingüe, es capaz de gestionar tanto la interfaz de usuario del cliente como la programación del servidor backend, incluidas las pruebas, y DevOps (despliegue y mantenimiento, incluida la respuesta a errores en directo) si es necesario.
Pero es de esperar que la mayoría de los problemas de DevOps se eviten gracias a algo que el desarrollador del futuro utiliza mucho más que los desarrolladores actuales: los servicios gestionados y las plataformas como servicio (PaaS). Mediante el uso de plataformas de despliegue y observabilidad externas, orientadas a la nube y no construidas desde cero, como GCP, AWS, o incluso otras que generan código adicionalmente, como Kalix o Golem, el desarrollador del futuro puede centrarse en el desarrollo en lugar de en el despliegue. Aunque el desarrollador del futuro todavía se ocupa de supervisar los despliegues, incluida la supervisión de los registros, la notificación y corrección de errores, y cualquier corrección necesaria que deba desplegarse, todas las cuestiones de escalado se gestionan bajo el capó mediante configuraciones no complejas basadas en código que se entregan al proveedor de servicios gestionados o al proveedor de PaaS.
El desarrollador del futuro, dada su preferencia por un estilo de codificación concreto, puede dejar de lado sus prejuicios para poder abordar cualquier preocupación, siempre que disponga de herramientas que sepa utilizar lo suficientemente bien como para hacer el trabajo. Si esto incluye el uso de IA para generar código para construir servicios rápidamente, o incluso si hay que aprender un nuevo lenguaje, que así sea.
Servicios reactivos (basados en mensajes)
El desarrollador del futuro también cree en la creación de sistemas reactivos y basados en mensajes. Para quienes no estén familiarizados con estos términos, vamos a explicarlos.
Un servicio basado en mensajes es un concepto muy distinto de las arquitecturas tradicionales que dependen de la recuperación de una base de datos en cada llamada de consulta. Las arquitecturas basadas en mensajes permiten el procesamiento de datos que pasan a ser segregados a servicios individuales, lo que permite añadir nuevas funcionalidades sin cambiar los servicios existentes y sin almacenar todo lo que sucede en una base de datos antes de que se pueda actuar sobre ellos. Al permitir que las bases de datos se integren más fácilmente en las aplicaciones en tiempo real y separar sus responsabilidades según convenga teniendo en cuenta cómo se espera que se recuperen los datos, podemos satisfacer las demandas de la multitud de usuarios que emiten consultas con los tiempos de respuesta rápidos esperados. También nos permite escalar elásticamente en función del uso de forma precisa, de modo que sólo escalamos lo que es necesario escalar cuando surge la necesidad.
Las arquitecturas basadas en mensajes tienen 4 tipos de mensajes: órdenes, consultas, eventos (cosas que ya han ocurrido) o resultados de una orden o consulta. En este caso, los comandos y las consultas siempre piensan en el futuro, mientras que los eventos siempre hacen referencia a algo que ha sucedido en el pasado. Al optimizar la base de datos de mensajes para reproducir eventos y almacenar su estado en sistemas de recuperación de datos en tiempo real, las arquitecturas basadas en mensajes permiten a los sistemas recordar estados antiguos si así lo desean, algo que podría implicar problemas de versionado en los sistemas tradicionales basados en BD.
En los sistemas basados en mensajes, se suele utilizar el "modelo Actor" para aumentar la escalabilidad y la resistencia, evitando los problemas de concurrencia. El modelo Actor es un patrón de diseño que dicta pequeñas entidades delimitadas según sus contrapartes en el mundo real. Esto, por supuesto, significa que el diseño del dominio es necesario antes del desarrollo. Aún así, creemos que esto debería ser siempre así para que no entremos en el desarrollo sin pensar en nuestro modelo de datos, requiriendo grandes cambios debido al cambio de datos. Del mismo modo, si el dominio es pequeño, podemos centrarnos más en el desarrollo en un compromiso corto. Sin embargo, si el dominio es muy complejo, es posible que sólo se pueda hacer una pequeña parte durante un compromiso corto, y que sean necesarias técnicas, plataformas o bibliotecas especializadas.
El modelo Actor ofrece muchas ventajas a nivel técnico. En primer lugar, nos permite mantener los datos en pequeñas unidades desacopladas entre sí, lo que permite una arquitectura basada en microservicios que se amplía en función de las necesidades de los objetos del dominio. Esto contrasta con un servicio monolítico tradicional que escala todo junto, replicando procesadores, infraestructura y datos incluso cuando no es necesario, simplemente porque los muchos dominios están acoplados en un único despliegue de servicio. Al desacoplar las entidades entre sí, el modelo Actor también ofrece resiliencia al permitir que una parte del sistema se caiga sin llevarse por delante otras partes. Esto también significa que los desarrolladores pueden implementar correcciones en un único servicio sin preocuparse de que otros servicios queden atrapados en el fuego cruzado y no estén disponibles durante la actualización. Además, al utilizar la memoria RAM para almacenar los datos pertenecientes a estas entidades Actor, podemos procesar y enviar datos a análisis en tiempo real sin bloquear las bases de datos que tienen que sincronizarse entre sí cuando se introducen nuevos datos.
Esto puede haber parecido mucho desentrañar. Pero ahora puedes ver que con estas ventajas de consistencia de dominio, elasticidad, resiliencia, capacidad de respuesta y recuperación de datos en tiempo real, los sistemas reactivos basados en mensajes nos permiten saltar por encima de la arquitectura convencional cuando se trata de ciertas medidas de calidad y eficiencia. Además, este modelo puede aplicarse a cualquier lenguaje o marco de trabajo, lo que permite que el desarrollador del futuro sea una infraestructura, sin prejuicios por lenguajes o marcos de trabajo, y sólo preocupado por cumplir las expectativas de tiempo, calidad, escalabilidad, resiliencia, capacidad de respuesta y otras especificaciones.
