Un año después de que el condado de Multnomah, Oregon desplegara una cartera de aplicaciones de gestión en las instalaciones, los dos miembros del personal de TI dedicados a ella renunciaron. Otros miembros del personal lucharon por mantener el entorno de servidor especializado. Al no tener otra opción para garantizar el soporte para la herramienta de misión crítica, el condado saltó a la nube.
"Todos nuestros proyectos de TI son monitoreados a través de Planview", señala Staci Cenis, gerente de proyecto del condado Multnomah, que incluye a Portland. "Lo usamos para contar el tiempo y la planificación. El seguimiento del mantenimiento programado y no programado nos muestra cuando el personal estará libre de tomar otro proyecto".
Inicialmente, el condado tenía dos administradores Planview dedicados, explica Cenis. Pero a lo largo de un período de alrededor de tres meses en el 2009, ambos dejaron sus puestos de trabajo en el condado, "lo que nos dejó sin cobertura", añade Cenis. "No teníamos a nadie en el personal que fuera entrenado en la configuración de nuestro Planview o entendiera las piezas técnicas de los trabajos que se ejecutan dentro de la herramienta para actualizar las tablas", entre otras cosas.
Cenis no había considerado la nube antes de esa cuestión, pero accedió a abandonar el software on-promise en favor del software como servicio (SaaS) de Planview, después de evaluar los costos. La capacitación de otro personal de TI en servidores, almacenamiento, administración de backup, recuperación y mejoras por sí solo habría agravado los gastos de software en las instalaciones, señala Cenis.
Hoy en día, con la infraestructura y la administración de aplicaciones descargadas en la nube, TI puede manejar la mayoría de las preocupaciones de recuperación de desastres, configuración y pruebas durante una llamada mensual programada. "Me hubiera gustado haber ido con la nube desde el principio, ya que ha aliviado una carga importante", comenta Cenis, especialmente en el área de las actualizaciones de software.
Cada actualización manejada por el proveedor de la aplicación en lugar de su equipo, se estima, añade numerosas horas a su fuente de recursos. "Lo que nos hubiera llevado días, si no semanas para solucionar, por lo general toma un día o dos", añade. Al mismo tiempo, los usuarios pueden acceder a la versión más reciente del software entre uno o dos meses de su lanzamiento.
La opción del condado de Multnomah por la nube es uno de los cinco modelos cada vez más comunes en la actualidad, de acuerdo con Anne Thomas Manes, vicepresidente y analista distinguida de Gartner.
* Reemplazo, como lo hizo el condado de Multnomah por arrancar la infraestructura e ir con SaaS;
* Re-host (volver a alojar), donde TI todavía administra el software, pero se encuentra alojado en la infraestructura externa, como Amazon, Rackspace HP o servidores de nube pública o privada;
* Refactorizar, donde se hacen algunos simples cambios a la aplicación para tomar ventaja de la plataforma como un servicio;
* Revisar, donde los marcos de código o de datos tienen que ser adaptados para PaaS;
* Reconstruir, donde los desarrolladores y TI desechan código de la aplicación y vuelven a empezar con PaaS.
"No muchas empresas reconstruyen o hacen muchas modificaciones importantes para migrar una aplicación a la nube. Por el contrario, hacen re-host, refactorizan o remplazan", señala Manes.
En primer lugar, las empresas ven a la nube como una vía de escape para un exceso de trabajo, fuera del espacio del centro de datos. "Si se enfrenta a la perspectiva de la construcción de un nuevo centro de datos, que cuesta miles de millones de dólares, sin duda tomar muchas aplicaciones menos críticas y llevarlas a la nube, ahorra mucho dinero", agrega Manes.
¿Problemas en el paraíso?
Sin embargo, desde la primera observación del frenesí de nubes, Manes reconoce que las empresas han tomado sus bultos. "Muchos líderes empresariales estaban tan ansiosos por llegar a la nube que no involucraron a TI para instituir una apropiada redundancia o legalidad para ejecutar los acuerdos adecuados", señala. Tales descuidos los han dejado vulnerables tecnológicamente y económicamente con los cortes y otras cuestiones.
Sin embargo, desde la primera observación del frenesí de nubes, Manes reconoce que las empresas han tomado sus bultos. "Muchos líderes empresariales estaban tan ansiosos por llegar a la nube que no involucraron a TI para instituir una apropiada redundancia o legalidad para ejecutar los acuerdos adecuados", señala. Tales descuidos los han dejado vulnerables tecnológicamente y económicamente con los cortes y otras cuestiones.
Las empresas que movieron aplicaciones y datos a la nube pública en las primeras fases del proyecto, no siempre planificaron los cortes con medidas tradicionales tales como balanceo de carga. "Incluso si un corte de luz se centraliza en una parte del país, puede tener un efecto en cascada, y si dura más de un día puede causar un problema real para los negocios", añade.
Dave Woods, gerente senior del servicio de proceso de inteligencia de negocios SNL Financial, está de acuerdo. SNL Financial agrega y analiza los datos a disposición del público de todo el mundo para sus clientes. A pesar de tener un importante centro de datos internos, la aplicación de gestión de flujo de trabajo de cosecha propia estaba poniendo a prueba sus límites.
"Nuestro centro de datos estaba lleno" con bases de datos y aplicaciones internas y de cara al cliente, agrega Woods. La compañía no hizo un análisis completo para averiguar si se trataba de espacio en el servidor o refrigeración, u otro tipo de limitaciones -o todo lo anterior- pero en algún momento se hizo evidente que se estaban quedando sin capacidad, y el software de nube se volvió atractivo.
A pesar de que consideró brevemente la reconstrucción de la aplicación y la construcción fuera del centro de datos, los costos, los plazos y la inestabilidad del código lo disuadieron. "La aplicación heredada carecía del diseño y la flexibilidad que necesitábamos para mejorar nuestros procesos", señala Woods. El objetivo, en otras palabras, no era solo para volver a alojar la solicitud, sino para hacer algunas mejoras en el proceso de flujo de trabajo.
Para lograr esto, SNL Financial adoptó el sistema de administración de negocio basado en nube de Appian. Aunque el costo de la licencia anual era similar al software en las instalaciones que la empresa había estado utilizando, el factor decisivo fue evitar los 70 mil dólares en costos de hardware que habrían sido necesarios para actualizar la aplicación en ese momento. (SNL desde entonces ha construido un "espectacular centro de datos nuevo en el sitio", agrega Woods, de modo que ya no es un problema).
SNL Financial está ampliando sus procesos de flujo de trabajo a más de 500 bancos en Asia, con Woods dándole crédito a la nube por permitir este tipo de escalabilidad y alcance geográfico. "No hubiéramos sido capaces de mejorar nuestro flujo de trabajo legado de esta manera. Había un ciclo de vida de desarrollo de TI mucho más largo con el que lidiar. Además, la aplicación no habría tenido tanta capacidad", dice.
"Estas plataformas son de misión crítica para nosotros, no es un proyecto paralelo," explica Woods. "Afectan nuestro motor de negocios y tienen que permitirnos cumplir la línea de tiempo de nuestras garantías para nuestros clientes", agrega.
Los procesos a los que se refiere Woods son los que implican reunir, auditar y revisar los datos y noticias para industrias específicas -en otras palabras, la información que SNL les vende a los clientes.
Eso no quiere decir que no ha habido algunos baches en el camino hacia la nube. Woods señala que, si bien TI fue traído al comienzo de la toma de decisiones, su equipo de mejora del proceso perdió la marca en asegurarse de que TI estaba plenamente informado. "Hemos encontrado que no importaba que pensemos que estamos haciendo un buen trabajo con TI y el networking, la sobre comunicación está a la orden del día", añade.
La construcción de la confianza en la nube
El Jet Propulsion Laboratory (JPL) tiene una actitud similar con respecto a la nube. Con más de 100 terabytes que se propagan a través de 10 diferentes servicios, la confianza del JPL en la nube se ha construido a lo largo del tiempo.
El Jet Propulsion Laboratory (JPL) tiene una actitud similar con respecto a la nube. Con más de 100 terabytes que se propagan a través de 10 diferentes servicios, la confianza del JPL en la nube se ha construido a lo largo del tiempo.
Su primera incursión fue en el 2009, cuando la realidad demostró que la misión de 30 días del Mars Exploration Rover (MER) iba a durar mucho más tiempo de lo que se pensaba, y exigieron más recursos que los que el centro de datos interno podía manejar. (MER sigue enviando datos a la Tierra).
"Todos nuestros sistemas de TI estaban llenos. También necesitábamos construir nuevos sistemas de TI internos o trasladarlos a la nube", señala Tom Soderstrom, CTO.
Soderstrom y su equipo de técnicos y desarrolladores entonces utilizaron la naciente plataforma Azure de Microsoft para hospedar su programa de difusión "Be a Martian". Inmediatamente, el JPL vio los beneficios de la elasticidad de la nube, la cual es capaz de girar recursos en consonancia con la demanda del usuario.
De hecho, la extensión ha demostrado ser un fértil patio de recreo para los esfuerzos de la nube del JPL, tales como el uso de Google Apps como base de su programa para escolares "Postcard from Mars". Soderstrom la llama la plataforma ideal, ya que permite una sociedad fuera del firewall con los desarrolladores de la Universidad de California, San Diego.
Los desarrolladores externos son autorizados simplemente en Google -por el grupo de TI del JPL- para trabajar en el proyecto. "Si utilizábamos el centro de datos interno, habríamos tenido que emitir cuentas y máquinas, conseguir que sean visados por JPL, y hacer que vayan a las escuelas para instalar y gestionar el código de la aplicación", agrega Soderstrom. "El enfoque de la nube es más barato y más eficaz".
El JPL también aprovecha Amazon Web Services para varios proyectos, entre ellos su concurso para EclipseCon, la reunión anual de la comunidad de código abierto Eclipse. "Todas las pruebas, codificación y puntuación que se hacen en la nube de Amazon para que nuestros centros de datos internos no tengan que soportar el golpe", añade.
La nube también beneficia los proyectos internos, incluyendo el procesamiento de datos de las misiones a Marte. Para apilar las 180 mil imágenes enviadas desde Marte, el centro de datos tendría que girar en torno a los servidores del reloj durante 15 días o más. JPL tendría que pagar el costo de esa infraestructura y pasar el tiempo en el desaprovisionamiento de las especificaciones según el tipo de enchufe necesario.
Por el contrario, el mismo proceso llevó menos de cinco horas con la nube de Amazon y cuesta alrededor de 200 dólares, según Soderstrom.
Como el uso de la nube crece en popularidad e importancia, JPL continúa reforzando recuperación de desastres/continuidad del negocio basado en la nube, utilizando múltiples zonas geográficas de un único proveedor de servicios, así como múltiples proveedores. "Siempre tenemos la conmutación por error para todo, y lo considero como un seguro", añade. Para el aterrizaje de verano en Marte, JPL instituyó un sistema de doble conmutación por error. "Todos los proveedores de nube van a tener cortes, simplemente hay que determinar la cantidad de conmutación por error que está obligado a soportar", indica.
Para obtener los datos en Amazon, JPL ha encendido balanceadores de carga para mover datos entre zonas, según sea necesario. "Anteriormente, habrían sido necesarios ingenieros de red para hacer ese tipo de planificación, y ahora los desarrolladores de aplicaciones pueden hacer estas medidas por sí mismos con solo apuntar y hacer clic", añade Soderstrom.
Auto aprovisionamiento
Ha habido contratiempos en el camino, como tratar de hacer coincidir la aplicación con el servicio de nube. "Los servicios de la nube solían ser una relación entre un proveedor y un líder de negocios con una tarjeta de crédito", señala Soderstrom. Ahora, "nos aseguramos de que TI esté involucrado en todos los niveles", explica.
Ha habido contratiempos en el camino, como tratar de hacer coincidir la aplicación con el servicio de nube. "Los servicios de la nube solían ser una relación entre un proveedor y un líder de negocios con una tarjeta de crédito", señala Soderstrom. Ahora, "nos aseguramos de que TI esté involucrado en todos los niveles", explica.
Para lograr esto, JPL ha estandarizado todo su aprovisionamiento de nube, con la creación de un formulario en línea que llenan los líderes de negocios y desarrolladores de proyectos. Sobre la base de plantillas pre establecidas creadas por TI, sus respuestas en inglés plano para preguntas como "¿Va a necesitar escalabilidad?" y "¿Dónde está tu cliente y dónde están sus datos?" guían hacia qué servicio en la nube y nivel de recursos se van a necesitar.
La decisión de pasarse al auto aprovisionamiento ha significado el reciclaje de administradores de sistemas que estén bien informados acerca de los casos de uso en la nube. Además, los miembros del personal de seguridad de TI sirven como consultores para el entorno de la nube, endureciendo y verificando el sistema operativo y la construcción de la aplicación.
Aunque esto suena como una evolución complicada, señala Soderstrom, los problemas técnicos planteados por la nube han sido fáciles en comparación con los legales. El equipo legal está en el centro de todas las negociaciones para asegurarse que las ofertas de licencia sean apropiadas, y que la contratación y acuerdos de cumplimiento sean respetados.
En sus contratos de nube, JPL incluye cláusulas sobre la posesión de los datos. En caso de cierre del servicio, disputa u otra terminación de mutuo acuerdo, el proveedor debe enviar todos los datos de nuevo a los discos, mientras la NASA paga la cuenta del trabajo.
Sin embargo, en general, agrega Soderstrom, se alegra de haber dado el salto. "La nube está cambiando el panorama de la computación, y estoy muy cómodo con ella. Nada ha sido tan revolucionario desde la PC o la Internet".