LinkedIn está tan involucrado en administrar sus propios centros de datos que lanzó su propia versión de Open Compute Project (OCP) basada en el rack de 19 pulgadas, Open19. También ha contribuido con cantidades significativas de código al sistema operativo de red SONiC de Microsoft para respaldar la funcionalidad que necesita para su propia red de centro de datos. Pero ahora está considerando mudarse a Azure.

Unos meses después del anuncio inicial, TechRepublic se reunió con el CTO de LinkedIn, Raghu Hiremagalur, para preguntarle por qué la empresa se está mudando a la nube y qué progreso se ha logrado hasta ahora. Y no, dice, no es porque Microsoft los posea o los presione, se trata de la oportunidad de escalar utilizando nuevos materiales y servicios que LinkedIn nunca podría crear por sí mismo.

Índice
  • Verdadera hiperescala
  • Migración de varios años
  • Local es el nuevo mainframe
  • Verdadera hiperescala

    Raghu Hiremagalur, CTO de LinkedIn.
    Imagen: LinkedIn

    Por un lado, mientras que Open19 se ha centrado en gran medida en simplificar y reducir el costo de operar un centro de datos, migrar a Azure elimina la necesidad de crear nuevos centros de datos.

    VER: Microsoft Azure: Guía de información privilegiada (PDF gratuito) (República Tecnológica)

    Hace diez años, los problemas de LinkedIn eran simplemente mantener su sitio web disponible a medida que crecía el tráfico, y pasó varios años enfocándose en cambiar a microservicios y tener la capacidad suficiente para atender a los miembros. . Luego comenzó a pensar en escalar la red y construir una arquitectura de centro de datos activo-activo. En los últimos tres años, esto ha cambiado para tratar de construir centros de datos de la forma en que lo hacen las nubes de hiperescala como Azure, con la red cambiando para satisfacer las necesidades de las aplicaciones que se ejecutan en ellas en lugar de pedirles a los desarrolladores que las aplicaciones funcionen con la infraestructura disponible. , ancho de banda y latencia.

    Pero estaba haciendo esto en centros de datos de tamaño mediano en lugar de los centros de datos en la nube gigantes a gran escala, y era más probable que el problema fuera quedarse sin espacio que quedarse sin energía. LinkedIn tiene alrededor de 250 000 servidores en cinco centros de datos, y ese número crece en un tercio cada año. También tiene 20 puntos de presencia y pares con 4000 redes, pero eso no se compara con Azure.

    “Estamos presentes en el oeste de Estados Unidos, el este de Estados Unidos, Singapur y Texas; son literalmente 57 regiones”, dice Hiremagalur. “Poder usar la red troncal de Microsoft es un beneficio inmediato: es probablemente una de las mejores redes troncales desde una perspectiva de red troncal privada, y tienen más de 160 ubicaciones de borde con Azure Front Door. Entonces, nuestra capacidad para servir a nuestros miembros será mucho mejor que donde estamos hoy porque podremos terminar sus sesiones cerca de donde están.

    LinkedIn hace más que usar la conectividad de Azure, dice Hiremagalur: “Nuestro plan es mover todas nuestras cargas de trabajo (producción, cómputo fuera de línea, cómputo actual) a Azure. En algún momento en el futuro, no queremos operar centros de datos. »

    No es porque LinkedIn no haya podido seguir haciendo crecer sus centros de datos: al menos durante los próximos cinco años, Hiremagalur no ve ningún problema en escalar su red, la capacidad del centro de datos, la energía u otras necesidades de infraestructura.

    LinkedIn no se está mudando a la nube porque lo necesita. Pero vale la pena pasar por lo que podría ser una migración bastante disruptiva de cargas de trabajo complejas por la oportunidad que ofrece Azure: agilidad.

    "Ya sea elasticidad y capacidad, o aprovechar las inversiones de Azure con su infraestructura perimetral con Azure Front Door, o su red troncal, o el trabajo que están haciendo en silicio personalizado, y el centro de datos y las cosas de red que están haciendo con aceleración redes e innovación en FPGA y almacenamiento... Todas esas son cosas a las que nos gustaría tener acceso con el tiempo”, dice Hiremagalur. "Y esas no son cosas en las que invertiríamos de forma independiente en nosotros mismos; no tiene sentido que invirtamos de forma independiente en ellas".

    LinkedIn también adoptará herramientas de IA en la nube como AzureML. “Las capacidades de Azure con lo que están haciendo en el campo de la IA son asombrosas. El nivel de computación GPU que tienen definitivamente nos beneficiaría significativamente”, dice Hiremagalur.

    Migración de varios años

    Ser parte de Microsoft significa que LinkedIn tiene una visión avanzada de lo que sucede en Azure. Hiremagalur quiere embarcarse en una migración que tardará varios años en estar lista para ello. “Dado el tiempo que creemos que tomará mover nuestras cargas de trabajo a Azure, queríamos comenzar el proceso ahora y estar listos para aprovechar todas estas cualidades cuando todo esté listo para nosotros”.

    Mientras tanto, LinkedIn continuará desarrollando su propio producto, pero al mismo tiempo se preparará para el movimiento y pensará en lo que puede dejar de hacer una vez que se ejecute en Azure.

    "En general, las interfaces que nuestros componentes básicos de infraestructura, como la indexación de almacenamiento, brindan al resto de la organización de ingeniería deben permanecer consistentes o al menos muy similares, por lo que la infraestructura de nuestros equipos de ingeniería hará el trabajo pesado de adaptar nuestros componentes básicos de infraestructura para ejecutar en la nube pública”, dice Hiremagalur.

    Pero no quiere terminar con una copia de la infraestructura actual de LinkedIn, solo en la nube. "Esta es una oportunidad para que desagregemos el cómputo y el almacenamiento. Tenemos la capacidad de aprovechar la elasticidad a escala para trabajar con los patrones de carga de trabajo diurnos que tiene LinkedIn. [with most users logging in during working hours]. Estas son cosas que queremos comenzar a aprovechar en nuestro viaje a Azure.

    LinkedIn utiliza bases de datos de gráficos muy grandes; hay una gran cantidad de Kafka (que se desarrolló en LinkedIn y manejaba más de un billón de eventos por día en 2015), y los sistemas de procesamiento de flujo de Samza se construyeron sobre Kafka, como la computación fuera de línea y el aprendizaje automático. Hace un uso intensivo de la red: por cada byte de datos que ingresa a un centro de datos de LinkedIn a partir de la actividad del usuario, se generan aproximadamente 1000 bytes de tráfico de este a oeste dentro del centro de datos de LinkedIn. sistemas como recomendar personas que podrías conocer).

    “Podremos aprovechar esta agregación de red y almacenamiento a gran escala, así como la capacidad de escalar el cómputo y el almacenamiento de forma independiente. Somos un sistema muy intensivo en datos, por lo que poder administrar estos dos como dos unidades separadas también es una gran ventaja para nosotros”, dice Hiremagalur.

    “Cuanto menor sea la latencia de la red, más recorridos de la base de datos de gráficos podrá realizar”, señala. “La capacidad de atravesar nuestro gráfico de una manera muy interesante requiere, por supuesto, sistemas distribuidos muy buenos y muy bien diseñados, pero también redes de primer nivel. Espero con ansias la posibilidad de tener un servidor sin servidor a escala para este tipo de cargas de trabajo y no tener que preocuparme en absoluto por cómo se ejecutan y terminan estas cosas. Estas cosas son candidatos increíbles para la informática sin servidor.

    VER: Informe especial: Prepárese para la informática sin servidor (PDF gratuito) (República Tecnológica)

    Es un cambio de arquitectura que LinkedIn habría considerado si se mudó a Azure o se quedó en sus propios centros de datos. Pero este movimiento significa que habrá áreas de infraestructura que LinkedIn puede ceder por completo a Azure.

    “Operar una carga de trabajo a gran escala en una nube pública es diferente de administrarla nosotros mismos, donde tenemos el 100 % de control sobre literalmente todo. Así que tendremos que aprender a operar un sitio de manera muy estable con estos cambios”, dice Hiremagalur.

    En lugar de pensar en fallas de hardware y servicios, los ingenieros tendrán que planificar ciclos de actualización que no controlan, dice Hiremagalur. “Necesitamos aprender a responder a las señales de que Azure nos servirá y comprender cómo mover o pausar las cargas de trabajo. La forma en que manejamos la seguridad va a ser diferente. Las capas de la pila sobre las que tenemos el 100% de control simplemente se reducirán: no controlamos la red, no controlamos los conjuntos de datos dispares. Entonces, la forma en que pensamos sobre la seguridad de la información tiene que evolucionar, la forma en que pensamos sobre la seguridad perimetral tiene que evolucionar.

    Es la historia habitual de migración a la nube: no está moviendo una aplicación a otro servidor, está moviendo lo que necesita hacer a otro tipo de abstracción. Una vez que haya hecho el trabajo, la recompensa es que puede concentrarse en problemas de mayor nivel.

    "Lo veo como tener la capacidad de centrarnos en áreas en las que brindamos un valor único y nos apoyamos en nuestros homólogos de Azure, para hacer cosas que están haciendo a una escala extrema y muy, muy bien", dice Hiremagalur. “Visualizo esto como un aumento del nivel del mar: las cosas que se sumergen bajo el agua para nosotros son cosas para las que solo confiamos en Azure. El resto son cosas que seguimos haciendo y en las que podemos centrarnos mucho más.

    Local es el nuevo mainframe

    La iniciativa Open19 no va a desaparecer, dice Hiremagalur. "Ya hemos obtenido mucho valor de esto: lo hemos implementado en nuestros centros de datos, ya hemos traído un montón de tecnología a OCP y continuaremos colaborando con ellos".

    Pero además de organizaciones gigantes como Facebook que ejecutan su propia nube, Hiremagalur también espera que más empresas se trasladen a la nube pública con el tiempo para una gran parte de sus cargas de trabajo, ya que sus propios desarrolladores lo exigirán.

    "Si no tiene acceso a las innovaciones que sucederán en la nube pública durante los próximos cinco a diez años, su empresa puede ser vista de la misma manera que las empresas que se ejecutan en mainframes, y ninguna empresa quiere estar en esta posición. ”

    Ver también

    • Multinube: una hoja de trucos (TechRepublic)
    • Nube híbrida: una guía para profesionales de TI (descarga de TechRepublic)
    • Principales proveedores de nube de 2019: AWS, Microsoft, Azure, Google Cloud; IBM se vuelve híbrido; Salesforce domina Saas (ZDNet)
    • Los mejores servicios en la nube para pequeñas empresas (CNET)
    • Microsoft Office frente a Google Docs Suite frente a LibreOffice en 2018 (Download.com)
    • Computación en la nube: más cobertura de lectura obligatoria (TechRepublic en Flipboard)