Administrar la infraestructura en Google es mucho más que simplemente poner cosas en contenedores y dejar que Borg lo empuje
Es todo un arte mantener los servicios funcionando a escala y en funcionamiento, y las personas que lo hacen se denominan ingenieros de confiabilidad del sitio o SRE. Cada vez se adoptan más las prácticas que creó Google y también el término SRE.
La mayoría de las empresas no pueden contratar a las personas más inteligentes en infraestructura del mundo, como pueden hacerlo los hiperescaladores y los creadores de nubes. Por eso confiamos en alguien para crear las herramientas de software que incorporan su experiencia. Esto sucedió con los contenedores de Linux y la orquestación de contenedores, por ejemplo, que se perfeccionaron en gran medida en Google, y ciertamente ha sucedido con la infraestructura nublada en general. Y para esa experiencia de SRE encapsulada en software, la comunidad de TI confía en personas como Brian Singer.
En 2012, Singer cofundó Orbitera, una empresa que creó una plataforma de mercado para comprar y vender software en la nube. Una parte importante de eso fue garantizar que la facturación fuera oportuna y precisa, algo con lo que Orbitera luchó en ocasiones. Bueno, hasta que Google Cloud compró la compañía en 2016 como parte de los esfuerzos del proveedor de nube más grande para expandir su presencia en el espacio de servicios empresariales.
Fue allí donde Singer y Marcin Kurc, entonces CEO de Orbitera, vieron el trabajo que estaba haciendo Google en el área de ingeniería de confiabilidad del sitio (SRE), que utiliza prácticas de ingeniería de software para ayudar a mantener las operaciones de infraestructura. El objetivo es garantizar que la infraestructura continúe funcionando a niveles que permitan a las empresas cumplir con el SLA y otros objetivos, lo que no siempre es una tarea fácil en un momento en que el entorno de infraestructura de una empresa puede abarcar nubes híbridas , múltiples nubes , el borde y los centros de datos heredados.
" Llegamos a comprender algunas de las prácticas de producción que se utilizan dentro de Google para satisfacer lo que buscaban los clientes", dice Singer a The Next Platform . “Una de las cosas en las que Google ha hecho un trabajo realmente bueno a lo largo de los años es aplicar los principios de ingeniería al problema de administrar y ejecutar la infraestructura. Eso ha dado lugar a un conjunto de prácticas de producción y un título de trabajo, por así decirlo, llamado ingeniería de confiabilidad del sitio, o SRE, algo que comenzó dentro de Google probablemente hace una década y media. Obviamente, se ha practicado en algunos de los sistemas de mayor escala que existen, pero para nosotros, como una startup más pequeña, ingresamos a Google e inmediatamente tuvimos que adaptar nuestras prácticas a lo que hacen para ejecutar la producción y adoptamos específicamente muchos de estos principios SRE. "
En esencia, SRE utiliza prácticas de DevOps para reducir la cantidad de trabajo que se necesita una y otra vez, como reiniciar las máquinas en un horario regular porque, de lo contrario, se quedarían sin memoria. El objetivo es descubrir cómo no tener que reiniciar esas máquinas de forma programada.
"Este conjunto de prácticas de producción dentro de Google que dio lugar a SRE en realidad ha dado lugar a gran parte de la infraestructura que comenzamos a dar por sentada hoy, como Kubernetes ", dice Singer. “Kubernetes es algo que surgió del trabajo de Google en su propia placa de plataforma de orquestación de contenedores y es algo que fue construido por los SRE de Google [ingenieros de confiabilidad del sitio] durante muchos, muchos años. Para los SRE, uno de los ejes que les permite hacer su trabajo de manera realmente exitosa es que pueden construir circuitos de retroalimentación entre lo que están haciendo los desarrolladores que están construyendo características y los operadores que son responsables de garantizar que un servicio funcione en producción. . "
Esos ciclos de retroalimentación ayudan a los desarrolladores y SRE a ver si lo que están haciendo daña la experiencia del usuario final o no cumple con las expectativas, lo que a su vez puede afectar a la empresa en términos de clientes perdidos o afectar su reputación. Eso ha dado lugar a objetivos de nivel de servicio, o SLO, que esencialmente son objetivos que las empresas deben mantener para cumplir con los SLA. (También en la mezcla están los SLI, o indicadores de nivel de servicio, que miden el cumplimiento de los SLO).
En principio, es algo bastante sencillo", dice Singer. “Tiene mucho sentido tener un objetivo y comprender cómo estamos avanzando hacia ese objetivo, dadas todas las cosas que hacemos en nuestra infraestructura y todos los cambios que hacemos en nuestro software. Pero en la práctica, históricamente, este tipo de cosas requirieron algunos ingenieros muy sofisticados para poder ponerse en marcha. Lo que encontramos en el mercado durante los últimos dos o tres años es que SRE, debido a los beneficios que tiene en términos de obtener apalancamiento y escala sobre la infraestructura y mejorar la vida de los desarrolladores y clientes, está comenzando a obtener una adopción generalizada. Lo que estamos viendo es que muchas empresas están empezando a intentar averiguar: '¿Cómo adoptamos e implementamos una solución?' ”.
Singer y Kurc, al ver un creciente interés entre las empresas por adoptar SRE, en 2019 lanzaron Nobl9, con el objetivo de brindar a las organizaciones un servicio comercial que les permita aprovechar los SLO, una piedra angular de SRE. Después de aproximadamente nueve meses de pruebas beta con una variedad de organizaciones, la puesta en marcha a principios de febrero hizo que su plataforma SLO de software como servicio (SaaS) homónima estuviera disponible para todo el mundo. Una semana después, Nobl9 anunció $ 21 millones en fondos de la Serie B que incluían varias firmas de capital de riesgo, incluidas Battery Ventures, CRV, Bonfire Ventures y Resolute Venture, todas las cuales contribuyeron a los casi $ 7.5 millones que la compañía recaudó en septiembre de 2019.
La plataforma está diseñada para utilizar fuentes de datos existentes, como sistemas de monitoreo, para recopilar métricas y determinar objetivos de confiabilidad. Las herramientas dentro de la plataforma ayudan a las empresas a crear circuitos de retroalimentación y garantizar la confiabilidad de la infraestructura para permitirles mantenerse en línea con sus SLO mientras equilibran el desarrollo de las características del software, la confiabilidad, los objetivos comerciales y los costos. La oferta de SaaS puede funcionar no solo con infraestructuras en la nube, sino también con operaciones locales heredadas, dice Singer, director de productos de Nobl9. (Kurc es el director ejecutivo). Su precio se basa en la cantidad de servicios para los que se calculan los SLO en un sistema. Una empresa mediana puede tener un par de cientos de servicios; empresas más grandes por miles. La escala de precios se basa en eso, así como si la infraestructura está en la nube o en las instalaciones.
Los primeros clientes incluyen Adobe y Brex, una organización de servicios financieros con sede en San Francisco.
“Los conceptos son tan sencillos que no es necesario ser tan sofisticado para querer pasar al uso de SLO”, dice. “La sofisticación viene al destilar este concepto. Es muy simple y al aplicarlo a su propia arquitectura, cree que un cliente típico podría tener un sistema de monitoreo para VMware que están ejecutando y otro que están ejecutando para su infraestructura en la nube y luego otro que están ejecutando para algún legado. cosas en las instalaciones. Luego, algunas de las cosas viven en archivos de registro en algún lugar. El truco es obtener una vista holística y usar SLO en todo eso requiere una plataforma que se haya creado para ese caso de uso ".
La clave para los SLO es una métrica llamada presupuesto de error. Los SLO no controlan aspectos como el consumo de CPU o la memoria disponible; en su lugar, se basan en presupuestos de errores, lo que ofrece a los administradores una forma de medir la fiabilidad.
Si su objetivo de confiabilidad para la disponibilidad de un sistema es del 99,9 por ciento, su presupuesto de error es de ese 0,1 por ciento”, dice Singer. “Lo pensamos en términos de gastar ese presupuesto de error durante un período de tiempo. Si no es confiable al 0.1 por ciento durante un período de 30 días, en realidad lo ha hecho perfectamente bien en muchas situaciones. Eso le permite tomar acciones muy específicas en función de la rapidez con la que consume ese presupuesto de error. Pero si, de repente, lo estoy consumiendo cinco veces más rápido de lo que esperaba, entonces probablemente quiera que un desarrollador lo mire de inmediato solo en función de la tasa de consumo de ese presupuesto de error. Si el presupuesto de error se está quemando demasiado rápido, si nos vamos a quedar sin presupuesto, entonces es un problema ".
Nobl9, la parte "Nobl" del nombre es un guiño a los gases nobles, los gases más estables y confiables, está entrando en un mercado de observabilidad más amplio que incluye algunos actores establecidos, incluidos Splunk, Sumo Logic, AppDynamics y Dynatrace, así como startups como Honeycomb, que se lanzó en 2016 y a principios de febrero anunció una ronda de Serie B de $ 20 millones, lo que eleva el monto total recaudado a $ 46,9 millones. Esta semana lanzó Refinery, cuyo objetivo es ayudar a las empresas a mejorar sus datos de observabilidad a escala. Y ahora, puede convertir su sistema y los administradores de bases de datos y aplicaciones en una especie de SRE virtual con la ayuda del software.
Gracias por visitar este sitio, espero que te haya gustado y vuelvas proximamente, compartela en las redes sociales, gracias
Fecha actualización el 2021-03-16. Fecha publicación el 2021-03-16. Categoría: google Autor: Oscar olg Mapa del sitio Fuente: nextplatform