¿Está trasladándose al SDN? No salte a ciegas. Ayuda saber, primero, que es el software-defined networking, y luego qué puede hacer por usted.
Luego es bueno saber todo el funcionamiento interno de un controlador SDN, las diferencias entre los productos que ofrecen los proveedores conocidos y las startups, y si el código abierto y el bare metal switching es una opción posible. Por último, conozca su propia red -¿va a soportar SDN o requerirá de un cambio a gran escala?- y luego aprenda de sus pares y sus experiencias. A continuación una guía de once consejos sobre cómo prepararse para el SDN:
1. Infórmese al respecto: Muchas organizaciones aún no saben qué es el software-defined networking, de qué se compone y cómo se podrían beneficiar de él. Es obvio, pero familiarizarse con el concepto es el primer paso para entender cómo el SDN puede ayudar o estorbar a la red de su empresa. Google, Facebook, Yahoo y Amazon Web Services frecuentemente señalan los beneficios y señalan el camino de los estándares, pero estas organizaciones no son el mainstream; se encuentran en la punta de todo lo que tiene que ver con la computación y el networking. Lea sobre los varios ‘sabores’ e iteraciones del SDN, qué es lo nuevo, qué es lo antiguo, etcétera. Puede que genere su propia definición.
2. Sepa qué es lo que quiera hacer: Goldman Sachs quiere estándares abiertos, arquitecturas de gran escala commodities, datos y planes de control independientes y programáticos, servicios virtualizados de Layer 4-7, cosas comerciales por aquí, código abierto por allá? El SDN fue dirigido inicialmente al centro de datos, pero ahora la WAN de la empresa es el foco central de los beneficios de la automatización y la orquestación del SDN. ¿Quiere un plano de control centralizado o distribuido? ¿Por qué o por qué no? Algunas de las aplicaciones SDN más imperiosas son la analítica y el monitoreo de paquetes —TAP- debido a la capacidad del SDN de dirigir rápidamente el tráfico con tan solo unos clics. Orquestar y automatizar la red a través de software puede ahorrar gastos de capital y operativos, señalan los defensores. Determine cuál es su meta u objetivo con el SDN y realice la implementación de acuerdo a ello, de forma prudente y gradual.
3. Considere las implicancias sobre la seguridad: Centralizar todo el control del SDN puede hacerle la vida más fácil al operador de la red, pero también genera un punto único de falla —catastrófica- o de ataque para un hacker o contenido malicioso. ¿Cómo va a reaccionar el controlador con las caídas que requieren el re ruteo del tráfico? Si un hacker obtiene el control de su controlador, ¿podría ese intruso derribar su red?
4. Piense en dónde comenzar: Como se mencionó líneas arriba, el SDN fue inicialmente -y aún se encuentra- dirigido al centro de datos en donde son obvios gran parte de los beneficios de la automatización y la orquestación, y de la reducción en los costos de capital y operativo. Pero la WAN empresarial se menciona ahora con mayor frecuencia como el foco primario para el SDN. Las WAN pueden igualmente beneficiarse de la automatización y la simplificación de la administración que los SDN conllevan, señalan los defensores del concepto. Las grandes tendencias de TI, como el software como servicio, nubes privadas, BYOD, movilidad y convergencia de voz/datos están presionando sobre la calidad de los enlaces en una WAN empresarial. Y los enlaces WAN requieren ahora de una mejor seguridad, menor latencia, mayor confiabilidad y soporte para cualquier dispositivo -en cualquier lugar- se adapte a estas tendencias. Los SDN pueden ayudar a la TI empresarial a lograr esto sin tener que hacer el gasto de hacer la actualización de enlaces individuales de WAN, señalan los que respaldan el concepto, y pueden permitir la priorización de las aplicaciones y el tráfico, facilitar el aprovisionamiento y mejorar la seguridad.
5. Pondere cómo comenzar: Comience en pequeño, señalan aquellos que tienen experiencia. Establezca una pequeña parte de su red de evaluación y desarrollo para experimentar con el SDN en lugar de hacerlo en toda ella. De esa forma, si algo sale mal, no va a afectar a toda la red de producción. Una vez que las cosas vayan bien, gradualmente podrá unir el SDN piloto con la red de producción y preparar otra pequeña parte de la red para la transición. Y cuando las cosas sigan yendo bien, el SDN puede ayudar en combinar las redes de desarrollo y operaciones en un solo ambiente DevOps en donde rápidamente se pueden activar las capacidades para producción una vez que hayan sido desarrolladas y probadas.
6. Evalúe las diferentes ofertas de los proveedores: Conozca los pros y los contras de los principales y más conocidos proveedores y sus ofertas de SDN/redes programables: la Application Centric Infrastructure de Cisco, el NSX de VMware, las Virtual Application Networks de HP, Contrail de Juniper, etcétera. Sepa en qué difieren –underlays físicos/virtuales, overlays de virtualización de red, reenvío basado en OpenFlow y administración del flujo- y en qué se parecen. Tome en cuenta la implementación que está intentando lograr. Estudie minuciosamente sus ecosistemas de aplicaciones en busca de soluciones a sus problemas.
7. Estudie las ofertas de código abierto y ‘caja blanca’: Bueno, si le sirve a Google? Quizás no haya centros de datos más sofisticados y complejos que aquellos de las compañías de escala global. Ellas encuentran soluciones en el hardware y software que se vende abiertamente, como lo son los switches de componentes comerciales de los Fabricantes de Diseño Original (Original Design Manufacturer) y el software de código abierto. Y el OpenDaylight Project ha desarrollado un framework de SDN de código abierto a partir del código de varios proveedores conocidos, en caso de que alguna empresa se preocupe al descargar SDN de la “comunidad”. Pero los Googles del mundo añaden una buena cantidad de su ‘salsa secreta’ y mezclan todo esto por ellos mismos. Los switches de código abierto y ‘caja blanca’ pueden hacerse cargo del SDN, pero usted tendrá que diseñar, instalar, operar, administrar, mantener, servir y soportar la infraestructura por sí mismo. A menos que opte por comprarle a las alianzas como Dell y Cumulus?
8. Revise las ofertas de las startups: Hablando de Cumulus, ellos son una startup con una interesante propuesta de código abierto/caja blanca que involucra un sistema operativo Linux específico para networking que puede correr en switches bare metal -es decir, solo ‘fierro’. Esta opción promete reducir drásticamente el gasto en networking del centro de datos, y con la sociedad con Dell, los clientes pueden ahora obtener el servicio y el soporte de un gigante de los centros de datos. Las startups se encuentran en todo el panorama del SDN: Vello Systems tiene software OpenFlow 1.4 para SDN ópticas para empresas; Pluribus y Adara combinan servidores con switching para integrar servicios virtuales con la infraestructura física; Big Switch Networks se enfoca en la orquestación de los recursos de networking físicos y virtuales; el sistema NCX de Anuta Networks es un controlador para una máquina virtual o x86 basado en appliance y agentes que interactúan mediante un conjunto de protocolos y API —incluyendo OpenFlow— para automatizar el aprovisionamiento y orquestación de los servicios de networking de Layer 2-7 en las infraestructuras existentes; y la lista continua. Las empresas deberían considerar las tecnologías de punta de las startups para sus SDN.
9. Determine las funcionalidades que necesita en un controlador SDN: Ethan Banks ha escrito un tratado sobre qué buscar en un controlador SDN. Entre sus consideraciones se encuentran el desempeño, capacidad, topología, capacidad y funcionalidad, apertura versus ataduras a un proveedor, entre otros. Pero Banks concluye que las empresas deben realizar una due dilligence (auditoria) en sus redes y definir qué quieren que el SDN haga en ellas, además de informarse a sí mismos sobre el controlador.
10. Aprenda de las experiencias y las mejores prácticas de sus pares: Goldman Sachs está en ello. Ha estado haciendo SDN antes que la tecnología se llamara así. Ahora la firma financiera quiere un poco más de consistencia, uniformidad y apertura. El Centro Médico de la Universidad de Pittsburgh también se encuentra en ello, está buscando un SDN y una nube privada para llevar la red al mismo nivel en el que se encuentra la virtualización de la institución. El Marist College también está en ello, la escuela está viendo el OpenFlow como una forma de interconectar los centros de datos con fibra óptica. Está usando controladores de código abierto, así como monitores para los servidores. Está trasladando cargas de trabajo entre los centros de datos, experimentando con la escalabilidad, investigando las SDN con IBM, y puede compartir mucha experiencia. Bloomberg tienen una SDN de propósito definido para el monitoreo del tráfico y el aprovechamiento del desarrollo de aplicaciones financieras, y también viendo la forma en que un overlay de SDN escala para los usuarios que van de una nube a otra. Todos los usuarios concuerdan en una cosa: hay que ir lento con el SDN.
11. Considere el impacto sobre su actual red: El Centro Médico de la Universidad de Pittsburgh encontró que su red actual no podía con la tarea cuando tenía que mover máquinas virtuales, así que se fue hacia una nube privada de SDN. La mayoría de los escuerzos de SDN probablemente van a requerir de enormes actualizaciones en redes que tienen más de cinco años de antigüedad. Cisco está guiando una nueva línea de switching para su Application Centric Network. El nuevo core switch SDN de Juniper, el EX9200, va a requerir una enorme actualización con respecto al EX8200. De hecho, el SDN está dejando de lado muchos viejos switches. Antes de dar el salto al SDN, sería bueno saber cuánto va a tener que saltar. Y si nada funciona mal sin el SDN, ¿vale la pena cambiar?
–Jim Duffy, Network World (EE.UU.)
