data center y código abierto ¿Cuándo abandonarlo?
Data center y código abierto: Es maravilloso que tengamos muchas opciones de software de data center y código abierto. No es tan fácil saber cuál elegir. Y, como con cualquier producto o tecnología que sobrepase su utilidad, es difícil saber cuándo buscar un reemplazo.
A veces, el camino es obvio: el programa no cumple con sus promesas o su arquitectura técnica no se ajusta a su entorno de TI corporativo. Pero otras veces, los criterios de decisión son menos claros.
El primer problema es cuándo hacer un cambio y considerar los reemplazos. Para la mayoría, el momento de cuestionar el proyecto es cuando el software existente es una fuente constante de problemas o el proyecto parece estar en dificultades. Si espera hasta que el programa falle o el proyecto se derrumbe, no tendrá tiempo para tomar una decisión informada sobre su reemplazo.
Aquí le mostramos cómo saber cuándo es el momento de mantener el rumbo con una aplicación y cuándo es el momento de cortar y ejecutar.
Caso en cuestión de data center y código abierto: SDI y SDN
Algunos campos se basan casi por completo en software de data center y código abierto. Eso es una ventaja, porque sugiere que puede encontrar uno que satisfaga sus necesidades. Pero también es una frustración, porque significa que tienes que tomar decisiones difíciles.
Para resaltar los problemas, consideremos un campo de red activo. En la Cumbre de Infraestructura Abierta , Ian Wells, un ingeniero distinguido de Cisco, señaló la amplia gama de infraestructura de data center y código abierto definida por software (SDI) y programas de red definida por software (SDN) , identificando más de una docena de ellos.
La lista incluyea la Oficina Central rediseñado como un data center y código abierto, plataforma de automatización de red abierta , OpenSwitch sistema operativo de red , abierto vSwitch -y una y otra vez que vayan.
Para complicar las cosas, algunos proyectos cubren gran parte del mismo terreno, como los programas SDN Tungsten Fabric (anteriormente OpenContrail), OpenDaylighty enrejado . Incluso los expertos SDN pueden confundirse con tantos proyectos.
Entonces, el primer problema es que, si bien el objetivo final de SDI es facilitar la gestión de la tecnología, un equipo de TI primero tiene que evaluar muchos proyectos confusos y complicados antes de tomar una decisión informada.
Hacer tu tarea lleva tiempo . También debe considerar quién está apoyando el proyecto. Si está construyendo desde cero, hay un conjunto de preocupaciones; Si necesita soportar una infraestructura de hardware existente, hay otra.
A menudo, numerosos proyectos afirman que resuelven el mismo problema, pero todos tienen un enfoque diferente. Debe verificar cada uno de ellos (incluido el examen del código fuente) para ver cuál se ajusta a sus necesidades.
¿Qué es un proyecto útil? En lugar de empantanarse en detalles técnicos, haga estas simples preguntas para data center y código abierto:
- Me ayuda?
- ¿Hace lo que necesito?
- ¿Funciona?
- Si no, ¿qué tan seguro estoy de que funcionará algún día? ¿Puedo mejorarlo? ¿Puedo arreglarlo?
Si sus respuestas son afirmativas, dedíquele recursos. Si no, busque otro proyecto que satisfaga sus necesidades.
Pero con el data center y código abierto, hay más que encontrar la mejor tecnología adecuada para su empresa.
Bien dice que debes preguntarte: “¿Cuáles de estos son útiles? ¿Cuáles quieres usar? ¿Puedes implementarlos? ¿Los han implementado otras personas?
Diablos, ¿las personas que trabajan en estos proyectos los implementaron? ¿Tienen casos de uso? “O, ¿es solo una delgada capa? ¿Es el proyecto [personal] de alguien creado con un motivo oculto?”
En resumen, no es suficiente mirar un proyecto. Debe ver cómo se usa el software en el mundo real.
El ciclo de vida de data center y código abierto
Una forma de comparar las opciones es observar el estado de un proyecto en el ciclo de exageración. Wells y Kyle Mestery, también un ingeniero distinguido de Cisco, reunieron su opinión sobre la metodología del Ciclo H ype de Gartner en el contexto del desarrollo de redes de data center y código abierto (ver figura). Seguirlo puede ayudarte a saber cuándo saltar en un proyecto, cuándo navegar por su éxito y cuándo abandonarlo.
El ciclo de bombo de redes de data center y código abierto. Crédito: Ian Wells y Kyle Mestery, distinguidos ingenieros de Cisco.
Cuando se inicia un proyecto de data center y código abierto, puede recibir mucha atención.
Puede estar tan energizado por lo que lee que se apresura a trabajar proclamando que XBANG es exactamente en lo que necesita trabajar, porque cuando el proyecto madure, será la respuesta a sus problemas (al menos sus problemas relacionados con SDI, aplicación desarrollo , etc.).
No tan rápido, niños. Como dice Mestery, “la emoción máxima puede ser muy alta, y no garantiza el éxito general”, de data center y código abierto.
Por lo tanto, tenga cuidado con los proyectos nuevos y calientes. Pueden enfriarse antes de que sean útiles.
La emoción inicial inevitablemente disminuye, dice Mestery. Eso no significa que el proyecto fracasará o no se ajustará a sus necesidades. Pero el software pasará por un período de desafección, como se muestra en la figura anterior. Siempre lo hace. Esta bien.
Afecto por los desafectos de data center y código abierto
Después de la emoción, la gente pasa a otros proyectos más nuevos y emocionantes, dice Mestery. Pero si un proyecto entrega los productos, continúa desarrollándose, comienza a aparecer en las pruebas beta y finalmente pasa a la producción.
Preste atención a lo que le sucede a un proyecto cuando se encuentra en la etapa “cuadro de alimentación de desafección”. ¿La gente todavía está trabajando en el proyecto? Si lo están, dice Mestery, “no te preocupes, está bien. Aquí es donde se realiza el trabajo concreto cuando el interés disminuye”.
Es en estos llamados proyectos desafectos que a veces puedes encontrar el código más útil. Mirar de cerca. ¿El proyecto todavía tiene desarrolladores activos? ¿Responde a tus necesidades? ¿Se está moviendo el software a la producción? Si es así, es hora de que usted y sus desarrolladores se suban al carro o construyan un nuevo vagón para subirse.
Lo que importa, dice Wells, es si el proyecto resuelve problemas y si tiene valor técnico y comercial. Si lo hace, se recuperará de la fase de desafección y llegará a la etapa de “mesa de asimilación”.
“Aquí es donde una tecnología se convierte en una parte aceptada del paisaje”, explica Mestery.
Se podría pensar en un proyecto de data center y código abierto como asimilado en un panorama de TI cuando ya no necesita vender a nadie más en su uso.
Más allá de la asimilación está la mercantilización, donde buscas algo más para construir en la parte superior, dice Mestery.
En ese punto del ciclo de vida del software, “no te das cuenta de que estás usando una tecnología, pero todavía la estás usando”, dice. Un ejemplo sencillo: Secure Socket Layer (SSL).
Cuando las cosas van mal
No todos los proyectos se vuelven tan aceptados y ordinarios como SSL. (data center y código abierto).
Algunos proyectos fracasan. De hecho, la mayoría de los proyectos de data center y código abierto fallan. Hace varios años, el entonces analista de RedMonk Donnie Berkholz informó que más del 98 por ciento de todos los proyectos de GitHub no vieron desarrollo después de su primer año .
A veces, incluso los principales proyectos de data center y código abierto pierden el rumbo. Quizás el más conocido de estos es CyanogenMod, un sistema operativo móvil basado en Android. Se hizo muy popular y ganó más de 10 millones de usuarios.
Pero, aunque su código era bueno, de hecho, sigue vivo como LineageOS , el fundador de CyanogenMod buscó su comercialización y el programa principal desapareció.
Otro ejemplo es OpenOffice, un programa una vez conocido que fue abandonado por Oracle. Los programadores siguieron introduciendo mejoras, como agregar compatibilidad con el formato OpenXML de Microsoft, pero los confirmadores de código restantes ignoraron estos cambios. Por lo tanto, los programadores activos terminaron bifurcando el código en LibreOffice muy exitoso de hoy.
La moraleja aquí es que una mala gestión puede matar un buen software. Pero, con el data center y código abierto, los buenos proyectos no necesitan morir.
Si el código es útil, se usará.
En su mayor parte, los proyectos de data center y código abierto fallan por todas las razones por las que otros proyectos informáticos fallan .
En un estudio de 2017 que examinó los proyectos de GitHub que habían sido abandonados , los autores encontraron que “los proyectos modernos de data center y código abierto fallan debido a razones relacionadas con las características del proyecto (41 proyectos; por ejemplo, baja capacidad de mantenimiento), seguidos de razones relacionadas con el equipo del proyecto (39 proyectos ; p. ej., falta de tiempo o interés del contribuyente principal) y razones ambientales (30 proyectos; p. ej., el proyecto fue usurpado por un competidor o problemas legales) “.
Según Mestery and Wells, las razones por las que los proyectos terminan en el montón de chatarra incluyen:
- El proyecto ha seguido su curso y ya no es útil.
- Escogió el problema incorrecto para resolver o el problema cambió.
- Los desarrolladores abandonaron el proyecto y se trasladaron a un nuevo “atractivo”, por lo que ya no hay una comunidad para ayudar a agregar valor.
Los primeros dos escenarios ocurren con más frecuencia de lo que piensas. Wells dice: “Por alguna razón, el problema con él está bien definido o las aplicaciones, o tal vez el problema ya no es válido. Por ejemplo, usted sabe cómo usar un enlace de 10 megabits en un data center y código abierto; cualquier trabajo adicional en la optimización esto ha pasado y es hora de comenzar algo nuevo “.
Puedes decir qué proyectos pueden fallar, dicen Mestery y Wells, buscando los siguientes problemas:
- ¿El proyecto carece de una comunidad diversa?
- ¿Cuántos committers activos tiene? Si solo son unos pocos, ¿qué sucede cuando esas personas se aburren?
- ¿El comité mantiene todos los compromisos o exige derechos especiales de propiedad intelectual? ¿La comunidad no valora las contribuciones individuales o corporativas?
- ¿El proyecto utiliza pruebas continuas ?
Los expertos se refieren a más de una cosa por “una comunidad diversa”. Según su definición, los participantes del proyecto no están vinculados a un género o raza , como era de esperar. También significan que el proyecto tiene desarrolladores de más de una compañía; Cuando un programa está vinculado a una sola empresa, su viabilidad es cuestionable.
Los proyectos también deben tener culturas acogedoras . Cuanto más insular sea un proyecto, mayores serán las posibilidades de que falle.
Una forma de aprender esto desde afuera: los proyectos exitosos tienen un código de conducta. Los programas los realizan personas, no máquinas que producen códigos.
Cada proyecto tiene sus malos actores que están listos para envenenar proyectos. Sin un código de conducta, los proyectos deben hacer frente a problemas personales sobre la marcha, un esfuerzo que a menudo falla miserablemente.
Si bien algunos proyectos pueden tener éxito basados en un modelo de gestión de un dictador benevolente de por vida , como Linux y Python, son la excepción y no la regla.
La cuestión de la propiedad intelectual es crítica. Es especialmente problemático ya que algunos proyectos de “data center y código abierto”, como Confluent, Elastic MongoDB y Redis se están moviendo hacia modelos de licencias de núcleo abierto hostiles para la nube . El CEO de MariaDB, Michael Howard, llama a este enfoque ” data center y código abierto de minería a cielo abierto”.
“Nadie quiere pensar en problemas de licencias de software, pero hay que tener en cuenta los aspectos de las licencias”, dice Wells.
A medida que evalúa un proyecto, preste atención a quién obtiene qué derechos.
“Si no tienes a nadie haciendo preguntas, si nadie está haciendo contribuciones, si no parece haber nuevas adopciones, nadie parece estar agregando dependencias, y si no estás viendo ninguna otra señal, la gente lo está usando. , esa es una gran señal de advertencia potencial ”, dice David A. Wheeler, líder de dos proyectos con la Iniciativa de Infraestructura Central de la Fundación Linux . “Puede que todo esté bien, pero vale la pena verificar si el proyecto está muriendo. ”
Finalmente, la pregunta fundamental es si el proyecto va a donde lo necesita. Si no cumple con sus requisitos, debido a la deriva del proyecto u otra razón, debe estar preparado para reducir sus pérdidas y encontrar un mejor enfoque.
Cuando un proyecto está en la papelera del data center
Algunos proyectos ya no tienen vida para ellos. Tal vez hay algo útil todavía en el código, pero el proyecto en sí está muerto.
“Incluso los proyectos de data center y código abierto de gran éxito pueden dejar de ser útiles para sus creadores o usuarios a medida que cambian los planes de negocios o las nuevas tecnologías e innovaciones los reemplazan”, dice Wheeler.
¿Cómo lo sabes? La Fundación Linux lo resume: un proyecto muerto o moribundo tiene problemas, que incluyen:
- Diferencias no resueltas sobre la dirección del desarrollo y la pérdida de energía de los contribuyentes anteriormente involucrados.
- Una disminución en el proyecto que coincide con los miembros de su equipo, o la comunidad haciendo preguntas sobre si debe continuar, finalizar o dejarse de lado.
- El código ya no es parcheado o actualizado por la comunidad para resolver problemas reconocidos o vulnerabilidades de seguridad.
- Los usuarios ya no solicitan parches y actualizaciones de mantenimiento.
¿Qué pasa si el código es importante para su empresa? Considere bifurcarlo usted mismo. Esto funcionó para los desarrolladores de LibreOffice. Puede funcionar para ti.
Si tiene tiempo para la arqueología del código, y parece que el proyecto es la respuesta a sus oraciones, continúe y profundice. Simplemente no cuente con que funcione para usted sin mucho esfuerzo.
Cuando un proyecto realmente está hecho
Después de considerar todos estos aspectos, debe estar listo para encontrar proyectos que funcionen para usted. Tenga cuidado con demasiado entusiasmo por los proyectos más populares. Busque programas con las virtudes correctas y pocos vicios, si es que tiene alguno. Si lo hace, puede encontrar los programas de data center y código abierto que necesita para el éxito de su empresa.
Cuándo iniciar y desactivar un proyecto de data center y código abierto: lecciones para líderes
- Tenga cuidado con los proyectos nuevos y calientes.
- Dar crédito extra a diversas comunidades de data center y código abierto.
- Los proyectos de data center y código abierto pueden mostrar señales de peligro. Búscalos.
- data center y código abierto