martes, 25 de julio de 2017

DevOps en Startups

Recientemente participé en la transición de una startup, que está yendo más allá de las pruebas de conceptos y de los pilotos hacia un negocio autosustentable. Comparto lo que aprendimos.
¿DevOps es distinto en Startups?
El movimiento DevOps busca derribar las paredes entre las áreas de las empresas, para lograr que las soluciones se construyan incluyendo el aporte de todos los involucrados. Esto permite disminuir el tiempo que toma pasar de la idea al producto, lo que a su vez permite aprender y ajustar el rumbo con mayor velocidad.
En las Startups,  por el contexto riesgoso y desconocido, es necesario aprender y ajustar el rumbo con velocidad. ¡Bingo! El objetivo de DevOps y las necesidades de las Startups coinciden.
Por otro lado, el foco inicial de las Startups es descubrir el producto y el mercado. Hay relativamente pocos usuarios y el mayor riesgo es hacer el producto incorrecto. Al inicio se pone menos atención a la operación.
Como reflejo de esto, en muchas Startups no hay un área de Operaciones separada. Y si la hay, hubo mucho menos tiempo de levantar muros entre esta y el área de Desarrollo.
Entonces, ¿cuál es el desafío?

El desafío de DevOps en Startups

Inicialmente validamos con pocos usarios que el producto genera valor. Luego la prioridad pasa a ser hacerlo disponible para muchas personas. Buscamos incorporar los atributos necesarios para seguir creciendo (por ejemplo: escabilidad, confiabilidad, que sea operable y tenga soporte) afectando poco en la velocidad del equipo. Queremos mantener al equipo en el centro de la acción, incorpore los conocimientos y responsabilidad de Operaciones.
Algunos de los análisis sobre DevOps (como The Phoenix Project o el Continuous Delivery Maturity Model) asumen que la organización ya tiene un área de Operaciones funcionado.
El desafío es encontrar un camino de evolución para que el equipo incorpore responsabilidades y actividades de Operaciones sin desatender la mejora del producto.
Estos son algunos de los riesgos en ese camino:
  • Que el esfuerzo de incorporar conocimientos y prácticas de operaciones le quite foco al equipo y no se pueda seguir con el ritmo de innovación.
  • Que el equipo vea las actividades de operaciones o soporte como aburridas. Esto bajaría la motivación del equipo.
  • Que no se incorporen buenas prácticas de operaciones. Esto bajaría la calidad de la experiencia del usuario.
¿Cómo lo hacemos?

¿Qué es Operación en IT?

Cuando hablamos de que el equipo incorpore responsabilidades y actividades de Operaciones, ¿lo tenemos que hacer como un todo o podemos dividirlo?
Intentaremos una posible división en roles, que nos permita incorporar el conocimiento incrementalmente al equipo o buscar soluciones alternativas:
  • Soporte de Operaración: Mantener la aplicación funcionando, lo que incluye entre otras cosas estar al tanto de los consumos de recursos para realizar escalamiento (según políticas preestablecidas), responder a incidentes como por ejemplo servicios caídos, realizar provisioning de ambientes, instalar versiones, realizar copias de resguardo.
  • Ingeniería de Operaciones: Anticiparse a los problemas relacionados con el software de base y infraestructura (red, almacenamiento, procesamiento), estando al tanto de las actualizaciones de seguridad, versiones de software que dejan de estar soportadas, manejo de licencias.
  • Arquitectura: Colaborar con el equipo en el diseño de la aplicación, incluyendo consideraciones sobre la forma de despliegue, radar de tecnologías, buenas prácticas para lograr los atributos de calidad buscados (como seguridad, escalabilidad, confiabilidad, etc.).
Conviene recordar que sobre esto hay mucho análisis, reflejado en ITIL. Hay mucho para reutilizar si mantenemos la visión de simplicidad que tiene la agilidad. Por ejemplo, en muchas Startups, es necesario implementar manejo de Incidentes y Resolución de problemas. Estos procesos pueden implementarse siguiendo las buenas prácticas de ITIL.

Alternativas

Pensamos algunas alternativas de solución, cada una con sus pros y contras:
  • Manejarlo con el equipo actual.
  • Incorporar personas en el equipo (permanente o temporal) con experiencia en Operaciones.
  • Aumentar temporalmente la capacidad del equipo.
  • Tercerizar el servicio
  • Delegar al usuario
  • Automatizar las actividades de operaciones.
Para decidir deberíamos analizar el caso concreto, y experimentar distintas alternativas para resolver los problemas en orden de prioridad.

Caso Ejemplo

El caso es una startup que tuvo éxito con un piloto y va a empezar a vender el servicio, lo que implica mantener un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) en cuanto a disponibilidad, resguardo de datos y escalabilidad ante la incorporación de nuevos clientes.
Con personas sumadas en forma temporal al equipo, se evaluó y decidió modificar la arquitectura de despliegue, para pasar de máquinas virtuales a servicios en la nube (Amazon Web Services). El estado del ejemplo al momento de este reporte, solo una foto dentro de la evolución:
  • Parte de la Soporte de Operación se mantuvo dentro del equipo, con herramientas de monitoreo provistas por la plataforma. Se mantuvo y extendió la automatización de la instalación.
  • Parte de los actividades de Soporte de Operación e Ingeniería de Operaciones fueron delegadas a la plataforma: Actualización de versiones y seguridad, parte de los mecanismos de alta disponibilidad y escalamiento.
  • Arquitectura: Se detectó una oportunidad de mejora, que se realizaría conjuntamente entre miembros del equipo y las personas sumadas al equipo en forma temporal.

Conclusión

En las empresas establecidas, el conocimiento sobre cómo Operar existe, pero está en áreas separadas. El desafío en la transición hacia DevOps es derribar las barreras internas entre áreas y compartir ese conocimiento. Además, las formas de desarrollo deben adaptarse, como por ejemplo automatizar builds y pruebas.
En las Startups la dificultad está en incorporar la Operación de manera incremental, profesional y sostenible a la empresa y al equipo (en una Startup son prácticamente lo mismo).