Matando la innovación: "Esta app no puede caerse NUNCA!!!"

Introducción

Pensemos por un momento que nos encontramos en una empresa de software la cuál está diseñando uno de los componentes de un gran producto, llega el líder y nos dice: "Chicos, este componente que estamos creando no puede sufrir caídas, NUNCA!"

Más allá de las caras que tendrán los encargados de la infraestructura, vamos a intentar analizar el porqué este tipo de definiciones son las que llevan a que las empresas dejen de innovar.

Innovación vs estabilidad

Cuando se plantean frases como las que comentamos anteriormente, inmediatamente el equipo de infraestructura "cerrará" todo tipo de intento de los desarrolladores de agregar nuevas funcionalidades a un sistema que funciona de manera estable. Esto es algo muy simple de ver "Equipo que gana no se toca".

Ahora, dejando de lado nuestra aplicación y nuestra empresa. Nuestros usuarios, viven en un sistema con una disponibilidad del 100%? Cuando pensamos que en medio se encuentra, la red eléctrica, nuestro wifi hogareño, el proveedor de internet, etc... tenemos realmente un 100% de disponibilidad? Entonces porqué seguimos persiguiendo una utopía en nuestro objetivo de estabilidad en nuestro sistema?

Creen que un usuario puede distinguir en su uso diario entre un 100% y un 99,99% de disponibilidad de un sistema? En la mayoría de los casos yo considero que no.

Y cuanto % ponemos? 99,99999% 80% 70%?

Entonces, comprendemos que un 100% puede causar problemas. Ahora, cuanto es lo correcto? La respuesta no es simple y depende mucho de nuestro sistema (imaginemos una aplicación para una mina donde la señal celular solo funciona a un 60%).

El % correcto saldrá del análisis de la gente de negocio cuando se pregunte, con qué disponibilidad nuestros usuarios estan conformes?, a donde pueden ir nuestros clientes si no cumplimos con la disponibilidad?, qué sucede con el uso del sistema a diferentes % de disponibilidad(pensemos en disponibilidad de cada componente de un gran sistema)?

Lo cierto es que llegamos a un %, y este nos brinda otro número que es el que a quienes estamos en la parte técnica nos interesa.

Error budget = 100% - %disponibilidad

Por ejemplo para un %disponibilidad = 99.99% tenemos

Error budget = 100% - 99,9% = 0,01%

Ahora la cosa cambia, podemos equivocarnos!

En este punto ya sabemos que el 0,01% (52.60 minutos) del tiempo anual nuestra aplicación puede no estar dispobile y aún así cumplir con los requisitos de disponibilidad.

Esto abre la puerta a poder agregar funcionalidad a nuestra aplicación más rapidamente, a buscar nuevas tecnologías para resolver problemas, a crear e innovar con más confianza, etc...

No todo es alegría, hay que trabajar mucho

Disponer de 50 minutos al año donde podemos estar sin servicio no es la panacea. Tomando en cuenta que la mayoría de las caídas en los sistemas vienen luego de agregar cambios, debemos tener muchas cosas en cuenta para poder lograr este % de disponibilidad y aún así seguir innovando.

De más está decir que no podemos llevar el código desde la laptop del programador a producción directamente, debemos disponer de ambientes en donde este código sea desplegado y probado antes de llegar a un ambiente productivo. POR FAVOR! que estos ambientes sean iguales al productivo, de otra manera para qué sirven las pruebas? Lograr esta uniformidad en los ambientes nos obliga a desprendernos de crear los recursos de manera manual, por lo que hay que hacerse amigos de la infraestructura como código y de herramientas como: terraform, pulumi, cloudformation, etc...

Ya teniendo varios ambientes para realizar pruebas estamos mejor, pero no confiemos en el código de nuestros desarrolladores, son humanos...

Debemos agregar test de código en todas las etapas, análisis estático de código(lint), test unitarios, test funcionales, y todos los que creamos convenientes.

Nota al pie: NO NOS OLVIDEMOS DE LA SEGURIDAD!!!

Perfecto, ya es más dificil llevar un cambio erróneo a producción, pero si sucede? Que tiempo nos lleva volver ese cambio hacia atrás? Aquí se abren un abanico de posibilidades, pero debemos tener en cuenta el modo en el que desplegamos, que tan automático es hacer un rollback a un deploy, etc...

Conclusión

Debemos ser cuidadosos con las frases como, "no se puede caer nunca" ya que implican un nivel de presión muy grande en los equipos técnicos matanto todo tipo de innovación dentro de la empresa!

Del mismo modo los equipos técnicos no debemos tomar a la ligera este % de disponibilidad y trabajar para automatizar todos los procesos lo más que se puedan para poder innovar sabiendo que ante un error podemos volver atrás rápidamente