Para poner de relieve la importancia de la estandarización, Schmitz citó el histórico incendio que afectó a Baltimore, Estados Unidos, en 1904. La magnitud del incendio obligó a las autoridades a convocar cuerpos de bomberos de otros estados federados, los que trajeron sus propios equipos y mangueras. Al intentar conectar las bocas de las mangueras a los hidrantes constataron, consternados, que no eran compatibles. A pesar de 35 años de intentos por estandarizar tales equipos en EE.UU., esto no había sido posible, con trágicas consecuencias. Para el caso particular de Baltimore, la fabricación de los hidrantes había sido encomendada a un fabricante, que –curiosamente– decidió instalar 600 componentes, principalmente en las válvulas de los hidrantes, patentando luego el diseño. Su lógica era, según Schmitz, “hemos construido una tecnología propietaria, que no queremos compartir”. El CEO de OCC recalcó lo contraproducente de que alguien patente este tipo de tecnología, pero que a fin de cuentas fue lo que ocurrió.
El incendio de Baltimore duró dos días, y la razón es únicamente atribuible a la falta de estandarización; es decir, aún con 2500 bomberos presentes, provenientes de otras regiones, no fue posible controlar el fuego lisa y llanamente debido a que no pudieron conectar sus equipos a los hidrantes.
Lo verdaderamente sorprendente, quizás increíble, es que 110 años después de estos hechos, la mitad de las ciudades estadounidenses aún no han estandarizado sus equipos.
“Esperemos que en la nube tengamos un mejor resultado”, comentó Schmitz, antes de abordar de lleno el tema.
La labor de OpenCloud Connect
“OpenCloud Connect es una entidad adscrita al Metro Ethernet Forum (MEF), organización que agrupa a empresas Carrier Ethernet, un negocio que en sólo cuatro años generó US$ 10 mil millones de facturación.
Jeffrey Schmitz
Según Schmitz, hay varias razones clave que explican por qué el proceso de estandarización ocurrió mucho más rápido para el caso de la Nube: “En primer lugar, el MEF fue lo suficientemente listo como para discernir el tema desde la perspectiva corporativa y del usuario final. Con ello me refiero a los servicios que requiere el usuario final. La entidad definió entonces los estándares a partir de las necesidades del usuario final – que a fin de cuentas es quien está pagando. Es un primer paso crítico”. El presidente de OCC puntualizó que si ese hubiera sido el caso en Baltimore; es decir, si se hubiera pensado más en la gente cuyas casas se incendiarían, quizás el problema habría sido solucionado un poco más rápido. “Luego, estamos frente a un diferenciador clave en cuanto a la forma en que el MEF enfrentó el problema”.
“En segundo lugar se requería un lenguaje común”, dijo Schmitz, puntualizando que la moneda de cambio utilizada por el sector corporativo que adquiere servicios de Ethernet es Carrier Ethernet, que facilita sobremanera la comunicación a través de todas las entidades que están proporcionando el servicio.
En tercer lugar se sitúa la conectividad global, dijo Schmitz, agregando que no hubo un país o ciudad que decidieran estandarizar. “Ahora estandarizamos a escala global, desde certificaciones hasta programas de capacitación. Tenemos cientos de personas capacitadas para Carrier Ethernet, que están instalando y dando soporte a estos servicios”.
Las empresas ya están en la Nube
El ejecutivo explicó que según estudios analizados por OCC, la mayoría de las empresas ya cuentan con 10 a 15 servicios en la nube, lo que pone de relieve la rapidez con que el negocio está escalando. “Ya no hablamos solamente de un negocio que alcanzó los US$ 10 mil millones en pocos años; es un negocio del rango de los US$ 100 mil millones. La escala es formidable”.
La situación se complica cuando actores como centros de datos y servicios en la nube buscan conectividad, señaló el ejecutivo, explicando que en el caso de los grandes actores, estos buscan modelos como el de Baltimore; queriendo decir que tienen la capacidad de pautar a sus proveedores cómo conectarse a su red. El razonamiento es que al constituir un negocio atractivo, los proveedores no tendrán inconveniente en adaptarse a su “estándar propietario”.
“Claro está, hay miles de proveedores de servicios en la nube. ¿Cómo se conectan de forma estandarizada? ¿Qué les permite tener una posibilidad justa, y un escenario justo, donde puedan captar una parte de ese mercado?
Para el caso de OCC, es necesario buscar inspiración en el MEF y aplicar sus soluciones al ámbito de la nube, señaló Schmitz, a cuyo juicio primero es necesario definir los servicios. “Si voy a tener un servicio en la nube, necesito saber el ancho de banda, desempeño y seguridad, los que dependerán del servicio en cuestión y su eventual conectividad global – además que quiero implementarlo con rapidez”.
Lenguaje común, sin jergas: un imperativo
Schmitz recordó entonces que el problema es complejo y que al sector han acudido más actores que antes, en todo nivel del negocio, lo que hace imperativo contar con un lenguaje común. “Necesitamos tener una moneda común para los servicios basados en la nube” dijo el ejecutivo, quien advirtió contra los sistemas propietarios: “Si opto por una solución propietaria; si uso mi válvula no-estándar para conectar a mi proveedor de servicios cloud en la red, corro el riesgo de que mi empresa quede atrapada. Al llegar a cierta escala, las cosas se complican si no utilizas estándares”.
Schmitz relató el caso de uno de los proveedores de servicios afiliados a OCC, presente en el evento, quien le comentó que cada vez que deben aprovisionar servicios a su red puede tomar hasta una semana sólo identificar la jerga utilizada para empezar a habilitar las conexiones. “Esto tiene que ser aerodinámico, principalmente debido a que no disponemos de 100 años, o 25, o 4; este negocio ya está facturando por US$ 100 mil millones”.
Estándares, a la velocidad de la nube
Schmitz puso entonces de relieve el reto de la velocidad. “Los estándares tendrán que funcionar a la velocidad de la nube. Tomemos por ejemplo el caso de Uber; con menos de cinco años es la mayor empresa de taxis y, adivina, no son propietarios de un solo vehículo. Es sorprendente. Luego, Facebook, son el mayor proveedor de contenidos del mundo, y no crean contenidos propios. Alibaba, en tanto, es el mayor minorista del mundo, y ni siquiera tienen existencias. Airbnb, con menos de cinco años online es el mayor proveedor de hospedaje, y no tienen una sola habitación propia. A eso me refiero con velocidad”.
Todo lo anterior pone de relieve la necesidad de contar con un lenguaje común, señaló Schmitz, puntualizando que OCC ya lo ha hecho, con la publicación de su arquitectura de referencia. “Al contar con un lenguaje común no tenemos que pasar horas cada semana simplemente tratando de entender un lenguaje común para conectar estos servicios cloud a un proveedor”.
El modelo DevOP
El último factor de gran relevancia para Schmitz y OCC es avanzar hacia un modelo DevOp; es decir, un enfoque más ágil en cuanto a los estándares. “OpenCloud Connect es uno de los actores abocados a tal labor. Otras personas están buscando pruebas de concepto y formas de habilitar estándares expeditos. En nuestro caso, estamos utilizando el modelo DevOps”.
El ejecutivo mencionó un laboratorio de conectividad operado por la empresa en San Francisco, Estados Unidos, donde se avanza según un modelo casuístico ya que “no vamos a pasar años frente a un teclado, escribiendo el estándar perfecto y luego dedicar años a intentar venderlo e implementarlo. Estamos ensayando y viendo qué funciona aquí y ahora”.
Por Héctor Pizarro, desde Tiburón, California, Estados Unidos
—-
Fotografías © NetEvents y OpenCloud Connect
