El especialista y el porqué de su trabajo

En Pensamientos Ágiles despierto leyendo un post que en cierta manera me ha hecho recordar: Análisis de rendimiento y la necesidad de contratar especialistas.

Para mi es evidente la razón que ofrece Martín; y creo que su actuación como médico de cabecera es una buena decisión y consejo. Al margen de las recomendaciones de Martín y del post, yo me quedo con:

Actualmente estamos en el proceso de implementación…

Espero y deseo que realmente estén en esta fase y estén realizando pruebas de carga y de estress en fases de desarrollo y sea ahí donde están viendo que tienen un problema. Es cierto lo que comenta Martín, es bueno contar con un arquitecto o experto en la materia y aunque no sea durante todo el proceso de desarrollo sino más bien de forma puntual, haya alguien que se encarge de aportar ese conocimiento al desarrollo.

Es importante que durante las fases de diseño se hayan estudiado los requerimientos y desde la fase 0 se haya tenido en cuenta que la aplicación debía soportar este nivel de acceso y ese número de usuarios concurrentes. Importante es el diseño de la aplicación para tener posibilidades de escalabilidad e importante que desde el momento en el que hay algo funcional se empiecen a pensar en las pruebas de carga y en como vamos a comprobar que lo que estamos haciendo realmente soporta nuestros requerimientos iniciales.

Pero hay más. Más importante que tener a alquien con la experiencia suficiente y con el tiempo suficiente, es dejarle hacer su trabajo y hacer caso de sus recomendaciones, ¿trivial? Pues sí, pero a veces cuesta un poco.

Por ejemplo, si desde el principio nuestra arquitectura no iba orientada a cluster, que es una de las posibles soluciones que planteaba Martín, es bastante problable que si no se tuvo en cuenta en los diseños, haya que cambiar parte del desarrollo, porque nuestro sistema no soporte cluster. O si se plantea como solución tener un balanceador de carga, pues resulta que nuestro sistema de sesiones hay que volverlo a diseñar. O resulta que tenemos un máquina impresionante como parece por los datos, pero nuestro diseño de base de datos es malo, no está optimizado y realizamos peticiones un tanto innecesarias y que sobrecarga en sistema y se convierte en el cuello de botella.

Lo obvio de esto es que a nadie se le ocurriría poner un sistema como este en producción, dado que ya es evidente que tienen un problema. Y lo obvio de esto es que se van a necesitar de un tiempo determinado para que el sistema aguante tal cantidad de carga. Lo curioso es que sistemas peores y más inestables llegan a producción y se viven situaciones verdaderamente dramáticas, aunque técnicamente ya hubiese saltado la alarma y se hubiese puesto en entredicho continuar con una determinada tecnología, un determinado planteamiento de diseño e inclusive un posible pase a producción. Pero el que sea obvio no implica que se quiera ver.