Estuve en una conferencia de arquitectura sin servidor esta semana. Es genial estar rodeado de personas brillantes en el ámbito sin servidor.
Mientras estaba en una sesión, comencé a pensar en el contenido que he estado viendo últimamente sobre el tema de sin servidor. La mayoría de lo que veo son tutoriales para principiantes o publicaciones altamente avanzadas e informativas que requieren años de práctica para alcanzar. Ambos extremos ofrecen un gran contenido, pero dejan a muchos constructores en ese punto intermedio sin suerte.
Si seguimos los tutoriales para principiantes una y otra vez, es posible que las capacidades de nuestra aplicación no crezcan al ritmo de las demandas del producto. Si seguimos las guías avanzadas demasiado pronto, terminamos con un código excesivamente complejo y optimizado prematuramente que está preparado para situaciones que quizás nunca encontremos. Entonces, ¿qué hacemos el resto de nosotros que no somos principiantes ni ingenieros sin servidor superavanzados?
Construye lo que importa.
¿Cómo sabes qué es lo que importa? En pocas palabras, lo que importa es resolver tu problema comercial. Específicamente, ¿qué puedes hacer para resolver el problema comercial de una manera diferente a tus competidores? ¿Cuál es tu valor agregado que hace que tu solución sea mejor?
Determinar cómo vas a resolver de forma única un problema empresarial es infinitamente más importante que tener un código optimizado y autorreparable sin servidor desde el principio. El software nunca se acaba. Entrar en la mentalidad de que lo mejorarás gradualmente con el tiempo es lo mejor que puedes hacer una vez que empieces a aventurarte más allá de los cursos de introducción a Lambda.
Hace poco vi un tweet que hablaba de una presentación de Boris Tane en la que hablaba de la entrega incremental.
El mensaje de su presentación era ofrecer un vehículo cada vez mejor. En lugar de empezar a construir un coche y pasarse meses y meses construyéndolo de la nada, hay que empezar poco a poco. Entrega un monopatín. Luego mejora el diseño y entrega una patineta. Luego una bicicleta. Luego una motocicleta. Al final, tus conocimientos se desarrollarán lo suficiente como para acabar entregando un coche de mayor calidad en menos tiempo que si empezaras con ese objetivo.
Empezar por algo pequeño y ofrecer algo que resuelva el problema de la empresa de forma rápida y sencilla (por ejemplo, un monopatín) permite llegar antes a los consumidores. Además, se adquiere experiencia en el área del problema. Esta experiencia ayuda a tomar decisiones de diseño significativas que, en última instancia, repercutirán no sólo en la experiencia del cliente, sino también en la arquitectura del producto final.
Empezar poco a poco
He escrito varias veces sobre la importancia de la iteración. Incluso he escrito sobre mi propio viaje con la iteración en serverless. La mejor manera que he encontrado para tener éxito es hacerlo, hacerlo bien, hacerlo mejor.
Resuelve primero el problema comercial. Sé ingenioso. Hazlo rápido y sin complicaciones. Aprende lo que se necesita técnicamente para resolver
Luego, prepáralo para su uso a largo plazo en producción. Incorpórale herramientas de observabilidad. Soluciona los defectos. Optimiza el código.
Después de eso, añade más. Agrega funciones a tu aplicación ya sólida. Mejórala con las lecciones que has aprendido. Mejora las herramientas para facilitar su soporte.
Pongamos un ejemplo.
En noviembre de 2022, Luc van Donkersgoed estuvo en el podcast Real World Serverless hablando sobre cómo PostNL implementó su arquitectura basada en eventos. Describió cómo construyeron un intermediario de eventos personalizado para validar y dirigir los eventos hacia los consumidores. Crearon su propio registro de esquemas que gestionaba los cambios, la versión de los eventos y rastreaba cuántos consumidores se suscribían a ciertas versiones de los eventos.
Fue (y sigue siendo) increíblemente impresionante. Cuando lo escuché, quise construir exactamente lo mismo de inmediato para el producto en el que estaba trabajando. Teníamos un caso de uso similar y ya era un patrón probado, entonces ¿por qué no?
En primer lugar, mi equipo no tenía el mismo nivel de experiencia que el de Luc. Los conocimientos necesarios para llegar a ese punto tardaron años en desarrollarse. Así que empecé poco a poco.
Podíamos utilizar EventBridge de forma nativa para comenzar. No había necesidad de construir nuestro propio intermediario de eventos. Recién estábamos comenzando a admitir una arquitectura basada en eventos, necesitábamos aumentar nuestros niveles de comodidad y dejar que el servicio administrado por AWS se encargara durante un tiempo. La simple publicación y suscripción a eventos de EventBridge fue nuestro monopatín.
Una vez que nos sentimos cómodos con los flujos de trabajo asíncronos, pudimos empezar a validar esquemas. Construí un paquete interno npm que validó las cargas útiles de eventos contra esquemas json codificados. Empezamos a utilizar este paquete antes de publicar mensajes en el bus de eventos. A continuación, los consumidores de eventos comenzaron a utilizar el paquete para validar la carga útil también.
A partir de ahí, el plan era crear un portal para permitir a los desarrolladores registrar sus eventos en lugar de codificarlos en un paquete npm. Luego construiríamos el agente de eventos para orquestar todas las partes móviles.
No importaba en qué punto del viaje nos encontráramos, una cosa siempre fue consistente: el problema comercial siempre se resolvía. Simplemente seguíamos haciéndolo mejor.
Resumen
Se necesita tiempo para desarrollar experiencia. Cuando se construye en una tecnología tan amplia y cambiante como serverless, a veces es mejor descubrir los mejores patrones por ti mismo. No tomes todas las charlas, publicaciones de blog y podcasts increíbles que ves como instrucciones de “hazlo de esta manera ahora mismo”. Tómalos como referencias para guiarte en tu propio camino.
Es fácil dejarse llevar por la emoción del éxito de los líderes de la comunidad. Pero ellos no llegaron allí de la noche a la mañana. Aprendieron por su cuenta, siguiendo las guías y referencias de otros, al igual que el resto de nosotros.
Así que aprovecha todo el contenido increíble que puedas. Aprende de ello. Úsalo para ayudarte a tomar decisiones. Pero no te comprometas más de lo que puedas manejar, podrías encontrarte deseando haber lanzado ese monopatín después de todo.
¡Feliz programación!
