Guía Esencial

Navegue en las secciones

BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Guía esencial de desarrollo de aplicaciones corporativas
Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Despliegue de una aplicación de misión crítica: podemos hacerlo mejor

¿Los errores de algún despliegue le traen malos recuerdos? Niel Nickolaisen le da su receta para desplegar una aplicación de misión crítica.

En cierto modo, me siento mal por el equipo que puso en marcha el Mercado de Seguros de Salud de la Ley de Cuidado de Salud Asequible de Estados Unidos. No me gusta ver a ningún equipo de TI fracasando en entregar una aplicación de misión crítica. Al mismo tiempo, estoy sorprendido de que el despliegue del mercado ha sido tan problemático. Realmente podemos y debemos hacer un trabajo mucho mejor cuando lanzamos un producto, especialmente un sistema que cuesta unos 400 millones de dólares.

Con los años, hemos aprendido cómo escalar y poner a prueba los sitios web de alto volumen. A medida que el sitio web del Mercado de Seguros de Salud va y viene, desde estar fuera de línea por reparaciones hasta volver a estar en línea, pensé en compartir las lecciones que he aprendido y aplicado cuando me han encargado entregar una aplicación de misión crítica de gran volumen.

  1. Siempre planee por más que la demanda más esperanzadora. Recientemente entregué una aplicación web que soportaba una agresiva campaña de marketing. Teníamos una idea de la demanda de visitas a la web, pero no conocíamos las cifras reales. Basándonos en una fórmula que inventé hace años, hice una encuesta entre el equipo por su número más optimista de visitantes por hora y por día. Entonces tomé el mayor número y lo multipliqué por 2.7. ¿Por qué multiplicarlo por 2.7? Porque un número como ese le da a los demás la sensación de que lo he pensado detenidamente (a pesar de que simplemente inventé ese factor). Entonces diseñamos el front end y el back end de la aplicación para manejar elásticamente dichas cargas.

  2. Planee la elasticidad. Ahora teníamos un objetivo para las visitas de los sitios, pero no queríamos construir para el pico de demanda. En su lugar, construimos toda la infraestructura para un número más razonable, y planeamos altos niveles de elasticidad. Esto nos obligó a ser muy creativos con nuestros diseños y proveedores de servicios. No solo necesitábamos la elasticidad en la planificación de la demanda, también necesitábamos flexibilidad en cuanto a la duración de la campaña. Si la campaña era un éxito, continuaría para siempre. Si no funcionaba, podíamos cerrarla en solo un par de meses. Con el fin de hacer frente a nuestro incierto pico de demanda, nos comprometimos con un proveedor de servicios de nube para construir la infraestructura elástica. Ese proveedor requería un contrato por un primer año por sus servicios. Les dije que no podíamos hacer eso. En su lugar, necesitábamos un plazo de mes a mes. Me dijeron que estaba loco. Yo les dije que podría ser, pero que todavía necesitaba cierta flexibilidad. Nos arreglamos con un período de tres meses, renovable.

  3. Piloto, piloto, piloto. Al implementar una aplicación de misión crítica, tenemos que probar y validar tanto la funcionalidad de la aplicación, como las capacidades de la infraestructura. La mejor manera que he encontrado de hacer esto es hacer una serie de pilotos en expansión. Conduzco estos pilotos en dos dimensiones. En la primera dimensión, hago el piloto de la funcionalidad en fases. Aprendí hace mucho tiempo que nadie sabe lo que quiere hasta que lo ven. Y que una vez que lo ven, van a querer cambiarlo. Como resultado, yo desarrollo una parte de la funcionalidad, luego lo implemento en el grupo piloto. Ellos me dan retroalimentación sobre el diseño y las características lo más pronto posible. En la segunda dimensión, pongo a prueba la escalabilidad de la aplicación. En la práctica, estas dos dimensiones lucen así:

  • Construimos una parte de la aplicación y se la damos a un pequeño grupo de usuarios piloto.
  • Recibimos comentarios, revisamos la aplicación y se la damos a un grupo mayor de usuarios piloto.
  • En paralelo, construimos más características y las probamos con el grupo original.

A medida que agregamos características, agregamos más al grupo piloto. Al mismo tiempo, usamos herramientas de prueba para medir la carga que los grupos piloto están poniendo sobre la aplicación y la infraestructura. Extrapolamos las cargas para decidir si necesitamos cambiar el diseño de la aplicación o reforzar la infraestructura. En el camino, construimos confianza de que cuando encendamos la aplicación, se desempeñará en ambas dimensiones. En nuestro caso, las cargas del grupo piloto inicial nos ayudaron a identificar maneras en que podríamos simplificar la aplicación para reducir los cuellos de botella en la integración de datos.

Al adoptar este enfoque con nuestra campaña de marketing, el lanzamiento no tuvo eventos. No hubo hipo, no hubo obstáculos en el camino, no hubo mala prensa sobre clientes que pasaron horas infructuosas en un sitio web. Ya ve, realmente podemos hacerlo mejor.

Acerca del autor: Niel Nickolaisen es CIO de la Universidad Western Governors en Salt Lake City. Él es un orador frecuente, presentador y escritor sobre la doble función de TI al permitir la estrategia y entregar la excelencia operativa. Lo encuentra en: nnick@wgu.edu.

Este artículo se actualizó por última vez en agosto 2014

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close