El SDDC es un término genérico que incluye una computación mínima definida por software, elementos de redes y almacenamiento, así como una capa de orquestación para coordinar la configuración de la infraestructura de centro de datos, a medida que es impulsada por los requerimientos de recursos y de nivel de servicio establecidos por esas aplicaciones alojadas en la parte superior.

Lo que es más, el simple punto de control que establece un SDDC a través de una serie de APIs, no debería detener las cuatro paredes de un centro de datos tradicional. Una arquitectura bien diseñada debería servir como base para una infraestructura más amplia definida por software que extiende el control sobre los recursos de TI, incluyendo aquellos disponibles en nubes privadas, nubes públicas y los recursos tradicionales recursos de centros de datos tanto en on-premises y en instalaciones de colocación.

Aunque todos tienen una sensación de urgencia debido a que piensan que están detrás de la competencia con los SDDC, no hay necesidad de entrar en pánico, anota Kerravala: 95% de las empresas aún están en la fase de aprendizaje. “Usted tendrá que hacer algunas grandes inversiones, de modo que no se apure con esto. Aún no estamos ni siquiera en la primera entrada”.

Todos los chips en SDDC

Los estándares y el software para SDDC basados en arquitectura abierta no están del todo maduros. Pero eso no detuvo a Intel de crear un SDDC basado en OpenStack, un conjunto de tecnologías creadas por la OpenStack Foundation e insertadas, en cierta medida u otra, en productos de infraestructura de centro de datos ofrecidos por Cisco, IBM, Hewlett-Packard y otros proveedores.

Después de probar la tecnología en un centro de datos en nuevas instalaciones, el fabricante de chips ahora está consolidando 13 de sus centros de datos internos, incluyendo todos los tradicionales así como aplicaciones conscientes de la nube, bajo un solo punto de control de software.

La arquitectura de Intel ofrece cinco APIs para sus desarrolladores de aplicaciones: una para cómputo, una para redes, otras respectivas para almacenamiento de bloques y objetos, y una para gestión de identidad. Intel también agregó una opción de plataforma como servicio (Paas) construida usando la plataforma de código abierto Cloud Foundry. De esta forma, los usuarios pueden acceder a APIs de más bajo nivel o usar abstracciones de más alto nivel. “Tenemos que servir diferentes tipos de usuarios”, anotó Das Kamhout, ingeniero principal. Y servirlos rápidamente. “El ritmo al que los proveedores de servicio de nube pública se están moviendo es una locura. Así que si los departamentos privados desean estar al día, deben mantenerse a la vanguardia -al menos un poquito”, señaló Kamhout.

Moverse a un SDDC le ha permitido a Intel crear una infraestructura de nube privada que ofrece utilización mejorada de cómputo, almacenamiento y recursos de red, autoservicio de usuario con ejecuciones medidas en menos de una hora en lugar de semanas, y potenciación de desarrolladores de aplicaciones, quienes ahora pueden definir los requisitos de infraestructura en software a través de una serie de APIs comunes. Después de años de trabajo duro, agregó Kamhout, “estamos llegando al punto en el que los desarrolladores pueden levantar algo y usar la capacidad del centro de datos”.

Pero la redistribución de la infraestructura de un centro de datos sobre tecnologías emergentes requiere cierta cantidad de garbo en un contexto de incertidumbre -y un montón de alambre para amarrar todo junto. Debido a que Intel comenzó temprano, no usó OpenStack en un inicio. Como resultado, tuvo que hacer un montón de personalización de código, incluyendo la construcción de su propia capa de orquestación para hacer que todo funcione.

“Estamos reemplazando todo eso con OpenStack nativo, ya que esto nos permite remover un montón de ‘deuda técnica’, y ser parte de una comunidad más grande que tiene exactamente los mismos problemas de nuestro equipo humano”, añadió Kamhout.

Con el nuevo paradigma, el personal de TI acostumbrado a configurar el hardware manualmente tiene que ser entrenado para usar las herramientas de scripting como Python y Puppet, y para manejar clusters virtuales de Linux. Kamhout señaló que los nuevos conjuntos de habilidades requirieron incluir conocimiento de automatización, scripting, Linux y análisis de datos. Lo que Kamhout llama herramientas de “Siguiente, siguiente, terminar” para configuración, aún están de seis a nueve meses de distancia. Todos quieren un botón “fácil” para la configuración. Pero mientras tanto, agregó, “usted debe elevar el nivel de su fuerza de trabajo o esperar a que las herramientas estén ahí afuera”.

Una vez que todos los 13 centros de datos estén listos, el enfoque cambiará a una visión unificada para arquitectura de nube híbrida en la que Intel se convierte en una nube pública para manejar picos de actividad, mientras que su nube privada soporta las cargas de trabajo básicas. “Hacer puente es la siguiente fase”, señaló Kamhout.

“Esperamos manejar un juego de APIs dentro y fuera de nuestro centro de datos. Queremos una nube federada, interoperable y abierta”. Pero las nubes públicas podrían necesitar exponer su infraestructura a esas APIs -algo que no están listas para hacer aún. “Ellos consideran esto como su salsa secreta”, dijo. Pero ocurrirá con el tiempo, anotó Kamhout, agregando que los medios de un proveedor de servicio de nube para adquirir un servidor no deberían ser vistos como un diferenciador competitivo.

Esperar que los proveedores de servicios de nube soporten directamente los APIs estándares de la industria no es realista, añadió Dave Shacochis, vicepresidente de plataformas de nube en el proveedor de servicios de nube CenturyLink. Pero, eventualmente, los proveedores de servicios como Century Link “estarán incentivados a publicar sus propias especificaciones de APIs”, agregó, y los terceros deberán construir las traducciones entre las diversas plataformas de nubes privadas y públicas.

Impulsados por la necesidad de velocidad

En FedEx todo es velocidad de entrega, y Chris Greer, personal técnico en FedEx Corporate Services,  señaló que la compañía desea expandirse a servicios de TI. “En la evolución de nuestro centro de datos, el software manda todo”, agregó. Su meta: automatizar todo, desde el procesamiento de aplicación definido por software bajando hasta el cómputo, almacenamiento y red, todo el camino hacia la base -energía, calefacción, enfriamiento, e incluso espacio blanco en el piso.

Todo esto, añadió, debería ser gestionado activamente para una máxima eficiencia, como dictan las necesidades de recursos de aplicaciones en la cima de la pila. Aunque FedEx tiene implementaciones de referencia, se está moviendo hacia adelante con cautela -y con el conocimiento total de que la gestión de algunas capas, como la energía y el enfriamiento, ni siquiera son alcanzadas por OpenStack hoy en día.

Pero lo que está disponible es sólido, añadió Jonathan Bryce, director ejecutivo en OpenStack Foundation. “Las capacidades técnicasestán maduras, pero tiene que haber una transición metódica en la compañía para hacer que esto ocurra”.

Don Fike, vicepresidente y arquitecto técnico en FedEx, señaló que no ha habido la suficiente unificación en la industria alrededor de los estándares de OpenStack -pero no está indeciso acerca de avanzar. “Tiene que presionar hacia adelante ahora, porque tomará tiempo lograrlo”, agregó. Y “tiene que estar comprometido a volver a trabajar todo”, indicó. “No puedes permitir que las antiguas decisiones legacy le mantengan atrás”. FedEs está siguiendo una pista de tres pasos hacia un SDDC.

“Virtualice su hardware primero”, y muévase hacia almacenamiento y red definidos por software, en segundo lugar, recomendó Greer. “Luego tiene un montón de trabajo para capturar las personalidades de aplicación, y entender cómo interactúan en el mundo. Dentro del próximo año, estaremos a escala en programación de dispositivos de hardware”, con redes definidas por software (SDN, software defined networking), luego siguen el almacenamiento y la seguridad, agregó. Aunque a Greer le gustaría tener una implementación abierta, el proyecto aún requerirá programación personalizada para llenar las grietas -la “salsa secreta” para hacer que todo funcione junto.

El almacenamiento y el networking son los más duros para automatizar, anotó Fike. “Nuestro otro reto, desde un punto de vista de regulación, serán los firewalls y la seguridad; pero eso solo es importante para ser capaz de mover cargas de trabajo”, explicó. Las necesidades de FedEx son complejas y conducidas por aplicación -y ese fue el punto de partida de la compañía. “Estamos construyendo un centro de datos definido por software con pleno conocimiento de las miles de aplicaciones corriendo en nuestro centro de datos”, indicó Greer. “La forma en que esas apps interactúan, sus configuraciones y lo que ellas hablan es extremadamente importante”.

Desafortunadamente, la capacidad de capturar los requerimientos de configuración para miles de aplicaciones y traducirlas en tareas de automatización, es donde las ofertas de productos están menos maduras, agregó Fike. Finalmente, espera que los socios proveedores de FedEx comiencen a ofrecer formas más sencillas y flexibles de capturar los requerimientos de configuración de aplicación, automatizar tareas asociadas y desplegarlas en infraestructuras de nube pública o privada. Pero, añadió, “los requisitos alrededor de esto son demasiado desalentadores para ellos en este momento”.

Unir todo

Columbia Sportswear no esperó a que los estándares maduren, optando en lugar de ello por un stack personalizado usando herramientas VMware, corriendo en una infraestructura de hardware Vblock. “Se trataba de ser capaz de construir un entorno altamente virtualizado, altamente flexible, altamente escalable, y ser capaz de moverlo transparentemente para casos de múltiple uso”, comentó Suzan Picket, gerente de servicios de infraestructura global en Columbia. La compañía no quiso esperar porque vio la automatización habilitada por un SDDC como una forma de evitar agregar más personal de TI, ya que enfrentaba un crecimiento de 700% en necesidades de sistema respecto a los años anteriores.

Después de clasificar las apps de Columbia por criticidad del negocio, Picket avanzó virtualizando el 85% del hardware servidor de la compañía y luego migrando a un sistema ERP de SAP que controla las operaciones estadounidenses en dos plataformas de infraestructura convergente Vblock System 700, a inicios del año pasado. “Fuimos en vivo sin un solo incidente crítico”, señaló la ejecutiva.

Ahora la compañía está considerando una estrategia de nube híbrida que pudiera pelar las capas más bajas de aplicaciones de su centro de datos interno y sucursales internas. “Quiero extender mis políticas, framework de seguridad, e incluso el single sing-on del Active Directory, y tener confianza en la plataforma subyacente”, agregó.

Sin embargo, esas movidas, deben ser compatibles con el conjunto de herramientas basadas en VMware de Columbia. El staff de TI ahora gasta menos tiempo en trabajo de rack-and-stack, y más en automatización, aprovisionamiento y estableciendo catálogos de servicio. Los tiempos de entrega del sistema han caído desde entre tres y seis semanas a aproximadamente cuatro minutos. “Si se necesita una base de datos de back-end, nuestro centro de automatización de nube lo hace. Nuestro staff tiene habilidades más altas y es más eficiente en lo que hacen”, indicó Picket.

Los servidores de Columbia están totalmente virtualizados. La compañía usó tecnología VPLEX de EMC para configurar el entorno virtual, y está evaluando el ViPR de EMC para el almacenamiento definido por software. El siguiente paso, agregó Picket, será adoptar redes definidas por software de modo que todos los cambios en la capa de red sean transparentes ya que las apps migran entre centros de datos.

“La SDN es enorme para nosotros”, comentó Picket. Pero aunque Columbia planea adoptar NSX de VMware para ese propósito, ella ve esa tecnología como un producto “versión 1” que necesita madurar. Al igual que la Application Centric Infraestructure (ACI) de Cisco, construida alrededor de sus switches serie 9000, “aún está en su infancia”, y no es un modelo puro basado en software, añadió. Ishmael Limkakeng, vicepresidente de gestión de producto en Cisco, anotó que ACI -cuando se compara con las superposiciones de software que ofrecen los competidores- es el más completo, y puede soportar otras marcas de switches, además de la serie 9000 de Cisco.

Pero Columbia sí tiene switches Cisco. De cara al futuro, Picket señaló: “no siento que necesitemos quedarnos solo con el enfoque de un proveedor. No siento que estemos atados a ninguna tecnología sola porque definimos el proceso debajo de él. También hay un riesgo asociado en usar un stack personalizado amarrado a proveedores de nube específicos, añadió Kerravala. ¿Puede migrar de uno a otro? ¿Qué pasa si se fusiona con otra compañía que usa otro proveedor de nube? Más adelante no podrá usar múltiples proveedores de nube”.

Quizás el reto más grande, fuera de la necesidad de un nivel ejecutivo de entrada, es vender el SDDC a los miembros del equipo de TI, cuyo trabajo de seguridad está amarrado a la necesidad de tener un racking, apilado y configuración manual de servidores, almacenamiento y red. “Ellos no están establecidos en TI en un entorno como-nube. Aun necesitan expertos que dominen el almacenamiento, redes, servidores y apps, pero el cambio a un modelo DevOps es obligatorio”, indicó Kerravala. “Nuestro reto fue cómo movernos hacia la automatización y dejar que TI esté tranquilo con el hecho de que nos estábamos exponiendo como autoservicio para usuarios”, señaló Kamhout, de Intel. “Ese era el punto de miedo”.

Esa actitud es comprensible, agregó Kerravala, porque casi la mitad de los ahorros en costos operativos que se derivan de moverse a un SDDC vienen de la mano de obra, la cual suma entre 40 a 45% de los costos totales. Aunque TI aún tiene trabajo de rack-and-stack que hacer, la mayoría de la configuración de los componentes de bajo nivel puede ser manejada completamente por software, con herramientas automatizadas.

Si, al igual que Intel, su personal de TI no entiende Linux o sripting, espere invertir en reentrenamiento. “La mayoría de TI no está interesado en cambiar desde una perspectiva personal”, señaló Kamhout, así que nuestro equipo de liderazgo tuvo que ayudarlos a transformarse y aprender las nuevas habilidades. Ese proceso toma años”. Pickett enfrentó retos similares de entrenamiento. “Para nosotros, se trata realmente de la madurez del conjunto de habilidades con algunos de esos productos automatizados”,  expresó, añadiendo que la tarea es aún más dura cuando los equipos de redes, almacenamiento y servidor están en sus propios silos.

El Nirvana será alcanzado cuando las cargas de trabajo asociadas con aplicaciones alcancen el hardware, el cual entonces se adapte en tiempo real, mencionó Kamhout. Por ejemplo, a él le gustaría ver una infraestructura a más bajo nivel, como el de energía y enfriamiento, responder a las demandas de cargas de trabajo en la forma más eficiente de manejo energético, como mover cargas de trabajo a un conjunto de recursos por la noche y apagando o disminuyendo la energía y el enfriamiento en áreas no utilizadas del centro de datos para ahorrar corriente. “Aún estamos a cuantos años de que eso sea real”, anotó. Pero es más posible a medida que avanzamos más en automatización”.

-Robert L. Mitchell, Computerworld EE.UU.