- Se comparten casos de aplicación efectiva de los conceptos de DevOps, ingeniería de staff e ingeniería de plataforma en entornos de startup
- El ponente Chad McElligott es Senior Staff Engineer en Smartrr, una empresa que ofrece servicios de suscripción y lealtad basados en Shopify
- Se proponen metodologías de ingeniería adaptadas a la cultura y los requisitos propios de las startups
[Conceptos clave]
DevOps
- La definición de DevOps varía según la persona; para algunos es un puesto, y para otros una forma de trabajar
- El concepto de "DevOps as No Ops" hace que los ingenieros de software se encarguen por sí mismos de todas las tareas relacionadas con Ops
- DevOps consiste en entregar valor al cliente rápidamente mediante una mentalidad de colaboración, la automatización del trabajo repetitivo y manual (toil) y el uso de herramientas modernas
- Más allá de elementos técnicos como el uso de la nube, la infraestructura como código y la construcción de pipelines de CI/CD, la clave está en derribar barreras de comunicación y colaboración para lograr mejores resultados
Ingeniería de plataforma
- Platform Engineering es un enfoque técnico para reducir la carga cognitiva de los desarrolladores
- Su objetivo es aumentar al mismo tiempo la velocidad de desarrollo del producto y la estabilidad del sistema, proporcionando los componentes básicos que respaldan las actividades de los desarrolladores
- Cada vez hay más casos de grandes empresas que crean equipos de ingeniería de plataforma para aumentar la eficiencia y mejorar la experiencia del desarrollador
- Se popularizó a través del libro Team Topologies de Manuel Pais y Matthew Skelton, y es posible encontrar ejemplos de fortalecimiento de capacidades de ingeniería en diversos medios
Ingeniería de staff
- Staff Engineering no es una mentalidad ni una habilidad específica, sino un rol que asume un ingeniero de software dentro de una organización
- Es una etapa de carrera posterior a Senior Software Engineer, y también puede describirse como el liderazgo servicial de la ingeniería de software
- Los ingenieros Staff+ amplían su responsabilidad más allá del trabajo individual hacia toda la organización, y colaboran con managers o VPs aportando ejecución práctica y perspectiva
- En el libro Staff Engineer de Will Larson, el rol de Staff se explica a través de cuatro arquetipos: Architect, Right Hand, Tech Lead y Fixer
[Cultura de startup]
- Las startups financiadas con capital de riesgo suelen gastar más de lo que ingresan para crecer
- Buscan crecer rápidamente usando como "runway" el capital obtenido de la inversión, y deben alcanzar crecimiento y rentabilidad antes de que ese runway se agote
- Este entorno crea dos características culturales clave
- No hay tiempo que desperdiciar
- En una startup, perder tiempo es especialmente crítico
- El equipo de desarrollo debe enfocarse en los objetivos estratégicos de la organización y ejecutar dentro del runway disponible
- Cada integrante del equipo debe revisar con frecuencia si sus actividades están alineadas con los objetivos y reajustarlas si es necesario
- Incluso si un experimento falla, no es una pérdida si existe una estructura para aprender y se obtienen las lecciones deseadas
- Todos desempeñan varios roles
- En organizaciones pequeñas hay mucho por hacer, pero pocas personas para hacerlo
- Por ejemplo, un desarrollador frontend puede asumir también funciones de diseñador de producto, technical writer, product manager, aseguramiento de calidad o responsable de integraciones con terceros
- Si surge una nueva idea para mejorar la experiencia del cliente, la persona que la propuso podría terminar siendo responsable de crear el prototipo o hacerla realidad
- Estas características culturales determinan las capacidades necesarias en los grupos de desarrollo de producto y, en particular, en los líderes de ingeniería de software
- También dan pistas sobre cómo DevOps, Platform Engineering y Staff Engineering deben adaptarse al entorno startup
[Aplicar mis principios de ingeniería (tenets) a la cultura startup]
DevOps en startups
- En las startups es fácil cambiar procesos.
- Como hay pocas personas, no existen grandes barreras para adoptar nuevas formas de trabajar
- Ajustar los procesos con base en las herramientas produce los mejores resultados
- Mantener procesos rígidos desperdicia tiempo porque obliga a personalizar herramientas o desarrollar software adicional
- Hay que evitar al máximo las herramientas personalizadas
- Es preferible aprovechar infraestructura serverless, herramientas SaaS y bibliotecas open source
- Conviene seguir la corriente general de la tecnología y no personalizarla cuando eso no aporte una ventaja competitiva diferenciada
- Referencia: Utility vs Strategic Dichotomy de Martin Fowler
- Hay que elegir "tecnología aburrida"
- No conviene apostar fuerte por soluciones que el equipo no conoce o que tienen poca comunidad
- Cuando surjan problemas, se deben elegir tecnologías para las que sea fácil encontrar soluciones en línea
- Dan McKinley explica esta idea con más detalle en su charla de boringtechnology.club
Platform Engineering en startups
- Contenido mencionado en el podcast Engineering Unblocked de Rebecca Murphey:
- "La experiencia de desarrollador de una empresa es un producto, haya sido diseñado así o no"
- Incluso a escala startup, sigue siendo necesario contar con monitoreo, despliegues, seguimiento de errores, revisión de logs y cambio de feature flags
- La pregunta importante es: "¿Estas tareas son dolorosas?"
- Platform Engineering es un rol de medio tiempo en una startup
- Al principio puede hacer falta un entorno de pruebas integrado, pero después puede perder prioridad
- El rol de ingeniería de plataforma se desempeña solo cuando es necesario
- No hay margen para llevar adelante proyectos de plataforma de largo plazo
- En cambio, hay que implementar elementos valiosos mediante trabajos pequeños
- Es importante compartir con el equipo la visión general, pero haciendo que entiendan cómo se conectan las piezas pequeñas
- El trabajo de plataforma en startups consiste en abrir camino hacia nueva productividad y nuevos enfoques
- En la mayoría de los casos no se trata de migrar desde software existente a herramientas modernas, sino de construir desde cero elementos que antes no existían
- Más importante que decidir qué se puede hacer es decidir qué se debe hacer
- Hay que enfocarse en resolver problemas actuales de la organización o problemas del futuro cercano
- El trabajo necesario debe identificarse mediante experiencia práctica, conversaciones con ingenieros, feedback de retrospectivas y análisis de métricas del SDLC (ciclo de vida del desarrollo de software)
- A veces puede ser mejor dejar para después el trabajo de plataforma y concentrarse en otras necesidades
- La clave está en actuar con flexibilidad
Staff Engineering en startups
- El rol de Staff Engineer encaja bien en el entorno startup
- La combinación de profunda especialización técnica, deseo de tener un impacto amplio y disposición a intervenir donde haga falta para resolver problemas de negocio se adapta bien a las startups
- En organizaciones grandes existe la expresión "saber dónde está enterrada la deuda técnica"
- El Staff Engineer encuentra a quienes tienen ese conocimiento, lo organiza y deriva decisiones para avanzar
- En las startups, la deuda técnica y los problemas están expuestos con claridad
- Un Staff Engineer puede generar un gran impacto al ordenar ese caos y construir soluciones que ayuden a la organización a largo plazo
- En una startup, un Staff Engineer no puede quedarse en un solo arquetipo
- Como la organización es pequeña, debe realizar actividades diversas, incluida la ejecución directa
- Además de diseñar arquitectura, liderar proyectos y realizar trabajo táctico, también debe generar por sí mismo ideas de mejora y ejecutarlas
- La flexibilidad y el sentido de responsabilidad proactivo son cualidades esenciales para un ingeniero Staff+ en una startup
- Uno de los roles importantes de los ingenieros Staff+ es el mentoreo y patrocinio
- Son una fuente especialmente importante de apoyo y dirección para el talento junior en startups
- A través de ese apoyo, el Staff Engineer impulsa el crecimiento del equipo y fortalece las capacidades de la organización
[Aplicar la ingeniería de staff moderna en startups]
Historia 1 de 2 - "Improving DevEx by Removing a Merge Freeze"
Situación del problema
- Proceso de QA existente:
- Antes del release, se aplicaba un "merge freeze" durante 2-3 días y el equipo de QA realizaba pruebas de regresión manuales
- Los bugs detectados se corregían de inmediato y se fusionaban en la rama main
- Los desarrolladores generaban nuevos parches, pero debían posponer las solicitudes de merge hasta después del release
- Desventajas:
- Las pruebas de regresión manuales son lentas e impredecibles
- Los retrasos en los merges aumentan la frecuencia de merge conflicts
- Disminuyen la productividad y la colaboración de los desarrolladores
Solución
- Integrar el código de infraestructura en un monorepo
- Se integraron los proyectos de Terraform en el mismo repositorio que el código de la aplicación
- Se conectaron a herramientas automatizadas de linting y gestión de dependencias para facilitar que los desarrolladores trabajaran con la infraestructura
- Gestionar todos los entornos con Terraform
- No solo los entornos nuevos, sino también los entornos existentes de staging y producción se gestionaron con Terraform
- Se mantuvo la consistencia entre entornos aplicando variables distintas sobre una misma definición de infraestructura
- Simplificar el proceso de CI/CD
- La plantilla existente de GitLab Auto DevOps se había vuelto compleja por tantas personalizaciones
- Se eliminó Auto DevOps y se definió claramente un nuevo archivo
.gitlab-ci.yml
- La mayoría de los comandos se movieron a un Makefile para permitir también su ejecución manual
- Mejorar la gestión de secrets
- Para reducir el acoplamiento con GitLab, los secrets de la aplicación se movieron a Google Cloud Secrets Manager
- Se modificaron los scripts de despliegue para actualizar automáticamente el ConfigMap de Kubernetes
- Trabajos excluidos del alcance
- La aplicación se ejecuta en Kubernetes con una arquitectura monolítica
- Se mantuvo así porque cambiarla podía generar retrasos y riesgos
- No se construyó un pipeline automatizado para Terraform
- Como los cambios de infraestructura eran relativamente pocos, se mantuvo el proceso manual
- También se dejó pendiente un enfoque nativo de Kubernetes para el acceso a secrets
Resultados y logros
- Se desplegó un nuevo entorno de pruebas y el equipo de QA pudo realizar pruebas de regresión de forma independiente
- Al eliminar el merge freeze, los desarrolladores pudieron fusionar cambios libremente en la rama main
- El proceso de release se simplificó y mejoró la velocidad de todo el equipo
Principios aplicados
- Principios de Staff Engineering
- Se lideró el proyecto colaborando con distintos equipos
- Se asumió el rol de "Tech Lead" y se llevó el proyecto hasta su finalización
- Las mejoras en CI/CD e infraestructura aumentaron la comprensión y accesibilidad para el equipo
- Principios de Platform Engineering
- El proyecto de DevOps se amplió hacia un proyecto de plataforma
- Toda la infraestructura se gestionó como código para asegurar consistencia entre entornos
- El alcance del proyecto se ajustó mediante trade-offs realistas
- Principios de DevOps
- Gestionar la infraestructura como código permitió operar la infraestructura cloud de forma consistente
- Se mejoró el proceso de release y se aceleró el desarrollo con nuevas herramientas
- Se introdujo el formato de documentos RFC (Request For Comment) para hacer más inclusivo el proceso de toma de decisiones
Conclusión
- El equipo de QA pudo ejecutar pruebas automatizadas en un entorno más estable
- Los desarrolladores pudieron continuar con el desarrollo sin merge freeze y se fortaleció la colaboración
- La productividad de la organización mejoró gracias a mejores herramientas y procesos
- En el futuro, se quiere avanzar además con tareas como construir entornos de preview o automatizar las pruebas de regresión
Historia 2 de 2 - "Iterating Towards a Productive Engineering Process"
Situación del problema
- Proceso existente:
- Todo el equipo trabajaba en un solo board y compartía el avance todos los días
- Muchas personas no prestaban atención cuando no era su turno y estaban en estado de "checkout"
- La responsabilidad del desarrollo de funcionalidades estaba dispersa, y a menudo el product manager terminaba asumiendo la responsabilidad final
- También faltaba una comprensión clara de la arquitectura técnica
- Objetivo:
- Realizar distintos experimentos para construir una mejor colaboración y un mejor proceso de desarrollo de software
- Experimento 1: Equipos de funcionalidades de corta duración (Short-lived Feature Teams)
- Propósito: dar a los ingenieros sentido de responsabilidad sobre todo el ciclo de vida del desarrollo de funcionalidades
- Método:
- Se asignaba un líder para cada funcionalidad y se organizaba un equipo con backend, frontend, QA, etc.
- Resultado:
- Mejoró el sentido de responsabilidad del equipo, pero no todas las personas eran adecuadas para el rol de líder ni querían asumirlo
- Después se cambió a un "modelo de equipos fijos" para formar "Squads", y cada equipo empezó a hacer su propia planificación y retrospectivas
- Experimento 2: Epic Kickoff Documents
- Propósito: aclarar requisitos y lograr acuerdos del equipo sobre el alcance y el enfoque del proyecto
- Método:
- Resultado:
- Mejoró la comunicación del equipo y empezaron a colaborar mejor desde el inicio del proyecto
- Los integrantes del equipo consideraron que esta reunión era tiempo valioso
- Experimento 3: Revisión de código grupal (Group Code Review)
- Propósito: reducir el tiempo de code review, fomentar la discusión sobre el código y compartir conocimiento técnico entre ingenieros
- Método:
- Dos veces por semana se realizaban sesiones de code review de una hora en Slack Huddle
- Los desarrolladores compartían su pantalla para explicar el PR y los participantes daban feedback
- Resultado:
- El tiempo dedicado a code review se redujo mucho y se mantuvo el estado de Inbox 0
- Las discusiones sobre el código ayudaron a crear una cultura en la que los desarrolladores aprenden unos de otros y se respetan
- Además del code review, también se introdujeron al equipo las ventajas del pair programming
Principios aplicados
- Principios de Staff Engineering
- Se lideró la mejora de procesos en ausencia de un engineering manager
- Se introdujo una cultura de mejora continua en el equipo para reforzar la colaboración autónoma mediante un proceso ágil
- Se ayudó al equipo a romper procesos estancados y encontrar mejores formas de trabajar
- Principios de Platform Engineering
- Se consideró que los procesos también son parte de la plataforma, no solo las herramientas
- Los procesos ineficientes perjudican la productividad del equipo, por lo que mejorarlos es importante
- Los cambios de proceso que eliminan desperdicio pueden tener un impacto tan grande como mejorar herramientas
- Principios de DevOps
- Principios CALMS: colaboración (Collaboration), automatización (Automation), lean (Lean), medición (Measurement) y compartir (Sharing)
- Mediante procesos lean se elimina desperdicio y se entrega valor más rápido
- Se capacitó al equipo para mejorar continuamente mediante procesos ágiles
Conclusión
- La productividad y la colaboración mejoraron notablemente al experimentar con mejoras en el proceso del equipo
- Con mejoras de bajo costo y alta eficiencia, se mejoró la experiencia de desarrollo de todo el equipo
- Se recomienda enfáticamente revisar críticamente los propios procesos y buscar oportunidades de mejora
[Cierre]
- Al trabajar en un entorno de startup, se puede poner en juego tanto la especialización como la pasión en el proceso de resolver diversos problemas y hacer realidad soluciones
- Como existen limitaciones de tiempo, es una buena oportunidad para cultivar un enfoque pragmático, y se puede tener un gran impacto en las etapas iniciales de la empresa
- Se puede sentar la base del éxito de la empresa aplicando enfoques modernos de ingeniería de software
-
Staff Engineering y las startups
- Un Staff Engineer requiere experiencia con amplitud y profundidad
- Las startups ofrecen a los ingenieros Staff+ la oportunidad de ampliar sus conocimientos técnicos y explorar nuevas áreas
- Ejemplo: un ingeniero backend puede aprender tecnologías como React o BigQuery
-
Platform Engineering y las startups
- El Platform Engineering en startups varía según la escala
- A través de comunicación 1:1 se pueden identificar los puntos de dolor de los desarrolladores y mejorar la experiencia del desarrollador (DevEx) con proyectos pequeños
- Se debe construir un bucle de retroalimentación rápido para mejorar el proceso de desarrollo y ayudar a que los desarrolladores puedan resolver problemas por sí mismos en el futuro
- Es importante cubrir los aspectos básicos del ciclo de vida del desarrollo de software (SDLC) con herramientas y técnicas estándar de la industria
- En las startups, Platform Engineering no es una función dedicada, sino un enfoque técnico que se aplica según sea necesario
- Hay que tener presente que la experiencia del desarrollador dentro de la empresa es un producto, y dedicar tiempo a diseñarla
-
DevOps y las startups
- DevOps también cumple un papel muy importante en las startups
- La clave es entregar valor al cliente más rápido mediante cultura, procesos y herramientas, y crear un mejor entorno de trabajo
- Aumentar la eficiencia de la empresa y afianzar una cultura de colaboración a través de DevOps es un proceso muy gratificante
- En una startup, un ingeniero apasionado por DevOps puede hacer una gran contribución a través de sus habilidades y experiencia
- El entorno de una startup está lleno de nuevos desafíos y oportunidades de aprendizaje, y a través de ello los ingenieros pueden crecer aún más y lograr resultados significativos
3 comentarios
Elegía por DevOps
El ingeniero de plataforma que gana más dinero que un ingeniero de DevOps
¿Qué es un ingeniero Staff?
Parece que define muy bien los roles de ingeniería que harán falta en las startups de ahora en adelante. También da la impresión de que organiza muy bien el trabajo de ingeniería que antes se hacía sin una distinción clara. Creo que incluso uno mismo podrá entender con más detalle de qué tipo de ingeniería se encarga y en cuál le gustaría destacar en el futuro. Además, las startups también podrán contar con una ingeniería más sistematizada y contratar mejor a los ingenieros que necesitan.