Por qué las herramientas de DevOps se basan en excelentes integraciones de API

 

Las API impulsan DevOps en todos los significados de la palabra. Habiendo dicho eso, a menudo miramos las API solo de una manera: las vemos como un producto en lugar de lo que son, que es un sistema de habilitación central para la infraestructura de código moderna . Las API están involucradas en casi todas las acciones en el espacio DevOps.

¿Porqué es eso? ¿Qué hace que las API sean tan importantes para DevOps específicamente? Hoy, vamos a ver solo eso: consideraremos casos de uso para excelentes integraciones de API y señalaremos exactamente por qué las API son los héroes no reconocidos y mal definidos de la era de DevOps.

¡En la Platform Summit 2019 en Estocolmo, presentaremos nuestra primera pista de oradores de DevOps ! CFP todavía está abierto aquí

API en el contexto de DevOps

Antes de sumergirnos en las API como habilitador de herramientas de DevOps, sería útil definir realmente lo que queremos decir cuando decimos " API ". La palabra API a menudo recuerda un producto terminado. En otras palabras, cuando una empresa dice que use "su API", la idea inmediata es una solución completa que realice una amplia gama de acciones dentro de una clase determinada.

Incluso un microservicio , que en realidad es solo una API dividida en varias partes, a menudo se ve en la lente de un producto; si habilita algo, habilita lo que el desarrollador quiere monetizar, como implementar el estado de su servidor en un push móvil. sistema.

La realidad es que las API están, de hecho, en cada capa de la informática y, como tal, cuando hablamos de las "API", las estamos vendiendo cortas al considerarlas únicamente un producto. Estas API pueden estar presentes de manera visible, como una oferta de API completa y discreta que habilita un grupo central de funciones, pero también puede ser un elemento relativamente invisible , lo que hace que la comunicación entre capas sea más fluida y refinada. En otras palabras, una API puede ofrecer un conjunto independiente de funciones y facilitar la interconexión de otras funciones.

Teniendo esto en cuenta, el mundo de DevOps y su relación con las API se hace más claro. Una API puede cumplir una o más funciones fundamentales en el mundo de DevOps ; echemos un vistazo a algunas ahora.

Lea también:  ¿Cuál es la diferencia entre API y microservicios?

API como habilitador

En DevOps, las API sirven principalmente como habilitadores entre cada etapa de interacción. Como cada acción de DevOps es esencialmente una función discreta, una unidad discreta de cálculo, las interacciones entre ellas deben estar respaldadas por un sistema de metodología o conocimiento comúnmente acordado.

Por ejemplo, cuando una oferta permite a un desarrollador transferir información de un sistema a otro, no es tan simple como copiar y pegar información; esto requeriría un esfuerzo manual y consumiría demasiado tiempo y potencia de cálculo. En cambio, las API facilitan la comunicación directa de solución a solución , lo que permite que las plataformas se comuniquen directamente.

Por ejemplo, digamos que tenemos un caso en el que un desarrollador quiere que su equipo desarrolle adiciones a una base de código en respuesta a tickets de problemas y luego rastree esa implementación en dispositivos móviles. En cada nivel de esta interacción, necesitamos una API habilitadora. El sistema de emisión de tickets tiene su propia API que se alimenta en la API de la cola de trabajo, con la que luego interactúa el codificador, quien luego envía estos datos a una API de seguimiento, que luego envía a un dispositivo móvil usando, lo adivinó, una API. En cada paso, las API sirven para habilitar la solución DevOps, y sin estas API, no existe una gran solución.

En este ámbito, normalmente vemos integraciones entre ofertas. Vincular Slack a Zapier, utilizar Google Translate en los sistemas de venta de entradas e incluso habilitar los chats de soporte de servicio al cliente sincrónicos son excelentes ejemplos de este tipo de integración de API en el espacio DevOps.

API como traductor

No todos los sistemas van a ser iguales; como tales, las API funcionan como una especie de traductor . En los primeros días de la TI, cuando todo se desarrollaba internamente (o al menos en un sistema definido como compatible entre sí), no había que traducir nada. Algo para los sistemas compatibles con IBM sería compatible en todos los ámbitos, hablando en gran medida, y como tal, no había una necesidad real de trasladar la información de un formulario a otro.

En la era moderna, donde cada servicio y función principal está disponible por partes y, en cambio, aprovecha una gran cantidad de integraciones de diferentes proveedores, este no es siempre el caso. Lo que es factible en una solución puede no serlo en otra, y cuando se mueven datos de un servicio a otro, la traducción debe ocurrir.

En tales casos, las API no son solo habilitadores, son la columna vertebral completa del sistema en sí ; no hay forma de transferir información de Scala a Ruby en diferentes pilas de hardware con diferentes formas de paquetes de tránsito y tipos de cifrado sin el uso amplio de API .

API como herramienta de automatización

DevOps proporciona muchos beneficios en la optimización de sistemas . Uno de esos beneficios es la posibilidad de automatización . Cuando un sistema está automatizado, se requieren API en cada paso para procesar de manera eficiente la información solicitada y entregarla al proceso correspondiente. Cada función central necesita una forma de comprender el contexto y las expectativas del sistema de datos que automatiza la solicitud; lo contrario también es cierto, ya que el sistema necesita algún tipo de nivel de comprensión para cada función central.

Las API permiten esta comprensión. Las API ampliamente documentadas, comentadas y definidas pueden permitir que los sistemas se conecten a una red automatizada, aprovechando la estructura de código existente con gran efecto. La automatización es diferente a una solución de programación normal, porque la relación es de confianza implícita y una especie de custodia de datos: debe haber un intermediario que tome los datos del cliente que se están automatizando, los retiene y luego los envía a otra cosa en la forma esperada. Esto es exactamente lo que hace una API.

Por ejemplo, si un desarrollador desea implementar una solución de monitoreo , las API son necesarias para comprender no solo cuál es la función esperada, sino también para probar la salida de esas funciones con el resultado esperado. Las API en cada nivel de la interacción deben poder ver la función y compararla con el valor esperado, y si el valor se desvía significativamente, también deben poder informar esta desviación y volver a introducir el código en el error. comprobación.

API como factorización

Finalmente, debe mencionarse que las API en el espacio DevOps sirven funcionalmente como un método para refactorizar los esfuerzos . Cada implementación e integración de una API crea una red de integraciones, lo que hace que una función central única sea más efectiva, más completa y, en última instancia, más que la suma de sus partes.

Por ejemplo, si uno estuviera desarrollando una API de control de calidad para ayudar en el desarrollo de código, se esperaría una verificación automática de errores. Sin embargo, lo que podría no esperarse es el valor de integrar una API para verificar informes de errores recientes en los repositorios de GitHub. Verificar de esta manera puede ayudar a identificar si el problema que está experimentando la base de código es nativo del código, o el resultado de una biblioteca o función que funciona incorrectamente.

Las API adicionales podrían incluso expandir este tipo de interacción, permitiendo integraciones inteligentes y ricas en hipermedia que hacen que cada función realizada en el ciclo de vida del desarrollo sea más fácil de contextualizar; por ejemplo, una API podría proporcionar enlaces a áreas específicas de documentación de esquemas cuando falla una función invocada, permitiendo al desarrollador aislar y eliminar rápidamente el código problemático.

Un solo producto solo puede hacer mucho. Cuando ese producto se une a una red de integraciones que permite la traducción, la automatización, la comprensión, la contextualización y la habilitación, se hace mucho más grande que la suma de sus partes.

Ejemplos de código

Ahora que generalmente entendemos el valor detrás de las integraciones de API para las herramientas de DevOps , veamos algunos ejemplos de código. Estos fragmentos de código provienen de la documentación oficial y representan acciones y operaciones efectivas que pueden ayudar a integrar cada solución.

Gitlab

Un aspecto de las pruebas de DevOps implica probar experiencias de usuario específicas. Desafortunadamente, esto a veces puede estar oculto detrás de la cuenta que realmente realiza las pruebas; lo que puede fallar para un usuario puede funcionar para un administrador, en otras palabras.

Gitlab proporciona una solución sencilla para generar un "token de suplantación". Estos tokens funcionan exactamente igual que un token personal en el código base de Gitlab, pero permiten a los administradores realizar una llamada como si fueran el usuario en cuestión.

Para empezar, se puede realizar la siguiente llamada para crear un token de suplantación:

POST /users/:user_id/impersonation_tokens

Desde aquí, este token (o realmente cualquier token adjunto a una cuenta) se puede usar para hacerse pasar por el usuario y, por lo tanto, ayudar en las pruebas automatizadas del flujo de trabajo del usuario, así como del flujo de trabajo del administrador.

Jenkins

Durante la puesta en escena automatizada, los usuarios de DevOps pueden desear evitar la automatización completa para detectar cualquier problema emergente durante ciertas etapas. Este tipo de "limitación de hitos" a menudo se denomina control de cordura y se utiliza para garantizar que todavía hay un elemento humano en el patrón de liberación general.

Jenkins hace esto de manera bastante simple al generar un escenario que requiere participación humana. Considere el siguiente fragmento de código.

pipeline {
    agent any
    stages {
        /* "Build" and "Test" stages omitted */

        stage('Deploy - Staging') {
            steps {
                sh './deploy staging'
                sh './run-smoke-tests'
            }
        }

        stage('Sanity check') {
            steps {
                input "Does the staging environment look ok?"
            }
        }

        stage('Deploy - Production') {
            steps {
                sh './deploy production'
            }
        }
    }
}

En este enfoque, la etapa Implementación - Puesta en escena tiene scripts automatizados que se ejecutan para garantizar un procesamiento adecuado. Sin embargo, una vez que se completa esta etapa, se realiza una solicitud de entrada durante el llamado "control de cordura" para forzar la intervención humana. Esto también podría admitir herramientas adicionales y entradas externas, permitiendo que el procesamiento secundario o la puesta en escena ocurra fuera del sistema automatizado.

Kubernetes

Por último, el uso de ReplicaSet en Kubernetes puede proporcionar una solución eficaz para establecer la disponibilidad y la concurrencia de los servicios mientras se implementan las actualizaciones de los servicios principales. El siguiente código se utiliza en su documentación para crear un conjunto de réplicas de pods; en este caso, crea 3 pods idénticos de la aplicación "libro de visitas" en la interfaz del servicio.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Lo que esto está haciendo en términos de DevOps es garantizar la continuidad de los servicios al permitir que los puntos finales se resuelvan en servicios de réplica mientras se actualizan o cambian los servicios centrales. En este flujo, el usuario no tendrá idea de que los pods originales están siendo alterados de alguna manera, y si experimentan esto, solo será debido al uso de nuevas sintaxis / llamadas o mediante metodologías de implementación gradual por parte del propio desarrollador. .

Conclusión

Las API son los héroes anónimos de DevOps: sin grandes integraciones de API, DevOps no cumple su promesa de un futuro mejor, más sensible y más automatizado. Sin embargo, con el poder de las API y las integraciones de API, esta promesa se puede cumplir, y con creces.

¿Qué opinas sobre las API en el espacio DevOps? ¿Crees que la amplia gama de opciones de API es más útil o perjudicial? Háganos saber en los comentarios a continuación.