Construir y escalar un centro de datos es difícil. La mesosfera lo está haciendo más fácil. Matt Asay explica.
La manzana puede ser la envidia de la clase adinerada, regordeta con altos márgenes y ventas de alto volumen. Pero la mayoría de las empresas aspiran a ser Google cuando se trata de poner los datos a trabajar.
Para llegar allí se requiere algo más que la voluntad de hacer de los centros de datos una competencia central. Las empresas tienen que pensar diferente sobre el software, con proyectos de código abierto como Apache Mesos ayudando a los ingenieros de uber a crear sistemas operativos de centros de datos, tratando el hardware como si fuera «ganado» en lugar de «mascotas».
Pero sigue siendo difícil, y todavía hay que ser bastante «súper» para que funcione.
Lo que hace que las noticias más importantes de Mesosphere sean particularmente interesantes. En su cara, Mesosphere ha puesto en marcha un programa para desarrolladores y ha lanzado un SDK para facilitar un poco la vida de los posibles desarrolladores de Mesos. Pero en realidad es parte de un gran plan para llevar el poder de Google, con la simplicidad de Apple, a la empresa.
Anteriormente hablé con el CEO de Mesosphere, Florian Leibert, sobre su concepto de «sistema operativo de centro de datos», y la compañía ha estado en una laguna. Contrató al creador de Mesos de Twitter, se llevó a un profesor de investigación de sistemas distribuidos de la Universidad de Stanford, se tragó a una firma de diseño de Nueva York, cerró una ronda de la Serie B liderada por Khosla Ventures y anunció el lanzamiento de su Sistema Operativo de Datacenter (DCOS.
El CEO de Mesosphere, Leibert, me habló de cómo la compañía piensa en un nuevo modelo de despliegue para las pilas de software de aplicaciones distribuidas en el centro de datos y en la nube.
ConsejoTecnologico.com: Primero, cuéntame sobre las noticias de los nuevos desarrolladores.
Leibert: Ofrecemos a los desarrolladores y socios herramientas para facilitar la creación de aplicaciones distribuidas. Seamos honestos, construir sistemas distribuidos es difícil. Necesitan ser escalables, tolerantes a fallos, altamente disponibles, consistentes, seguros, elásticos y eficientes.
Para lograr estas propiedades, los sistemas distribuidos requieren que muchos componentes complejos trabajen juntos de una manera muy sofisticada. Por ejemplo, Apache Hadoop depende de un sistema de ficheros altamente tolerante a fallos (HDFS) para proporcionar un alto rendimiento para procesar conjuntos de datos multi-terabyte en paralelo en grandes clusters.
En el pasado, cada nuevo sistema distribuido, como Hadoop o Cassandra, tenía que construir su propia subestructura para mensajería, almacenamiento, redes, tolerancia a fallos y elasticidad.
Afortunadamente, sistemas como Mesos y DCOS simplifican la tarea de construir y administrar sistemas distribuidos al proporcionar primitivas similares a las de un sistema operativo para los bloques de construcción clave de los sistemas distribuidos. Mesos extrae la CPU, la memoria, el almacenamiento y otros recursos para que los desarrolladores puedan escribir aplicaciones distribuidas como si los clústeres de sus centros de datos fueran una máquina gigante.
Además, ahora que hay docenas de estos sistemas distribuidos escritos de forma nativa en Mesos y DCOS, estamos viendo un nuevo modelo que construye pilas de backend compuestas de estos bloques de construcción para ofrecer soluciones de casos de uso en el mundo real.
ConsejoTecnologico.com: ¿Qué quiere decir con «stack» bajo este modelo de sistema operativo de centro de datos?
Leibert: Los desarrolladores modernos que construyen aplicaciones back-end normalmente necesitan trabajar con múltiples servicios para crear lo que tradicionalmente se conoce como funcionalidad «stack». Por ejemplo, la mejor práctica actual para construir un pipeline de datos en tiempo real significa que un desarrollador probablemente usaría Apache Kafka y Akka para mensajería y acceder a un almacén de datos distribuido como MemSQL o Cassandra y ejecutar análisis a través de Apache Spark.
Para establecer esto en el viejo mundo como desarrollador, el equipo de operaciones tuvo que proveer clusters separados (uno para cada framework) y soportarlos, estáticamente, con herramientas de gestión de configuración como Chef y Puppet.
Reclamar los recursos y poner en pie estos servicios en silos puede llevar semanas o meses, y si hubiera entornos de desarrollo y puesta en escena, el resultado sería una matriz multidimensional de clústeres, cada uno con su propia complejidad operativa, sobrecarga y, en consecuencia, baja utilización.
En este nuevo modelo de sistema operativo de centro de datos, las organizaciones pueden componer estas complejas pilas rápidamente mediante la instalación de servicios distribuidos con una simplicidad que le recuerda la instalación de una aplicación desde la tienda de aplicaciones de iPhone.
ConsejoTecnologico.com: ¿Eso significa, literalmente, navegar por un catálogo de servicios y elegir los que desea instalar?
Leibert: Sí, mucho. Una de las cosas que hemos hecho en Mesosphere, que se siente como magia pura, es construir un sofisticado sistema de empaque que hace posible descargar e implementar un sistema distribuido a escala de centro de datos a través de un solo comando en la línea de comandos.
Por ejemplo, para instalar Kafka en su cluster, simplemente escriba el paquete dcos install kafka. Es así de fácil. En segundos, el paquete Kafka es descargado e instanciado en el cluster en una configuración altamente disponible, listo para escalar a cientos de nodos si es necesario y listo para empezar a aceptar flujos de datos.
Nuestro enfoque DCOS permite a los desarrolladores centrarse en el servicio que están creando y en la lógica de negocio de la aplicación. Hemos abstraído la complejidad del back-end. Los servicios sólo funcionan, obteniendo los recursos que necesitan del grupo. Y hemos eliminado las operaciones de la ecuación. Esos equipos de operaciones ahora pueden centrarse en cosas más interesantes e importantes en el funcionamiento de un centro de datos que en la gestión y respuesta a los tickets de ayuda al desarrollador.