Al solicitar un trabajo, por lo general, puede encontrar dos tipos de trabajos similares: Sysadmin Engineer e DevOps Engineer .
Ambos se ocupan de la configuración del servidor y garantizan el funcionamiento confiable de los sistemas informáticos. Puede ser difícil distinguir la diferencia entre los dos. ¿Cuáles son las principales diferencias entre ellos?
terminology
kenorb
fuente
fuente
Respuestas:
Principalmente DevOps no es un rol (cuando se usa como tal es más una palabra de moda que un rol real).
DevOps es más o menos un patrón de organización que tiene como objetivo romper el silo entre desarrolladores y administradores de sistemas.
El objetivo principal es crear equipos con desarrolladores y administradores de sistemas (junto con los probadores generalmente) responsables de un producto (aplicación) desde su definición, decisiones de arquitectura hasta el mantenimiento en funcionamiento de este producto.
Cada miembro del equipo será parte de la decisión sobre el ciclo de vida completo del producto, un desarrollador realizará algunas tareas de administrador de sistemas en la producción y un administrador de sistemas participará en la fase de diseño del producto para evitar advertencias desde la perspectiva de la infraestructura por ejemplo.
En el ideal, un administrador del sistema también sería parte del equipo de desarrollo del producto, en el código del administrador del sistema real más sobre la configuración del producto y las soluciones de monitoreo, pero ser capaz de expresar sus preocupaciones a otros miembros del equipo para evitar muchos malentendidos. en el proceso de implementación.
fuente
Version corta
DevOps combina una cultura organizacional, formas de trabajo ágiles / lean y automatización de software que, cuando se aplica a la Administración y Operaciones de Sistemas, permite que estas funciones operen con el mismo nivel de Agilidad que los Equipos de Desarrollo Agile o Lean.
Versión larga
Las ideas detrás de DevOps surgieron de las comunidades de Administración de Sistemas, Operaciones y Ágil, específicamente, Patrick Debois dio una presentación en Agile2008 titulada 'Infraestructura ágil' donde destacó la disparidad entre la forma en que operan las tres funciones dentro de una organización:
La propuesta de Debois era unificar las tres formas de trabajar juntos, moviendo específicamente los equipos de Administración de Sistemas y los equipos de Operaciones de un Modelo de Cascada a un Modelo Ágil. Con ese fin, Debois configuró DevOpsDays 2009 en Gante, Bélgica, inadvertidamente acuñando la frase DevOps .
La idea de DevOps resonó con los Autores de la serie de libros VisibleOps: Gene Kim, George Spafford y Kevin Behr; quien escribió The Phoenix Project y The DevOps Handbook . Ambos libros exploran cómo Agile y Lean pueden impactar positivamente en los equipos de Administración y Operaciones de Sistemas.
fuente
Como ingeniero de DevOps con experiencia en operaciones, habrá pasado de construir e implementar servidores y software manualmente a crear scripts para la instalación de software en sus servidores con BASH, PowerShell, Python, etc. Después de un tiempo, se dará cuenta de cómo Los scripts geniales son y comienzan a explorar formas más sofisticadas para automatizar la implementación .
Eventualmente, se habría decidido por un Chef, Puppet, Ansible u otra herramienta de administración de configuración para ayudar a administrar el estado de su flota de sistemas. A medida que maduraron sus habilidades con la automatización de la implementación de aplicaciones y la administración del sistema, junto con sus herramientas, más recientemente se mudó al ámbito de ' Infraestructura como código ' y lo usó no solo para automatizar la implementación de software sino también la infraestructura y los entornos requeridos para conducir el software durante el cambio del negocio a la nube.
Ahora estás cocinando con gas. Con el tiempo, se le han presentado los beneficios del uso de herramientas centradas en el desarrollador, como el control de código fuente, para administrar los módulos, recetas y plantillas que conforman su arsenal de herramientas de implementación y administración.
Cuando ingresó al equipo de DevOps , estuvo expuesto al ciclo de vida de desarrollo de software y al concepto de integración continua . ¡Vaya, esos desarrolladores lanzaron cambios rápidamente y para mantenerte al día te encontraste trabajando más estrechamente con los desarrolladores! Experimentó la urgencia puesta en el equipo de desarrollo para cambiar las cosas TODO EL TIEMPO, lo que contradice el viejo paradigma operativo de " si no está roto, no lo arregle ". No más alardear sobre el tiempo de actividad del sistema, ya está en la infraestructura desechable .
Notó que el cambio a DevOps fue más que trabajar con los desarrolladores o usar nuevas herramientas y técnicas , pero hubo un cambio cultural distinto en el equipo, uno que impregnaba la organización en general. Usted estaba trabajando como un equipo muy unido con responsabilidades compartidas , herramientas y objetivos compartidos .
Tomó sus habilidades en la implementación automatizada y las incorporó a la tubería " CICD " que está siendo orquestada por un " servidor de integración continua " como Jenkins , Bamboo o Code Pipeline . Ahora, cuando los desarrolladores introducen un nuevo código, sus scripts, herramientas y plantillas presentan nuevos entornos bajo demanda, activan marcos de prueba para hacer lo suyo y destruyen los entornos de preproducción después de que se encienden las luces verdes en el lanzamiento, adhiriéndose a la ideas de " entrega continua ".
A medida que el nuevo código se abre paso a través de las etapas de CICD, usted, los desarrolladores y la empresa confían en que la actualización no se romperá cuando se lance a producción. Hay un camino por recorrer antes de que el equipo llegue a un " despliegue continuo ", aún debe decidirse por los puntos más finos de automatizar la capacidad de despliegue azul / verde , y la decisión es principalmente de negocios. Por el momento, está contento de que la cantidad de llamadas a las 3 a. M. Haya disminuido y la disminución de sev-1 y sev-2.
Incluso si obtienes un sev-1, ya no estás tirando todas las noches con los gerentes respirando por tu espalda: puedes lanzar fácilmente la versión anterior a través de la tubería CICD y volver a poner el sistema en línea en poco tiempo. El negocio ha notado que la estabilidad de los sistemas de TI ha mejorado a pesar de la velocidad de los cambios .
Te maravilla la forma en que administras los recursos necesarios para impulsar el software en tu negocio, especialmente cuando piensas en cómo solía ser y la cantidad de sangre que dejaste en los rieles en el centro de datos ...
fuente
Sysadmin vs. DevOps (vista personal)
Algunas compañías hablan sobre Dev, Ops y Test. Si algo necesita ser probado, entonces dicen: "La prueba debería hacer eso". Si algo necesita ser desarrollado, Dev lo hará y si el software necesita ser implementado, Ops lo hará.
En mi opinión, y lo que he experimentado en varias compañías es que esto resulta en una mentalidad de "tirarlo por la pared" que resulta en fricción entre las personas y los equipos. Personalmente, a veces siento que las personas trabajan individualmente y dicen que esto es lo que hice, no tengo nada que hacer en lugar de trabajar en equipo.
Según mi opinión, DevOps significa que todos los miembros de un equipo son responsables y están ocupados con el desarrollo, las pruebas y las operaciones. No hay un yo en un equipo y no hay departamentos separados. Todos deberían liberar. Por supuesto que hay especialidades, pero en mi opinión todos deberían poder realizar al menos el 25% de algún trabajo en cada área. Por ejemplo, si alguien era un Desarrollador en ese momento, entonces uno debería poder cambiar algún código de administración de configuración, por ejemplo, chef e implementar software.
Referencias
Sysadmin
De acuerdo con Wikipedia :
DevOps
De acuerdo con Wikipedia :
DevOps
Cadena de herramientas DevOps
fuente
Un administrador del sistema es responsable de mantener y configurar los servidores y su responsabilidad es garantizar al usuario el rendimiento, el tiempo de actividad y la seguridad que está buscando. Definir el papel de un ingeniero DevOps es un poco más difícil ya que no existe una carrera profesional formal y DevOps en sí mismo puede tener muchas formas.
Un ingeniero de DevOps puede ser, por ejemplo, un desarrollador que esté interesado en las operaciones de red e implementación o un administrador del sistema que tenga pasión por la codificación y las secuencias de comandos. La transición del administrador del sistema al ingeniero de DevOps no es muy difícil; de hecho, este artículo hace un muy buen trabajo al describir el proceso.
Muchas personas incluso argumentarían que esta transición de administrador del sistema a ingeniero de DevOps es esencial ya que el puesto de administrador del sistema quedará obsoleto en el futuro. Aunque hay muchos servidores heredados que necesitan mantenimiento y los administradores del sistema poseen mucho "conocimiento tribal", la posición del administrador de sistemas será más escasa en el futuro.
fuente
Habrá servidores que no se oirán en los centros de datos. Todo va a ser software. Almacenamiento, red, sistemas, seguridad, centros de datos; SDN, firewalls, NFV, almacenamiento, servidores, etc. Los administradores de sistemas sin experiencia en desarrollo de software, experiencia SDLC (ni siquiera me refiero a scripts de Perl, Powershell, etc.) probablemente desaparecerán. Los entornos distribuidos, escalables y virtualizados, que en su mayoría son de nube, crecen horizontalmente, no verticalmente.
Me atrevo a decir que los administradores de sistemas crecen en vertical, DevOps (u OpsDev) crecen en horizontal. Puede ver el mismo patrón de cómo evolucionaron los microservicios a partir de monolitos. Preferiría elegir al ingeniero DevOps del equipo de software y no del equipo de operaciones / sistema.
Porque el equipo de operaciones / sistema solo ejecuta lo que el equipo de software construye.
Sysadmin comienza a funcionar después de que finaliza CI / Entrega continua / Implementación.
Y si interrumpe y asigna Implementación / Entrega, podría ser una tubería rota
el equipo de software es el creador del sistema / equipo de operaciones son los corredores / cuidadores en su mayoría.
Parece que no hay un servidor / sistema para administrar, no se necesita un administrador de sistemas.
La computación sin servidor es un modelo de ejecución de computación en la nube en el que el proveedor de la nube actúa como el servidor, administrando dinámicamente la asignación de recursos de la máquina. El precio se basa en la cantidad real de recursos consumidos por una aplicación, en lugar de en unidades de capacidad precompradas Computación sin servidor
Alguien del equipo de software ya sabe cómo construir, mantener incluso cómo codificar (SRE vs DevOps / OpsDev).
Me pregunto por qué se llama DevOps pero no OpsDev. ¿está relacionado con la dirección entre los dos?
* En el medio de la nada, no comencé a escribir sobre el almacenamiento definido por software, esto es en reacción a un comentario ahora eliminado al respecto *
Acerca del almacenamiento definido por software
El almacenamiento definido por software (SDS) es un término de marketing para el software de almacenamiento de datos informáticos para el aprovisionamiento basado en políticas y la gestión del almacenamiento de datos independiente del hardware subyacente. Almacenamiento definido por software
EMC anunció su primer producto de código abierto: Project CoprHD. CoprHD es un controlador de automatización y gestión de almacenamiento definido por software, y la reciente decisión de EMC de abrir el código es el meollo de nuestra estrategia para ofrecer un mayor valor a las empresas globales a medida que ingresamos en un área de crecimiento y cambio extremo. Como líder mundial en almacenamiento y gestión de la información, le corresponde a EMC liderar el camino en el almacenamiento definido por software (SDS) .
CoprHD es un controlador de almacenamiento de código abierto definido por software y una plataforma API. Permite la gestión basada en políticas y la automatización en la nube de los recursos de almacenamiento para los proveedores de almacenamiento de bloques, objetos y archivos CoprHD
fuente