Que es DevOps (y que no es)

En esta nota vamos a abordar una tendencia actual que seguramente hayas escuchado o leído. Redactamos esta nota para aclarar un poco DevOps desde el negocio y no desde el lado de las herramientas, softwares u otros componentes de tecnología. Hoy en dia DevOps se encuentra en boca de mucha gente, lo que es beneficioso para expandir el concepto pero que trae consigo ciertos riesgos respecto a que es realmente . Es muy común escuchar errores tales como “DevOps es Agile” (o lo reemplaza), “hay que armar un grupo exclusivo”, y muchos otros errores de comunicación y de concepto.

Empecemos por los principales NO.

DevOps no es una metodología. No existen reglas o métodos a seguir que de forma sistemática o estandarizada nos ayuden a implementar DevOps.

DevOps no es una política que puede implantarse de forma forzada o imponerse. El movimiento DevOps es una cultura y como tal deben ser los departamentos de IT quienes adopten la nueva forma de trabajo. En cada proyecto que llevamos a cabo nos gusta resaltar que no existe una forma standard de llevar a cabo DevOps, porque lo que en una empresa funciona, en otra no.

DevOps resuelve problemas de tecnología. Este error de concepto muchas veces nos hace creer que DevOps significa implementar ciertas herramientas y fin del tema. DevOps tiene como funcionalidad principal ayudar al negocio; los procesos, cambios culturales y cambios tecnológicos son un derivado de los cambios que el negocio impulsa para ser mas óptimos.

Entonces… Que es DevOps?

Es un cambio Cultural que impacta de lleno en las personas, la plataforma y el producto. El principal beneficio es la reducción del time-to-market, o dicho de otra forma, nos permita lanzar productos al mercado de manera mas rápida o modificar un producto existente en tiempos mucho mas cortos.

Logra empatizar los equipos de trabajo. Es muy común que los empleados de un sector del negocio de una compañía mire con ciertos recelos al personal de IT, como así también es habitual los duelos entre los departamentos de Desarrollo y los de Operaciones principalmente porque  los objetivos de uno u otro grupo suelen ser contrarios entre si. Para ponerlo en ejemplos, el objetivo de un sector de marketing suele perseguir adaptarse al mercado en búsqueda de nuevos clientes o nuevas opciones para los clientes existentes, eso genera en el departamento de desarrollo el objetivo de entender, crear (o modificar) el sistema alineándolo con proyectos o releases en curso y finalmente el sector de Operaciones que tiene como misión asegurar la disponibilidad lo que genera que entre 3 sectores alinear un objetivo sea extremadamente difícil. Mediante DevOps, se hace mas fluida la comunicación, se logra fomentar la confianza entre los grupos de trabajo y con ese puntapié efectuar los cambios que logren alinear un objetivo de 3 departamentos con un fin en común.

DevOps, se trata de las personas. Se trata de conseguir productos mas flexibles, orientados a las necesidades del negocio y que acompañen los ritmos cambiantes del mercado.

En próximas notas vamos a contarles de que manera estamos trabajando con algunos de nuestros clientes. Si necesitas mas información, ponete en contacto con nosotros.

 

[contact-form-7 404 "Not Found"]

[quotcoll orderby=”random” limit=1]

Ambientes de desarrollo baratos y ágiles con Vagrant

Ambientes de desarrollo baratos y ágiles con Vagrant

En otras entradas hemos mencionado Docker una herramienta de containers que se esta volviendo una tendencia en todas las empresas que realizan desarrollos.

Resultado de imagen para Vagrant

En este post vamos a hacer una reseña de Vagrant, una herramienta de creación de entornos de desarrollo pensada originalmente como complemento de Virtualbox.

En la actualidad Vagrant puede ser ejecutado en Virtualbox, pero también en Vmware, HyperV, Docker, AWS, GCP, etc.

Pero que es Vagrant? Es una forma de tener containers que nos permitan tener ambientes de desarrollos, pero de una forma agil y barata.

En caso de que un desarrollador necesita trabajar sobre un ambiente para una aplicación web, requiere contar con un servidor web (Apache, Nginx, IIS, Etc), sus dependencias como Frameworks, Application servers, etc y ademas los motores de base de datos. Vagrant reemplaza la necesidad de instalar cada componente ofreciéndonos enlatados que contienen todo lo necesario para que lo unico que haya que hacer es sentarse a desarrollar.

El concepto de container de Vagrant es llamado Boxes, cada uno de estas cajas contienen los mencionados enlatados preconfigurados listos para ser descargados y usados. Desde el sitio web del producto se accede a un ‘market‘ donde se encuentran listados todos los modelos disponibles para bajar y usar en la herramienta.

Boxes

Una vez bajado el template y aplicado en el Hypervisor elegido, resta redireccionar los puertos (Vagrant funciona haciendo port forwarding) y empezar a trabajar.

Es realmente muy simple y existe extensa documentación oficial como infinidad de tutoriales en ingles y español en la web. En geekytheory.com existe una nota muy buena sobre la instalación de Vagrant sobre Virtualbox para que quienes están conociendo este tipo de tecnologías puedan comenzar a trabajar y ganar experiencia.

Es importante resaltar que la herramienta nació como un proyecto libre de la empresa HashiCorp, que ademas de tener software libre tiene versiones comerciales orientados a resolver problemas de desarrollo, operaciones y seguridad de la infraestructura para que las organizaciones puedan concentrarse en tareas críticas para su negocio.

Realmente vale la pena probar esta herramienta por lo tanto esperamos que este post haya sido de utilidad para nuestros lectores.

Para mas información sobre soluciones de tipo DevOps pueden escribirnos.

[contact-form-7 404 "Not Found"]

[quotcoll orderby=”random” limit=1]

Aplicando DevOps en las empresas

Venimos implementando DevOps en compañías de diferentes portes, hemos mencionado este tema en otra nota acerca de los paradigmas del desarrollo de software, pero en esta puntualmente vamos a explicar que es y que beneficios tiene para una empresa la cultura DevOps.

DevOps es la implementación de un mecanismo de conjunción entre los sectores de Desarrollo y Operaciones. El mecanismo incluye un cambio cultural y un cambio en la forma de entregar los diferentes ambientes necesarios para la creación de un software y/o aplicación.

Erróneamente al pensamiento general, DevOps no solo debe ser implementado en empresas puramente de desarrollo de software, sino que aplica perfectamente en todo tipo de compañías que tienen muchos releases frecuentes.

El objetivo principal que persigue una organización que implementa DevOps es la de construir un negocio ágil, con una entrega continua de productos y servicios que cumplan las necesidades de sus clientes.

En esta infografia se resume visualmente el concepto:

[contact-form-7 404 "Not Found"]

[quotcoll orderby=”random” limit=1]

Guardar

Cambiando el paradigma en el desarrollo de software

Cambiando el paradigma en el desarrollo de software

Existen nuevas tendencias en lo que hace al desarrollo de software. Nuevas términos como DevOps, Continuous Delivery, Continuous Deployment o Continuous Integration entre otros son cada vez mas habituales en las empresas.

Este grafico representa bien la diferente entre Continuous Delivery y Continuous Deployment:

Cabe destacar que el Continuous Delivery es la evolución de Continuos Integration.

La base de la integración continua es obtener las fuentes desde los versionadores como Git/CVS, compilarlo y realizar las pruebas que hagan falta, todo de forma automatizada con herramientas como Jenkins, para luego ser compilado con (por ejemplo) Maven.
En el Continuous Delivery no necesariamente hay que hacer pasajes a producción, los pasajes a producción se deciden de forma planificada con los sectores de negocio, pero cuando se decida hacer el pasaje a producción el mismo debe realizarse en poco tiempo. Y vale la aclaración: “Continuous Delivery no es Continuous Deployment”. De manera que podemos resumir Continuos Delivery como una forma de construir software de forma separada a la operación pero dejando el código del software siempre listo para ser puesto en producción.

Algo importante al hablar de Entrega Continua es que la visión general al hablar de cambios de paradigma es netamente técnica, y en realidad para poder cambiar una organización debe considerarse un fuerte apoyo ejecutivo y debe ir acompañado de cambios culturales que afectan tanto a los sectores tecnicos como a los de negocios.

Continuous Delivery ayuda a hacer las empresas más eficientes, ayuda a fomentar una cultura de equipo profesional y de alto rendimiento.

Residuos de la empresa tradicional

Procesos lentos, propensos a errores y ejecutados manuales. Le es familiar? Cuando usted libera un gran número de cambios y arreglos de una sola vez, el go-live esta predestinado a ser estresante y a menudo seguido de días (o semanas) de tareas de emergencia post-liberación.
Como cambiar esto?
Es necesario examinar el flujo del desarrollo del software. Entender cada paso en el proceso que es costoso, que es una perdida de tiempo o que en muchos casos es propenso a errores. Una vez relevado cada paso, es necesario eliminar, automatizar y acelerar cada punto hasta que se pueda poner en marcha un proceso rápido, rentable y fiable. Esta transición es basada en las prácticas y principios de la Entrega Continua.

Como puede ayudarlo SGIT?

En una organización tradicional, el conjunto de ambientes disponibles es fija: Desarrollo, prueba, UAT, QA y producción.
Los servidores son mantenidos por sectores de operaciones, y los cambios de configuración se aplican manualmente a través de un proceso de solicitud de cambio formal. Adicionalmente ante una nueva solicitud de equipamiento para una nueva máquina puede tomar semanas o incluso meses, ya que los equipamientos necesitan ser instalados en el centro de datos, con todos los costos burocráticos que eso implica.Con la entrega continua, no existe el concepto de un conjunto fijo de entornos (se crean y se destruyen al vuelo, según sea necesario).SGIT tiene experiencia implementando Entornos on Demand para el rápido aprovisionamiento de un nuevo ambiente basado en plantillas que puede ser generado automáticamente a través de una consola o portal de autoservicio. Las nuevas máquinas virtuales están listas para su uso en cuestión de minutos, y se pueden destruir automáticamente cuando ya no sean necesarias para optimizar la maximización de la eficiencia de recursos y la relación costo/beneficio.El middleware en cada máquina se instala automáticamente y configurado, y diversos conjuntos de datos están disponibles para bases de datos, incluyendo snapshots enmascarados de la base de datos de producción. Esto permite a los equipos reproducir de forma rápida y fiable entornos de producción para probar nuevas funciones o llevar a cabo las pruebas.Toda esta plataforma es considerada “Plataforma de Acceso Cero” ya que a diferencia de la infraestructura de TI tradicional que se maneja manualmente a través del sector de Operaciones, en este caso la infraestructura de TI se gestiona mediante una clara política de “no intervención”. Ni a los desarrolladores ni a los administradores se les concede el acceso de inicio de sesión a las máquinas, excepto en emergencias de producción.

Esto fue una breve reseña de nuevas tendencias en referencia al desarrollo de software. Para mas información pueden contactarnos.

[contact-form-7 404 "Not Found"]

[quotcoll orderby=”random” limit=1]

Guardar

Guardar

Containers vs Virtual Machines

¿Cuál es la diferencia entre los contenedores y virtualización basada en Hipervisores?
El concepto de contenedor no es nuevo. Desde hace muchos años existe la creación de contenedores en sistemas corriendo Solaris, HP-UX o AIX. Ahora parece que la contenerización sobre Linux llego para quedarse a partir de buenas herramientas como Docker o RKT.

Containers

Para diferenciar ambos modelos de virtualización podemos aclarar que en un entorno virtual se debe instalar un servidor físico con un hypervisor, que dentro contendrá máquinas virtuales cada una con su sistema operativo corriendo.

En el caso de un entorno mediante contenedores, el servidor físico ejecuta un solo sistema operativo que será compartido con la cantidad de containers creados. Cada container hace uso del núcleo compartido del sistema con modalidad de “solo lectura”.

¿Qué beneficios conlleva compartir el núcleo de un solo sistema?
En la práctica los contenedores son más livianos, fáciles de administrar y consumen menos recursos que una vm.

Mientras que un container solamente lleva instalado sus aplicaciones particulares, una virtual machine lleva encima todo un sistema operativo instalado.

De esa manera, en un equipo físico se pueden agrupar muchos más contenedores que máquinas virtuales.

A nivel funcional, usar contenedores permite mucha flexibilidad para el escalamiento de recursos, y por otro lado la administración se ve simplicada al tener en un solo kernel toda la plataforma de software de base, dependencias y demás componentes.

¿Los contenedores tienen puntos en contra?
La respuesta es sí. Para cada solución que se busque se debe analizar que conviene. Mientras que para algunos entornos es más apropiado un container, en otros casos la vm es lo apropiado.

Los contenedores suelen tener asociada la impresión de que ante una falla en el sistema operativo host, todos los contenedores se ven afectados, lo que es una realidad. A nivel seguridad en caso de verse comprometido un único sistema operativo, se vería afectado la totalidad de los containers.

 

De todos modos, los containers existen hace mucho tiempo y tienen larga vida por delante. Muchos artículos suelen enfrentar la tecnología de containers contra la tecnología de virtualización sobre hipervisores. En nuestro modo de ver, creemos que no son competencia sino más bien un complemento uno de otro y que incluso podrían optarse por tener ambientes mixtos.

Por mencionar el caso, Microsoft anuncio que la versión de Hyper-V disponible a partir de Windows Server 2016 permitirá la creación de containers, lo que es un claro mensaje que ambas tecnologías pueden convivir y entre ambas poder brindar soluciones a necesidades cada día más complejas.

 

www.sgit.tech

[quotcoll orderby=”random” limit=1]