UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGÍA

DIRECCIÓN DE POSGRADO

“FUNDAMENTOS TÉCNICOS DE DEVOPS”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES VERSIÓN I

POSTULANTE : Neyber Guido Rojas Zapata

TUTOR : MSc. Richard Félix López Fulguera

Cochabamba – Bolivia
2018
 Tabla of Contenido
TABLA DE CUADROS, GRAFICOS Y FIGURAS 4

Resumen 5

Introducción 6

1 Generalidades 7

1.1 Antecedentes Generales 7

1.2 Antecedentes Específicos 8

2 Metodología 10

3 Conceptos importantes en el flujo de DevOps 12

3.1 Automatización de la Construcción (Build automation) 12

3.2 Integración Continua (Continuous integration) 14

3.3 Entregas Contínuas y Despliegues Continuos (Delivery and Deployment) 16

3.5 Infraestructura como Código (Infraestructure as code) 18

3.6 Gestión de Configuración (Configuration management) 19

3.7 Orquestación (Orchestration) 20

3.8 Monitoreo (Monitoring) 22

3.9 Microservicios (Microservices) 23

2
 3

4 Herramientas para DevOps y su integración en la nube 24

4.1 Herramientas para DevOps 24

4.1.1 Automatización de la construccción e Integración Contínua 26

4.1.2 Gestión de la Configuración (Configuration management) 27

4.1.3 Virtualización y Contenedores (Virtualization y containerization) 28

4.1.4 Monitoreo (Monitoring) 29

4.1.5 Orquestación (Orchestration) 30

4.2 Herramientas para DevOps en la nube 31

4.2.1 Google cloud platform 32

4.2.2 Microsoft azure 34

4.2.3 Amazon web services 36

5 Conclusiones y Recomendaciones 40

6 Bibliografía 41
 4

TABLA DE CUADROS, GRAFICOS Y FIGURAS

Descripción Pág.

Figura 1 – Flujo de DevOps 11

Figura 2 – Flujo de integración continua 14

Figura 3 – Flujo de entregas continuas 16

Figura 4 – Infraestructura como código 17

Figura 5 – Microservicios 21

Figura 6 – Tabla periódica de herramientas de DevOps 23

Figura 7 – Gestión de servicios en la nube 29

Figura 8 – Funcionalidades soportada en Google Cloud Platform 31

Figura 9 – Funcionalidades soportadas en Microsoft Azure 33

Figura 10 – Funcionalidades soportadas en AWS 35

 5

Resumen

En la presente monografía se explica los fundamentos técnicos de DevOps en cada uno de sus

procesos dentro el flujo, para poder tener claro todos los conceptos necesarios que deben ser

considerados en la cultura de DevOps y brindar el detalle de todas las herramientas necesarias que

son aplicadas a lo largo de todo el flujo. Se debe considerar que se ha tratado de mantener muchos

de los términos usados en el idioma ingles con el fin de estar mas familiarizados con la

nomenclatura utilizada en ese mundo de DevOps.

 6

Introducción

Hoy en día, no puede entenderse el desarrollo de aplicaciones de cualquier tipo sin un enfoque

alineado, donde las pruebas de concepto este controladas hasta el lanzamiento, pasando por el

testing y los entornos de prueba, todos los pasos involucrados requieren de la máxima agilidad

posible, y eso pasa por integrar los procesos y los equipos de programación con los de sistemas.

Es que ahí nace una práctica de ingeniería de software que tiene como objetivo unificar el

desarrollo de software (Dev) y la operación del software (Ops), esta práctica es conocida como

DevOps.

Es importante tener claro cada uno de estos procesos, esto ayudará a establecer un paradigma el

cual será capaz de favorecer en gran manera en cada una de las etapas iterativas del desarrollo de

software.
 7

1 Generalidades

1.1 Antecedentes Generales

¿Qué es DevOps?

Técnicamente Devops = Dev (Development) + Ops (Operations)

Hay cientos de definiciones de DevOps. Sin embargo, la idea base detrás de todas ellas es la

misma: la de una organización alineada e integrada que facilita la aceleración del ciclo de vida de

las aplicaciones. Por eso DevOps no es algo que se pueda comprar y ponerlo en marcha, implica

una actitud, unos tiempos y un soporte completamente nuevos.

Una breve historia de DevOps

DevOps surgió a partir del movimiento de desarrollo de software ágil, el cual busca desarrollar

software en ciclos pequeños y frecuentes para entregar funcionalidad a los clientes de manera

rápida, ya que los requerimientos son bastante cambiantes dado ciertos objetivos comerciales que

puede tener una compañía. Por esa razón se puede decir que DevOps y Agile suelen ir de la mano.

La línea de tiempo de DevOps

2007: el desarrollo de software ágil estaba ganando popularidad, pero también sufría una división

creciente entre el desarrollo y las operaciones.

2007: Patrick Debois, un ingeniero con experiencia en desarrollo y operaciones, estaba haciendo

pruebas en un proyecto y se sintió frustrado por la gran división entre desarrolladores y operadores.

2008: Patrick Debois y Andrew Shafer se encontraron en la conferencia Agile 2008 que se llevo a

cabo en Toronto, Canadá. Iniciaron ciertas conversaciones con el fin de buscar a más interesados

y lograr salvar esa brecha existente entre desarrolladores y operadores.

 8

2009: John Allspaw y Paul Hammond dieron una charla en Velocity Conference titulado: “10+

Despliegues por día: cooperación entre Dev y Ops en Flickr”. Patrick estaba mirando en vivo. La

gente comenzó a discutirlo a través de Twitter.

2009: Patrick organizó los primeros DevOpsDays en Ghent, Bélgica; una conferencia para

desarrolladores e ingenieros de operaciones. La conversación continuó en Twitter: #devops.

DevOps se convirtió en un movimiento orgánico de base en todo el mundo y generó muchas

herramientas para respaldar las practicas valoradas por DevOps.

Hoy en día, el movimiento de DevOps no ha dejado de crecer desde 2009, por lo que ya no es un

movimiento pequeño. Cambio por completo la industria de TI.

Cultura DevOps

La cultura de DevOps se basa en la colaboración existente entre desarrollo y operaciones. Antes

de la existencia de DevOps, los objetivos eran distintos, desarrollo se enfocaba en la velocidad de

entrega de funcionalidad y operaciones en la estabilidad del software, ahora con la ayuda de

DevOps ambos tienen los mismos objetivos.

Los roles tradicionales de los desarrolladores y los ingenieros operativos pueden incluso

difuminarse en DevOps. En lugar de generar código a diestra y siniestra, los desarrolladores y

operadores trabajan juntos para crear, usar herramientas y procesos que soportan tanto velocidad

como estabilidad.

1.2 Antecedentes Específicos

En la era tradicional, los desarrolladores escribían el código y este era enviado al equipo de control

de calidad, el código viajaba hacia adelante y hacia atrás, entre desarrolladores y control de calidad.
 9

Control de calidad descubría problemas y los desarrolladores lo arreglaban, y finalmente después

de muchas idas y venidas, estaba listo para producción.

Entonces, desarrollo y control de calidad enviaban el código a operaciones, donde se encontraban

sin fin de problemas con el código y operaciones devolvía el código para que desarrollo solucione

los problemas. Es así que el dominio de cada equipo era una caja negra para los otros equipos,

donde ningún equipo asumía cierta responsabilidad y es aquí donde surgían varias preguntas del

porque salió mal la puesta a producción, las cuales al ser analizadas para poder encontrar una

solución desembocan en cambiar la cultura en el ciclo de desarrollo, es decir, cultura DevOps.

Es aquí que la era tradicional termina y nace una nueva era, donde, los desarrolladores escriben el

código el cual es subido continuamente a un repositorio y mediante técnicas, herramientas y un

poco de ingenio se logra automatizar para que este código sea compilado, integrado y probado en

todo momento. Así el equipo de control de calidad puede tenerlo en sus manos casi de inmediato

y una vez este listo, inicie una implementación automatizada para producción.

Como todo esta automatizado, es mucho más fácil la implementación manteniendo las cosas

estables. Las implementaciones ocurren con mucha más frecuencia, haciendo que las

funcionalidades lleguen a manos de los clientes más rápido.

En el caso de que alguna implementación rompa algo en producción, el monitoreo automatizado

notifica al equipo inmediatamente, el equipo realiza una reversión implementando la versión más

reciente sin errores y así soluciona el problema de forma rápida.

 10

¿Por qué DevOps?

Porque necesitamos tener equipos más felices, equipos que tengan más tiempo innovando y menos

tiempo apagando incendios. Equipos que no tengan que luchar entre ellos, sino más bien

colaborarse.

Y, por último, mantener al cliente feliz, brindándoles la funcionalidad que desean de forma rápida

y no tener que sacrificar la estabilidad del software para hacerlo.

2 Metodología

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

• Método Bibliográfico, debido a que se realizara la lectura y compilación de información

relacionados al tema de estudio.

1La investigación bibliográfica es la primera etapa del proceso investigativo que

proporciona el conocimiento de las investigaciones ya existentes, de un modo sistemático,

a través de una amplia búsqueda de: información, conocimientos y técnicas sobre una

cuestión determinada.

Dentro de la búsqueda de la verdad en la investigación científica, se acude a la realidad y

de ésta se obtienen: un problema, una hipótesis con su respectiva contrastación y

conclusiones.

1 RIVAS GALARRETA, E. (1994). La investigación bibliográfica y los textos académicos.

 11

El proceso de investigación estará completo cuando se cumpla el objetivo de la

investigación científica: un documento científico al cual los siguientes usuarios buscarán

como referencia, de tal manera que observarán hechos, platearán problemas; funcionando

así, como un nuevo punto de partida, realizado con la mayor objetividad posible, para

futuras investigaciones.

• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio y la experiencia de las clases del modulo de

entregas continuas.

2Es aquel método de investigación que consiste en la desmembración de un todo,

descomponiéndolo en sus partes o elementos para observar las causas, la naturaleza y los

efectos. El análisis es la observación y examen de un hecho en particular. Es necesario

conocer la naturaleza del fenómeno y objeto que se estudia para comprender su esencia.

Este método nos permite conocer más del objeto de estudio, con lo cual se puede: explicar,

hacer analogías, comprender mejor su comportamiento y establecer nuevas teorías.

2 http://gmorzingc.blogspot.com/2011/10/metodo-analitico-de-la-investigacion.html
 12

3 Conceptos importantes en el flujo de DevOps

Figura 1 – Flujo de DevOps

Fuente: http://www.tothenew.com/blog/fully-automated-cicd-pipeline-your-business-needs-it-
right-away/

Para tener un mayor dominio conceptual en el flujo de DevOps, se decidió mantener la

nomenclatura de las palabras en ingles. Esto permitirá familiarizarnos con todos los términos

técnicos usados en el mundo de DevOps.

3.1 Automatización de la Construcción (Build Automation)

Es el proceso de automatización del empaquetado de código para su implementación en un entorno

en vivo, dependiendo el lenguaje que se use, el código necesita compilarse, empaquetarse,

probarse, etc. La automatización implica seguir esos pasos y realizarlos de forma coherente
 13

utilizando un script o una herramienta, las cuales pueden diferir dependiendo el lenguaje y los
3
frameworks que se usen.

Por lo general, el build automation es muy parecido a la ejecución de ciertos pasos en línea de

comandos que permiten compilar el código usando ciertos archivos de configuración. El build

automation es independiente de un IDE, incluso si se puede compilar dentro de un IDE, debería

poder funcionar de la misma manera fuera del IDE.

Tanto como sea posible, el build automation debe ser independiente de la configuración de la

máquina en la que este construida, es decir el código deberá poder estar disponible en la máquina

de cualquier otro desarrollador.

La razón de ser del build automation se basa en lo siguiente:

• Rapidez: la automatización maneja tareas que de otro modo tendrían que hacerse

manualmente.

• Consistencia: la compilación se realiza de la misma manera todas las veces, eliminando

problemas y confusión que puede ocurrir con las compilaciones manuales.

• Repetible: la compilación se puede realizar varias veces con el mismo resultado. Cualquier

versión del código fuente siempre se puede transformar en código implementable de

manera consistente.

3 Framework,
es una estructura conceptual y tecnológica de soporte definido, normalmente con
artefactos o módulos de software concretos, que puede servir de base para la organización y
desarrollo de software.
 14

• Portable: La compilación se puede hacer de la misma manera en cualquier maquina.

• Confiable: habrá menos problemas causados por compilaciones incorrectas.

3.2 Integración Contínua (Continuous Integration)

También conocido con la sigla CI, es la práctica de fusionar frecuentemente cambios en el código

hechos por desarrolladores. La integración continua significa fusionarse constantemente durante

el día, generalmente con la ejecución de pruebas automatizadas para detectar cualquier problema

causado por dicha fusión.

Generalmente la integración continua se realiza con la ayuda de un servidor de verificación de

código fuente. Cuando un desarrollador hace un cambio en el código, el servidor de integración

contínua ve el cambio y automáticamente realiza la construcción y además realizar la ejecución de

pruebas automatizadas.

Esto ocurre varias veces al día y si hay algún problema con la compilación, el servidor notificará

de forma inmediata y automática a los desarrolladores, esto significa que, si alguien comete un

error en el código, es el responsable de solucionar el problema o revertir los cambios de inmediato

para que los otros desarrolladores puedan seguir trabajando.

La razón de ser del continuous integration se basa en lo siguiente:

• Detección temprana de ciertos tipos de errores, si el código no se compila o falla alguna

prueba automatizada, se notifica a los desarrolladores y se puede solucionar de inmediato.

Cuanto antes se detecten estos errores, más fácil será solucionarlos.

 15

• Eliminar problemas de integración justo antes de un 4release grande. El código se fusiona

constantemente, por lo que no es necesario realizar una gran integración al final.

• Hace posibles realeases frecuentes, es decir, que el código siempre se encuentre en un

estado implementable a producción.

• Hace posibles las pruebas continuas. Dado que el código siempre se puede ejecutar, los

verificadores de control de calidad pueden tener en sus manos todo a lo largo del desarrollo,

no solo al final.

• Brinda buenas practicas de codificación. Los 5commits frecuentes fomentan el código

simple y modular.

4
Es un lanzamiento de nuevas funcionalidades o modificaciones de codigo de acuerdo al
versionado de software.
5 Confirmar un cambio al repositorio de versiones.
 16

Figura 2 – Flujo de integración continua

Fuente: http://www.pepgotesting.com/continuous-integration/

3.3 Entregas Continuas y Despliegues Continuos (Continuous Delivery – Continuous

Deployment)

Continuous delivery, es la práctica de mantener continuamente el código en un estado desplegable.

Independientemente de si la decisión se implementa o no, el código siempre está en un estado

capaz de ser desplegado.

Continuous deployment, es la práctica de implementar con frecuencia pequeños cambios de código

en el entorno de producción, es decir, la entrega continua mantiene el código en un estado

desplegable y la implementación continua el despliegue con frecuencia.

 17

Algunas empresas que realizan implementación continua, las realizan a producción varias veces

al día, por tal motivo no existe un estándar para la frecuencia con la que debe implementarse, pero

en general, se dice que cuando más a menudo se implemente, mejor.

Con la implementación continua, las implementaciones en producción son rutinarias y comunes.

No son un gran evento aterrador.

Cada versión del código pasa por una serie de etapas tales como compilación automática, pruebas

automatizadas y pruebas de aceptación manual. El resultado de este proceso es un artefacto o

paquete que se puede implementar.

Cuando se toma la decisión de implementar, la implementación es automática. El aspecto de la

implementación automatizada depende de la arquitectura, pero no importa cual sea la arquitectura,

la implementación es automática.

Si una implementación causa un problema, se revierte rápidamente y de manera confiable,

utilizando un proceso automatizado para que el cliente no note el problema.

La razón de ser del continuous delivery y continuous deployment, se base en lo siguiente:

• La funcionalidad estará en manos del cliente de forma rápida.

• Menos problemas causados por el proceso de implementación, dado que el proceso de

implementación se usa con frecuencia, cualquier problema con el proceso se descubre más

fácilmente.

• Menor riesgo, cuantos más cambios se implementen a la vez, mayor será el riesgo. Las

implementaciones frecuentes de pocos cambios son menos riesgosas.

 18

• Reversiones confiables, en una automatización robusta las reversiones son confiables, esto

garantiza estabilidad para los clientes, y los desarrolladores pueden trabajar en la solución

del problema con menos estrés.

Figura 3 – Flujo de entregas continuas

Fuente: http://www.pepgotesting.com/continuous-integration/

3.4 Infraestructura como Código (Infraestructure as code)

La infraestructura como código, permite gestionar y proporcionar infraestructura a través de

código y automatización, en lugar de hacer las cosas manualmente, usa la automatización y el

código para crear y cambiar servidores, instancias, entornos, contenedores o alguna otra

infraestructura.

La razón de ser de la infraestructura como código, se basa en lo siguiente:

• Consistencia en la creación y administración de recursos, la misma automatización se

ejecutará de la misma manera todo el tiempo.

• Reutilización, el código se puede usar de nuevo en el futuro.

 19

• Escalabilidad, si se requiere una nueva instancia, se puede obtener uno configurado

exactamente de la misma manera que las instancias existentes en fracciones muy pequeñas

de tiempo.

Figura 4 – Infraestructura como código

Fuente: https://itsvit.com/our-solution/infrastructure-as-code/

3.5 Gestión de Configuración (Configuration Management)

La gestión de configuración consiste en mantener y cambiar el estado de las piezas de la

infraestructura de forma coherente, sostenible y estable. Siempre es necesario realizar cambios, y

estos pequeños cambios se van acumulando con el tiempo y hacen que los sistemas sean diferentes

entre sí y más difíciles de administrar, por tanto, es necesario una adecuada gestión de

configuración.

Si se necesita actualizar un paquete de software en varios servidores, sin una buena gestión de

configuración se tendría que iniciar sesión en cada servidor y realizar la actualización. Sin
 20

embargo, esto puede conducir a muchos problemas. Tal vez se olvidó un servidor debido a la

documentación deficiente, o tal vez algo no funciona, mientras que las versiones no coinciden

temporalmente entre los servidores, causando un montón de tiempo de inactividad mientras se

realiza la actualización.

Con una buena administración de configuración, se puede definir la nueva versión del paquete de

software en un archivo o herramienta de configuración y se despliega automáticamente el cambio

en todos los servidores.

La razón de ser de la administración de la configuración, se basa en lo siguiente:

• Ahorro de tiempo, lleva menos tiempo cambiar configuraciones en los servidores.

• Conocimiento, con una buena gestión de la configuración, se puede conocer el estado de

todas las piezas de una infraestructura compleja.

• Mantenibilidad, una infraestructura más fácil de mantener es mas fácil de cambiar de una

manera estable.

• Estandarizar, es más fácil mantener una configuración estándar en una multitud de hosts.

3.6 Orquestación (Orchestration)

Es la automatización que admite procesos y flujos de trabajo como recursos de aprovisionamiento.

Con la orquestación, administrar una infraestructura compleja es como ser un director de una

orquesta, donde en lugar de crear una pieza de infraestructura, el director simplemente señala lo

que se debe hacer y la orquesta lo realiza. El director no necesita controlar cada detalle, son los

músicos capaces de realizar su pieza con solo un poco de guía.

 21

Como ejemplo podemos tener a un cliente que solicita mas recursos para un servicio web, debido

a que este tendrá mayor transaccionalidad de usuarios. En lugar de implementar manualmente

nuevos nodos, los ingenieros de operaciones utilizan una herramienta de orquestación para solicitar

nodos adicionales y en cuestión de reducido tiempo, se tienen los nodos en funcionamiento.

Escalando un poco más la solución, en caso de que una herramienta de monitoreo detectara una

carga incrementada en el servicio, la herramienta de orquestación responde a esto generando

recursos adicionales para manejar la carga, cuando la carga disminuye nuevamente, la herramienta

vuelve a calibrar los recursos adicionales, liberándolos para que puedan ser utilizados.

La razón de ser de la orquestación, se basa en lo siguiente:

• Escalabilidad, los recursos pueden aumentar o disminuir rápidamente para satisfacer las

necesidades cambiantes.

• Estabilidad, las herramientas de automatización pueden responder automáticamente para

solucionar problemas antes de que los usuarios los vean.

• Ahorro de tiempo, ciertas tareas y flujos de trabajo se pueden automatizar, lo que libera

tiempo para los ingenieros.

• Información granular sobre el uso de los recursos, las herramientas de orquestación

proporcionan una mejor idea de la cantidad de recursos que utilizan software, servicios o

clientes.
 22

3.7 Monitoreo (Monitoring)

Es la recopilación y presentación de datos sobre el rendimiento y la estabilidad de los servicios y

la infraestructura. Las herramientas de monitoreo recopilan datos sobre cosas tales como: uso de

la memoria, CPU, I/O, logs de aplicaciones, tráfico de red, etc.

Los datos recopilados se presentan en diversas formas, como cuadros y gráficos, o como

notificaciones en tiempo real sobre problemas.

Para entender mejor el contexto de monitoreo, podemos poner como ejemplo el siguiente

escenario: el rendimiento en el sitio web esta empezando a degradarse, mediante una herramienta

de monitoreo se detecta que los tiempos de respuesta están creciendo e inmediatamente la

herramienta notifica al administrador para que pueda intervenir antes de que ocurra un 6timeout.

Como análisis post error, se puede ver que algo pudo haber salido mal en el último despliegue a

producción, con la información recolectada por la herramienta de monitoreo las personas

involucradas pueden determinar la causa raíz y corregirla.

La razón de ser del monitoreo, se basa en lo siguiente:

• Recuperación rápida, cuanto antes se detecte el problema, la solución también será rápida.

El problema debe ser identificado antes que el cliente lo perciba.

• Mejor análisis de la causa raíz, cuantos más datos se tenga, más fácil será determinar la

causa raíz de un problema.

6 Timeout, es un mensaje de error cuando el tiempo de espera se agotó.

 23

• Visibilidad en todos los equipos, buenas herramientas de monitoreo brindan datos útiles

tanto a los desarrolladores como a operaciones sobre el rendimiento del código en

producción.

• Respuesta automatizada, los datos de supervisión se pueden usar junto con la orquestación

para proporcionar respuestas automáticas a eventos, como la recuperación automática de

fallas.

3.8 Microservicios (Microservices)

La arquitectura de micro servicios divide una aplicación en una colección de servicios pequeños,

donde cada micro servicio implementa sólo una parte pequeña de funcionalidad general de una

aplicación. Estos micro servicios están ligeramente acoplados, es decir diferentes micro servicios

interactúan entre si utilizando API estables y bien definidas, donde son independientes uno del

otro.

La razón de ser de la arquitectura de micro servicios, se basa en lo siguiente:

• Modularidad, lo micro servicios fomentan modularidad. En aplicaciones monolíticas, las

piezas individuales se unen estrechamente y la complejidad aumenta. Eventualmente, es

muy difícil cambiar algo sin romper algo.

• Flexibilidad tecnológica, no necesita utilizar los mismo lenguaje y tecnologías para cada

parte de la aplicación. Se puede usar la mejor herramienta para cada trabajo.

• Escalabilidad optimizada, puede escalar partes individuales de la aplicación según el uso y

la carga de recursos.
 24

Figura 5 – Microservicios
Fuente: https://hackernoon.com/microservices-are-hard-an-invaluable-guide-to-microservices-
2d06bd7bcf5d

4 Herramientas para DevOps y su integración en la nube

4.1 Herramientas para DevOps

DevOps es más que una cultura que enfatiza en la colaboración y la comunicación entre los equipos

de desarrollo y el resto de los profesionales de IT. Hablamos de automatizar la entrega de software

y la estabilidad de los sistemas.

Por tanto, esta colaboración se basa principalmente en herramientas que aseguren al mismo tiempo

la rapidez y la fiabilidad en los cambios contantes.

Para tener un poco mas claro el rol de las herramientas en DevOps, debemos remarcar los

siguientes puntos:

• DevOps no es un conjunto de herramientas.

• Las herramientas permiten ejercer velocidad en los procesos de DevOps, sin descuidar la

estabilidad.
 25

• Parte de lo que se hace como DevOps es identificar las herramientas que se necesita y

aprender a usarlas.

Para poder conocer un poco más sobre las herramientas utilizadas en el flujo de DevOps, podemos

referirnos a la “tabla periódica de herramientas de DevOps” publicado por 7XebiaLabs, el cual nos

brinda un completo panorama de las herramientas open source, free, paid, enterprise, etc.

Figura 6 – Tabla periódica de herramientas de DevOps

Fuente: https://xebialabs.com/periodic-table-of-devops-tools/

7
XebiaLabs, es una compañia de software independiente especializada en DevOps y entrga
contínua para grandes organizaciones empresariales.
 26

Cabe recalcar que en las próximas secciones se describirán algunas de las más populares

herramientas que se usan hoy en día.

4.1.1 Automatización de la construcción e Integración Contínua (Build automation y

continuous integration)

Build automation, es el proceso automatizado del empaquetado de código para que este listo para

la implementación. La elección de la herramienta depende mucho del lenguaje de programación y

los frameworks, entre los cuales tenemos, por ejemplo:

• Java – ant, maven, gradle

• Javascript – npm, grunt, gulp

• Make – usado en sistemas basado en UNIX.

Continuous integration, es la fusión continua de código que se realiza dentro de un servidor de

gestiona el control de versiones y el control de código. Cuando el código fuente es cambiado, la

herramienta de integración continua realiza la construcción automática.

Podemos citar algunas de las herramientas populares:

• Jenkins, la cual tiene ciertas características al ser de código fuente abierto y está basada en

java servlets.

Jenkins fue originalmente desarrollado con el nombre Hudson. El desarrollo de Hudson

empezó en el verano de 2004 en Sun Microsystems. Su primera versión fue publica en

febrero de 2005.

En noviembre de 2010 surgieron varios temas respecto a la administración y gestión del

proyecto por parte de Oracle. Uno de los puntos claves fue la propiedad de la marca
 27

Hudson. Después Oracle reclamó el derecho al nombre y marca registrada Hudson en

diciembre de 2010. Como resultado, el 11 de enero de 2011, se hizo una votación entre los

miembros de la comunidad para cambiar el nombre del proyecto de “Hudson” a “Jenkins”.

La propuesta fue aprobada por la comunidad el 29 de enero de 2011.

El 1 de febrero de 2011, Oracle dijo que continuarían con el desarrollo de Hudson y

consideraron a Jenkins un fork en lugar de un cambio de nombre.

Jenkins y Hudson continúan como proyectos independientes y considerando al otro

proyecto como fork.

El 7 de julio de 2016 se hizo pública la primera versión 2.x con soporte LTS.

• TravisCI, es de código fuente abierto, se integra muy bien con github y además que ejecuta

cada build en una máquina virtual limpia.

• Bamboo, es un producto enterprise desarrollado por Atlassian, por tanto, la integración con

JIRA y Confluence es muy bien adaptable.

4.1.2 Gestión de la Configuración (Configuration Management)

Permite gestionar y cambiar el estado de las piezas de la infraestructura de forma coherente y

consistente. Es una muy buena forma de implementar infraestructura como código (infraestructura

as code).

Podemos citar algunas de las herramientas populares:

• Ansible, es de código abierto, usa configuración declarativa en archivos de configuración

yaml, no es necesario un servidor de control, es decir que puede utilizarse desde una PC si
 28

fuera el caso, tampoco requiere de agentes ya que puede usar tecnologías existentes como

Python y ssh.

• Puppet, el usuario describe los recursos del sistema y sus estados utilizando el lenguaje

declarativo que proporciona Puppet. Esta información es almacenada en archivos

denominados manifiestos Puppet. Puppet descubre la información del sistema a través de

una utilidad llamada Facter, y compila los manifiestos en un catálogo específico del sistema

que contiene los recursos y la dependencia de dichos recursos. Estos catálogos son

ejecutados en los sistemas de destino.

• Chef, usa una configuración procedural y además que requiere de agentes y servidor. La

configuración del servidor esta escrita en un lenguaje propio llamado DSL (domain specific

language).

• Salt, usa una configuración declarativa y que también esta orientado al uso de agentes

(conocidos como minions) y el servidor (conocido como master). Para la configuración usa

archivos yaml.

4.1.3 Virtualización y Contenedores (Virtualization y Containerization)

Lo que se pretende con la virtualización es administrar recursos creando máquinas virtuales en

lugar de físicas. Ejemplos de herramientas de virtualización:

• VMWare ESX and ESXi

• Microsoft Hyper-V

• Citrix XenServer
 29

La containerización es considerada como el paso siguiente de la virtualización, por lo que es un

paquete mucho mas liviano y aislado que contiene todo los necesario para ejecutar un software.

Por tanto, la ventaja de usar contenedores es mas alta que usar máquinas virtuales.

Docker es el máximo representante en los contenedores, si bien el concepto de contenedores es

nuevo actualmente es muy usado por DevOps, debido a que tiene grandes beneficios para la

portabilidad.

4.1.4 Monitoreo (Monitoring)

Es la actividad de recopilación y presentación de datos sobre el estado y el rendimiento de las

aplicaciones. Hay diferentes tipos de monitoreo:

• Monitoreo de infraestructura, el cual esta enfocado en el rendimiento de los servidores,

donde por ejemplo se puede monitorear el CPU, RAM, etc.

• Monitoreo del rendimiento de la aplicación (APM), el cual esta enfocado en el performance

y la estabilidad de las partes individuales de una aplicación, como por ejemplos, los

tiempos de respuesta, logs, etc.

Entre las herramientas usadas para este fin se tienen:

• SenSu, antes conocido como Nagios, usa una arquitectura servidor/agente donde los

agentes envían los datos al servidor para que este los pueda procesar y hacerlos visible de

muchas maneras.

• NewRelic, es una solución de software como servicio, además que ofrece una numerable

cantidad de métricas que permiten una clara toma de decisiones.

 30

• AppDynamics, básicamente recolecta todos los datos de las aplicaciones para luego

centralizarlas en dashboards. Hace un diagnostico a nivel de código a fin de identificar

problemas con anterioridad.

Algunas de las herramientas de monitoreo también incluyen funcionalidades de agregación y

análisis, los cuales permiten tener un mayor control grafico del monitoreo además de ciertas alertas

y notificaciones que son útiles en el sentido preventivo. Una muy buena herramienta con este valor

agregado es Elastic Stack, el cual ayuda a diagnosticar y detectar problemas de manera fácil.

4.1.5 Orquestación (Orchestration)

Como se explicó anteriormente, la orquestación permite automatizar los procesos y flujos de forma

que se puede proporcionar ciertos recursos necesarios, es decir, escalar los recursos cuando se

necesiten y bajar los recursos cuando estos ya no se requieran. Esto debe hacer de forma

automática, de acuerdo al uso de las aplicaciones.

Las herramientas mas usadas para hacer orquestación son:

• Docker Swarm, es nativo de docker y se adapta muy convenientemente a los contenedores

de docker.

• Kubernetes, es de código abierto y usa un servidor para gestionar las aplicaciones a través

de multiples hosts.

• Zookeeper, es de código abierto y forma parte de Apache Foundation. Ofrece un registro

de servicio centralizado que se integra con las funciones de orquestación.

• Terraform, combina la orquestación con la infraestructura como código, trabaja bien con

Ansible y se integra muy bien con AWS y kubernetes.

 31

4.2 Herramientas para DevOps en la nube

La nube, son servidores remotos en internet que ofrecen servicios en lugar de tener soluciones

alojadas localmente. La cultura y practica de DevOps es muy usado en el mundo de la nube (cloud),

por tanto, DevOps y la nube van muy de la mano.

Cuando comparamos un servidor local y un servidor en la nube, está claro que con el servidor local

tenemos que estas pendientes de la administración por nuestra cuenta a nivel infraestructura, en

cambio con un servidor en la nube sólo debemos enfocarnos a nivel de sistema operativo, además

de la instalación y configuración.

Algunas de las bondades de usar un servidor en la nube son:

• IaaS, permite gestionar la infraestructura como servicio.

• PaaS, la plataforma como servicio permite abstraer todo lo que está debajo de las capas de

la aplicación y datos.

• Uno solo es responsable de gestionar la aplicación y los datos.

• SaaS, con software como servicio, todo es gestionado.

En la figura 7 obtenida podemos ver a detalle de como son gestionados los servicios en la nube de

acuerdo a los modelos descritos.

 32

Figura 7 – Gestión de servicios en la nube

Fuente: http://cloudonmove.com/iaas-paas-saas-what-do-they-mean/

4.2.1 Google cloud platform

La plataforma de Google cloud dispone de algunas funcionalidades que brindan soporte para

DevOps. Entre las cuales se tiene:

• Google App Engine, es la plataforma como servicio de google que permite alojar

aplicaciones en la misma infraestructura usada por google, dotando a nuestras aplicaciones

de gran escalabilidad de manera transparente para el desarrollador. Está orientado al

desarrollo rápido de aplicaciones a medida que se acomoden dinámicamente a grandes

variaciones en su carga de uso, sin tener que preocuparse por administrar infraestructura

que las sustenta.

• Google Compute Engine, es la infraestructura como servicio de google que permite usar

máquinas virtuales con imágenes Linux dentro de la infraestructura de google. Está

 33

orientado al desarrollo de aplicaciones que tienen una gran carga computacional, o

aplicaciones que requieren paquetes de software open source o comerciales desarrollados

por terceros que no encajan en el modelo anterior.

• Google Cloud Storage, es el sistema de almacenamiento de archivos en la nube de google.

Nos permite almacenar una cantidad ilimitada de ficheros de gran tamaño, para servirlos

posteriormente con gran rendimiento y alta disponibilidad, de una manera segura,

protegiendo los datos mediante sistemas ACL y cifrado en el servidor.

• Google Big Query, es un sistema gestionado para analizar Big Data en tiempo real. Permite

ejecutar consultas SQL ad hoc sobre grandes cantidades de datos en cuestión de segundos.

Los datos se almacenan seguros, protegidos por ACL. Es una solución idónea para sistemas

de análisis de datos.

• Google Cloud Datastore, nos proporciona un NoSQL gestionado de alta disponibilidad.

Este almacén no relacional, con soporte de transacciones y consultas, puede ser accedido

tanto desde dentro de la plataforma como desde aplicaciones externas. Es un buen sistema

para aplicaciones con modelos de datos no relacionales, que requieren alta escalabilidad y

en las que priman las consultas de datos frente a las escrituras.

• Google Cloud SQL, es un sistema gestionado MySQL en la nube. Permite el uso de bases

de datos relacionales para alta disponibilidad, sin tener que preocuparnos de gran parte de

la administración de las mismas. Puede ser accedido desde dentro o fuera de la plataforma.

Útil para modelos relacionales complejos, con una carga de trabajo media.
 34

• Google Prediction API, permite ejecutar algoritmos de machine learning para analizar

datos y detectar características o hacer predicciones sobre los mismos.

• Google Translation API, permite detectar en que idioma esta escrito un texto o traducirlo

a distintos idiomas. Permite diseñar aplicaciones multi idioma de manera sencilla.

Figura 8 – Funcionalidades soportada en Google Cloud Plattform

Fuente: http://markoinsights.com/2016/11/11/google-cloud-update/

4.2.2 Microsoft Azure

Azure fue anunciado en 2008 y se publicó en 2010 bajo el nombre de Windows Azure, para ser

posteriormente renombrado como Microsoft Azure en 2014. El concepto de Azure surgió como

una plataforma de cloud computing diseñada para crear, desarrollar y administrar aplicaciones,

software y servicios a través de una red global de centros de datos administrados por Microsoft.

Estos centros de datos están repartidos por todo el mundo.

La visión de la nube de Microsoft Azure parece estar orientada al mundo empresarial, tanto

aquellas corporaciones de mayor tamaño como a las pequeñas y medianas empresas. Por ello, la
 35

mayoría de servicios son escalables y son capaces de responder a necesidades generales del mismo

modo que a necesidades particulares. Azure tiene un amplio abanico de herramientas y servicios

que puede ofrecer a los usuarios y que pueden resumirse en las siguientes categorías:

• Servicios para móviles, creación, desarrollo y gestión de aplicaciones para distintos

sistemas operativos móviles, con diferentes lenguajes de programación disponibles.

• Almacenamiento, diferentes tipos de almacenamiento (SQL, BLOBs, tablas, etc.) para

diferentes formatos de archivos o estructuras de almacenaje. También como

almacenamiento de los datos de aplicaciones y programa empresariales.

• Herramientas de seguridad, protocolos, herramientas y opciones complementarias para

aumentar la seguridad de sus datos y aplicaciones locales o en la nube. Creación de sistemas

de autentificación en varios pasos, recuperación ante desastres mediante copias de

seguridad, etc.

• Flujos de trabajo, procesos de automatización y optimización de flujos de trabajo, tareas y

procesos internos de la empresa. Tareas automatizadas a través de Azure y servicios

complementarios.

• Máquinas virtuales, creación, administración y gestión de maquinas virtuales.

• Business Intelligence, recolección y gestión de grandes cantidades de datos para análisis y

toma de decisiones. Herramientas de análisis y previsión empresarial.

 36

Figura 9 – Funcionalidades soportadas en Microsoft Azure

Fuente: https://www.advoco-solutions.co.uk/it-services/microsoft-products/windows-azure/

4.2.3 Amazon web services

Amazon Web Services, también conocida como AWS, es un conjunto de herramientas y servicios

de cloud computing de Amazon. Este servicio se lanzó oficialmente en 2006 y para junio de 2007

AWS ya contaba con una base de usuarios de aproximadamente 180 mil personas. Entre las

empresas que la utilizan se encuentran algunas como Reddit, Foursquare, Pinterest, Netflix, la

NASA o la CIA, y algunas españolas como Mapfre, el FC Barcelona o Interflora. Esto se debe

principalmente a la madurez del servicio frente a otros similares y las posibilidades que ofrece el

amplio abanico de herramientas disponibles. En la 8Guía de Cloud Computing podrá encontrar una

8 https://www.ticportal.es/guias/guia-cloud-computing
 37

comparativa de todas las herramientas de Amazon Web Services con las de otras plataformas

similares.

La tendencia general para las plataformas en la nube es la de ofrecer la mayor cantidad posible de

herramientas y servicios, para que así se pueda crear todo un entorno de computación en una misma

nube. Al igual que otras plataformas como Microsoft Azure, Amazon dispone de una gran cantidad

de herramientas para la gestión de diferentes elementos dentro de la empresa. Los servicios de

AWS están preparados tanto para autónomos, como pequeñas y medianas empresas o grandes

corporaciones, ya que existen posibilidades para escalar las instancias o el almacenamiento según

su empresa vaya también creciendo.

Amazon Web Services ofrece herramientas en las siguientes categorías:

• Cloud computing, todo lo necesario para la creación de instancias y el mantenimiento o el

escalado de las mismas. Amazon EC2 es el rey indiscutible dentro de los servicios de

computación en la nube de Amazon.

• Bases de datos, distintos tipos de bases de datos pueden permanecer en la nube mediante

el servicio Amazon RDS, que incluye distintos tipos a elegir como MySQL, PostgreSQL,

Oracle, SQL Server y Amazon Aurora, o Amazon DynamoDB para NoSQL.

• Creación de redes virtuales, permite la creación de redes privadas virtuales a través de la

nube, gracias principalmente al servicio Amazon VPC.

• Aplicaciones empresariales, Amazon WorkMail es el servicio de correo empresarial que

ofrece, al que pueden unirse otros servicios como Amazon WorkDocs y Amazon

WorkSpaces.
 38

• Almacenamiento y gestores de contenido, tipos de almacenamiento diferentes, tanto para

archivos con acceso regular, poco frecuente o incluso como archivo. Amazon S3 es el

servicio principal.

• Inteligencia de negocios, sistemas para análisis de datos empresariales a gran escala y

otros servicios para la gestión de flujos de datos.

• Gestión de aplicaciones móviles, herramientas como Amazon Mobile Hub permiten la

gestión, creación, testeo y mantenimiento de aplicaciones móviles a través de la nube.

• Internet de las cosas, para establecer conexiones y análisis de todos los dispositivos

conectados a internet y los datos recogidos por los mismos.

• Herramientas para desarrolladores, para almacenar código, implementarlo

automáticamente o incluso publicar software mediante un sistema de entrega continua.

• Seguridad y control de acceso, se pueden establecer autenticaciones en varios pasos para

poder proteger el acceso a sus sistemas internos, ya estén en la nube o instalados de

forma local en sus instalaciones.

 39

Figura 10 – Funcionalidades soportadas en AWS

Fuente: https://medium.freecodecamp.org/the-complete-aws-web-boilerplate-d0ca89d1691f
 40

5 Conclusiones y Recomendaciones

- Los enfoques tradicionales para el desarrollo y la entrega de software ya no son suficientes.

- Los procesos manuales inducen al error, generan más problemas y demoras en las
respuestas. Las empresas no pueden darse el lujo de priorizar el costo descuidando la
velocidad de la entrega, ni tampoco elegir la velocidad en lugar de gestionar el riesgo, por
tanto, un enfoque DevOps ofrece una poderosa solución para estos desafíos.
- DevOps reduce el tiempo de retroalimentación al cliente, aumenta la calidad, reduce el
riesgo, el costo y unifica varios procesos usando herramientas poderosas que tienen una
constante actualización.
- Para implementar DevOps, es esencial estar organizado, que los equipos conozcan los
beneficios de implementar los procesos para que pueda ser un cambio sostenible.
 41

6 Bibliografía

- Gene Kim, Jez Humble, Patrick Debois and John Willis (2016). The DevOps HandBook.

- Jennifer Davis and Katherine Daniels (2015). Effective DevOps.

- Joakim Verona (2016). Practical DevOps.

- Gary Gruver (2016). Starting and Scaling DevOps in the Enterprise.

- TechWorld (2018). Transforming Your Organization Through Agile, Scrum And DevOps Principles.

- Google Cloud Platform. Recuperado de https://cloud.google.com/docs/

- Microsoft Azure. Recuperado de https://docs.microsoft.com/es-es/azure/

- Amazon Web Services. Recuperado de https://aws.amazon.com/es/documentation/