El término “DevOps” se ha vuelto sin sentido y los desarrolladores aún no tienen acceso a las herramientas adecuadas para poner en práctica la idea general, argumenta el equipo detrás de la startup de DevOps, OpsLevel. La compañía, que fue cofundada por John Laban y Kenneth Rose, dos de los primeros empleados de PagerDuty, anunció hoy que ha recaudado una ronda de financiación inicial de $ 5 millones, liderada por Vertex Ventures. S28 Capital, Webb Investment Network y Union Capital también participaron en esta ronda, así como varios ángeles, incluidos los tres cofundadores de PagerDuty.
“[PagerDuty] fue una parte importante del movimiento DevOps. Poner a los ingenieros de guardia fue realmente importante para DevOps, pero estar de guardia y recibir avisos sobre incidentes y cosas, es de naturaleza muy reactiva. Se trata de solucionar los incidentes lo más rápido posible ”, dijo Laban. “Conocido [Rose] y vi una oportunidad para ayudar a las empresas a adoptar una postura más proactiva. Nadie realmente quiere tener tiempo de inactividad o brechas de seguridad en primer lugar. Quieren prevenirlos antes de que sucedan “.
Créditos de imagen: OpsLevel
class = “piano-inline-promo”>
Con esa misión en mente, el equipo se propuso llevar a las organizaciones de ingeniería de regreso a las raíces de DevOps dándoles a esos equipos la propiedad de sus servicios y creando lo que Rose llamó una cultura de “tú lo construyes, lo posees”. La propiedad del servicio, señaló, es algo con lo que el equipo ve regularmente a las empresas luchar. Cuando los equipos se trasladan a microservicios o incluso arquitecturas sin servidor para sus sistemas, rápidamente no queda claro quién es el propietario de qué y, como resultado, terminas con servicios huérfanos que nadie mantiene. El resultado natural de eso son problemas de seguridad y confiabilidad. Y al mismo tiempo, como nadie sabe qué sistemas ya existen, otros equipos reinventan la rueda y reconstruyen el mismo servicio para solucionar sus propios problemas.
“Hemos invertido poco en herramientas para que DevOps realmente funcione”, dice el equipo en el anuncio de hoy. “Todavía hay mucho que debemos desarrollar para ayudar a los equipos de ingeniería a adoptar la propiedad del servicio y desbloquear todo el poder de DevOps”.
Entonces, en el núcleo de OpsLevel está lo que el equipo llama una “plataforma de propiedad de servicios”, comenzando con un catálogo de los servicios que una organización de ingeniería está ejecutando actualmente.
Créditos de imagen: OpsLevel
“Lo que estamos tratando de hacer es recuperar el significado de DevOps”, dijo Laban. “Creemos que se ha vuelto insignificante y queríamos reenfocarlo en la propiedad del servicio. Vamos a invertir mucho en la construcción de nuestro producto y luego trabajar con nuestros clientes para que sean realmente dueños de sus servicios y se pongan realmente manos a la obra para resolver ese problema “.
Entre las empresas con las que OpsLevel ya está trabajando se encuentran Segment, Zapier, Convoy y Under Armour. Como señaló el equipo, su servicio se vuelve más útil una vez que una empresa ejecuta alrededor de 20 o 30 servicios diferentes. Antes de eso, una wiki u hoja de cálculo suele ser suficiente para administrarlos, pero en ese punto, esos sistemas tienden a fallar.
OpsLevel les brinda diferentes rampas de acceso para comenzar a catalogar sus servicios. Si prefieren usar un enfoque de “configuración como código”, pueden usar esos archivos YAML como parte de sus flujos de trabajo de Git existentes. Pero OpsLevel ofrece API que los equipos pueden conectar a sus diversos sistemas si ya tienen flujos de trabajo de creación de servicios existentes.
La ronda de financiación de la empresa se cerró a finales de septiembre. La pandemia, dijo el equipo, realmente no obstaculizó sus esfuerzos de recaudación de fondos, algo que he escuchado últimamente de muchas empresas (aunque las con las que hablo obviamente tienden a ser las que recientemente recaudaron dinero).
“La razón por la cual [we raised] es porque realmente queríamos invertir en la construcción de nuestro producto ”, dijo Laban. “Hemos tenido esta tracción con nuestros clientes y realmente queríamos duplicar y desarrollar una gran cantidad de productos e invertir en nuestro equipo de lanzamiento al mercado también y realmente queríamos acelerar las cosas”.
Source link