Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Cómo benefició la nube privada a la infraestructura de TI de Despegar

La virtualización de la estructura permitió acelerar el proceso de subida de aplicaciones en la compañía; hoy en día manejan 150 despliegues por día.

Cuando la “burbuja de las punto-com” explotó, Despegar estuvo entre el selecto grupo de compañías que se gestaron en internet en los 90´s y hoy son gigantes de la industria. Desde su fundación en 1999, la agencia online cambió el negocio del turismo en Latinoamérica al ofrecer la posibilidad de generar paquetes de viaje a medida, la opción del pago en cuotas y la inclusión de usuarios que califican los servicios para certificar una compra de calidad. Hoy está presente en 21 países de la región, cuenta con 4,500 empleados y una base de datos de más de 150 mil hoteles alrededor del mundo.

Para dar soporte al crecimiento constante de la masa crítica de usuarios y el tráfico de información, la compañía cuenta con infraestructura de TI propia en un 90% (incluyendo el centro de datos); sin embargo, un año y medio atrás tuvo lugar un punto de quiebre que los llevó a evaluar entre usar o no una nube privada y decidirse a implementarla.

Hasta ese momento, cada servidor físico que tenían en Producción representaba también un servidor lógico; es decir, cada instancia, cada hoja de cada Blade o cada servidor físico de rack representaba una unidad lógica y ahí configuraban Windows o Linux, pero el problema residía en que dependían de un área –la de Infraestructura o de Redes– para hacer cualquier tipo de deployment en Producción.

“Teníamos 150 desarrolladores haciendo un montón de aplicaciones y cuando alguno terminaba una dependía de todo un canal bastante angosto para llegar a Producción” explica Daniel Goldstein, Gerente de Desarrollo de Despegar.com.

Al no estar virtualizada la infraestructura, tenían lugar cantidad de colisiones y era preciso tener mucho cuidado con todas las pruebas de humo, sobre todo antes de poder subir las aplicaciones. “Debíamos imitar todo el mismo ambiente de producción en un ambiente no productivo lo más parecido posible para chequear si lo que íbamos a subir podía tener problemas con lo que ya existía” aclara Goldstein. Pero además, había que depender de las cuatro o cinco personas que administraban la red para poder subirlo. “Cuando empezó el crecimiento grande de Despegar hasta hace un año y medio, quienes estaban en Infraestructura se quedaban unas tres veces por semana trabajando hasta las tres o cuatro de la mañana para hacer la maratón de la subida más las correcciones posteriores” puntualiza.

Despegar, Daniel Goldstein & Carlos Alvarez

Llegado ese punto advirtieron que requerían una nube: “El driver fue: necesitamos llegar más rápido a Producción”, destacó Carlos Álvarez, Devop Manager & Cloud Architect de Despegar.com. “Ahí nos dimos cuenta que había tareas que debíamos descentralizar y teníamos que lograr un esquema que permitiera a los equipos experimentar, minimizando el daño global”. Álvarez subraya que el objetivo que se perseguía era que el equipo de desarrolladores pudiera asumir el ownership completo de todo su proceso –desde que empieza hasta Producción– a través de mecanismos que les otorgaran esa libertad sin afectar el resto del circuito.

Cambiar el modelo de la industria

Si bien uno de los pilares de la solución fue OpenStack, rápidamente detectaron que cuenta con una desventaja: la falta de un balanceador de cargas (load balancer). “Decidimos hacer un desarrollo integrando el load balancer que tenemos, F5, con OpenStack y con los sistemas de almacenamiento con el objetivo de que toda la flexibilidad de la infraestructura como servicio (IaaS), más la flexibilidad del load balancing como servicio, más la del almacenamiento como servicio, nos permita hacer fundamentalmente despliegues en vivo” indica Álvarez. El objetivo era realizar los deploys en horario diurno sin afectar la disponibilidad del site.              

La integración de instancias permitió que los equipos tuvieran mayor flexibilidad a la hora de hacer los despliegues: “Los desarrolladores pueden hacer un despliegue previo en Producción pero en servidores virtuales nuevos, y el balanceo de cargas como servicio les permite hacer una transferencia del tráfico gradual” subraya Álvarez.

En éste sentido, el entorno de pre-producción se tornó obsoleto: “Permite integrar la versión N+1 de un componente con todo el ecosistema de versiones que va a utilizar, un estadio que no ve el usuario, sólo el desarrollador” aclara Álvarez.

En Despegar.com no manejan aplicaciones monolíticas sino  aplicaciones pequeñas de propósitos muy específicos que se comunican a través de la red. “La ventaja es que es muy fácil ver si una aplicación pequeña anda bien, no tiene bugs obvios y a la vez permite que el delta del cambio sea a la vez chico, manejable, un riesgo que se puede correr. Nos permitió pasar de tres deploys por semana a 150 por día y hemos tenido picos de 200 en horario diurno” remarca Álvarez.

El corazón del problema que resolvió Despegar es de alguna manera el modelo de la industria: “No entiendo cómo llegamos a la idea alguna vez, como industria, de que alguien tenía que hacer las cosas y otro las tenía que poner en Producción” reflexiona Álvarez mientras Goldstein afirma que para cualquier punto-com como Despegar, ese parece un escenario del  siglo pasado. “Hoy es descabellado para nosotros pensar que podíamos vivir hace un año y medio sin todas estas facilidades. Hoy cualquier desarrollador de cualquier equipo sabe que es el verdadero dueño de su aplicación y que tiene todas las herramientas para poder hacer la gestión de su aplicación después de que ya es productiva” reconoce.

Beneficios colaterales

La migración a la plataforma virtualizada trajo cantidad de beneficios; el primero y más obvio es que el desarrollador, luego de terminar la aplicación pueda subirla y probarla allí donde va a quedar funcionando. “Tienen todo el tiempo del mundo para testearla. Antes había que esperar a que alguien homologara la prueba para luego preparar el paquete para Producción” aclara Goldstein.

Pero devinieron otra serie de beneficios que no esperaban. Los desarrolladores tuvieron que “desempolvar” algunos conocimientos adquiridos en la facultad relacionados con redes y protocolos que no suelen estar presentes en su tarea cotidiana. “Desmitificaron algunos dispositivos que eran propiedad de los administradores de redes, por ejemplo el balanceo de cargas. El F5 es un equipo muy robusto y los administradores de redes lo manejaban desde su punto de vista. Los desarrolladores lo empezaron a probar integrado a las aplicaciones y hoy la configuración del F5 se hace de una manera dinámica a través de las API que trae incorporado el dispositivo” resalta Goldstein.

Otro de los beneficios que no tenían en consideración es que el esquema levantó el perfil de los desarrolladores porque se benefician del feedback en vivo, es decir, el criterio sobre si lo que se hizo está bien o mal en Producción. “En el anterior esquema el desarrollador estaba aislado de Producción, no le llegaba un montón de retroalimentación. Por otra parte el que recibía el feedback (el Sys Admin) no era el que había hecho el software y muchas veces ni siquiera tenía conocimiento de programación, por lo que esa información se perdía” indica el Devop Manager & Cloud Architect de Despegar.com.

Álvarez rescata asimismo que ahora son capaces de entender y saber cómo se conecta el almacenamiento con la red a pesar de no estar entre sus tareas. “Se amplían sus conocimientos. Son capaces de entender que lo que hacen puede complicar al sistema operativo o desperdicia memoria. Es muy difícil aprender esto si no ves lo que hiciste en el lugar donde anda” afirma.

Otra de las consecuencias del nuevo esquema es que se vieron forzados a tener unidades desplegables mucho más chicas, con lo cual todos los servidores virtuales son dedicados. Cada instancia virtual de servidor web sirve a una única aplicación, con lo cual es preciso tener mucho más cuidado en cómo se van a interconectar todas las aplicaciones. “Tener toda la información en una carga única nos permite saber quién habló con quien y cómo resultó esa conversación. De esa forma generamos cantidad de herramientas que nos permiten resolver situaciones; por ejemplo, cuando dos componentes comienzan a tener una relación más enfermiza, más lenta, con más tasa de errores o un servicio consume a otro” puntualiza Goldstein.

El balanceo de cargas es un elemento muy importante para ese circuito de información. “Brinda trazabilidad. Si alguien reporta un error con un código, es fácil para el desarrollador decir ‘el error de estas 10 aplicaciones está acá’” aclara Álvarez. En éste sentido, uno de los daños colaterales de SOA que lograron solucionar fue el funcionamiento del entorno de desarrollo: “La probabilidad de que en Desarrollo alguna aplicación no funcione –incluso por una prueba del equipo– era muy alta, entonces empezaba la multiplicación de ambientes” indica Álvarez.

La otra cara de la moneda

Pero no todo fue positivo. Concretamente, el nuevo entorno les hace consumir mucho más hardware. “Cada instancia está dedicada a una única aplicación. Estamos en Despegar.com, en todo tenés que tener alta disponibilidad. Hay aplicaciones que tienen hasta 20 nodos y la realidad es que tal vez no sea lo más eficiente para el tráfico que voy a tener en determinado momento del día, dado que lo podría resolver con tres instancias y le estoy poniendo 20” explica Goldstein, quien reconoce que constantemente están presionando para cerrar órdenes de compra para agregar más stock. “Alguien podría decir que estamos sub-usando la infraestructura que tenemos pero el beneficio al final del día es mayor” subraya.

Por otra parte, cuando empezaron con la idea de descentralizar tareas de Sys Admin evaluaron y consideraron la posibilidad de tener downtime: “Podía ocurrir pero aún así seguiríamos adelante por estar seguros que era el camino correcto” señala Álvarez. Sin embargo, no sólo no ocurrió sino que mejoró el uptime: “Los desarrolladores hicieron un excelente trabajo en asumir la responsabilidad que les tocaba. Lo que nos cuesta un poco y nos sigue costando es que el desarrollador mejore su habilidad de planear sus capacidades, pero creo que es un costo menor en la ecuación” sentencia.

Finalmente, el cambio los llevó a modificar la metodología de trabajo. “Teníamos algo parecido a lo que es Scrum, o ciclos que nosotros creíamos que eran cortos pero en realidad eran larguísimos en dónde entraban cierta cantidad de requerimientos, se terminaban, se probaban y se enviaban a Producción. Hoy tenemos algo más parecido a Kanban donde termino y entrego, lo que nos permite llegar a los 150 deploys por día” aclara Goldstein.

En definitiva, con el nuevo esquema se perdió el miedo a subir una aplicación que pueda tener algún error y se realizan más versiones de prueba porque existe feedback inmediato, lo que incrementa la velocidad de entrega. “Ahora el desafío es cómo tener cada vez más control sobre lo que pasa y cómo incrementar la disponibilidad del site” concluye Álvarez.

Investigue más sobre Cloud computing (Computación en la nube)

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