Prometheus es uno de los sistemas clave en las arquitecturas de nube actuales. El segundo proyecto graduado de la Cloud Native Computing Foundation (CNCF) después de Kubernetes, y es la solución de monitoreo por excelencia en la mayoría de las cargas de trabajo que se ejecutan en Kubernetes.
Si ya has usado Prometheus por algún tiempo, sabes que se basa en una base de datos de series temporales, por lo que el almacenamiento de Prometheus es uno de los elementos clave. Basado en sus propias palabras de la página oficial de Prometheus:
Storage | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
Cada serie temporal se identifica de manera única por su nombre de métrica y pares clave-valor opcionales llamados etiquetas, y esa serie es similar a las tablas en un modelo relacional. Y dentro de cada una de esas series, tenemos muestras que son similares a las tuplas. Y cada una de las muestras contiene un valor flotante y una marca de tiempo con precisión de milisegundos.
Enfoque predeterminado en disco
Por defecto, Prometheus utiliza un enfoque de almacenamiento local guardando todas esas muestras en disco. Estos datos se distribuyen en diferentes archivos y carpetas para agrupar diferentes fragmentos de datos.
Así que, tenemos carpetas para crear esos grupos, y por defecto, son un bloque de dos horas y pueden contener uno o más archivos dependiendo de la cantidad de datos ingeridos en ese período de tiempo, ya que cada carpeta contiene todas las muestras para esa línea de tiempo específica.
Además, cada carpeta también tiene algún tipo de archivos de metadatos que ayudan a localizar las métricas de cada uno de los archivos de datos.
Un archivo es persistente de manera completa cuando el bloque ha terminado, y antes de eso, se mantiene en memoria y utiliza una técnica de registro de escritura anticipada para recuperar los datos en caso de un fallo del servidor de Prometheus.
Así que, a un nivel alto, la estructura de directorios del directorio de datos de un servidor de Prometheus se verá algo así:
Integración de Almacenamiento Remoto
El almacenamiento predeterminado en disco es bueno y tiene algunas limitaciones en términos de escalabilidad y durabilidad, incluso considerando la mejora de rendimiento de la última versión de TSDB. Así que, si queremos explorar otras opciones para almacenar estos datos, Prometheus proporciona una manera de integrarse con ubicaciones de almacenamiento remoto.
Proporciona una API que permite escribir muestras que se están ingiriendo en una URL remota y, al mismo tiempo, poder leer datos de muestra para esa URL remota como se muestra en la imagen a continuación:
Como siempre en cualquier cosa relacionada con Prometheus, el número de adaptadores creados usando este patrón es enorme, y se puede ver en el siguiente enlace en detalle:
Integrations | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
Resumen
Saber cómo funciona el almacenamiento de Prometheus es crítico para entender cómo podemos optimizar su uso para mejorar el rendimiento de nuestra solución de monitoreo y proporcionar un despliegue rentable.
En las siguientes publicaciones, vamos a cubrir cómo podemos optimizar el uso de esta capa de almacenamiento, asegurándonos de que solo se almacenen las métricas y muestras que son importantes para usar, y también cómo analizar cuáles métricas son las más utilizadas de la base de datos de series temporales para poder tomar buenas decisiones sobre qué métricas deben ser eliminadas y cuáles deben mantenerse.
Aprende cómo puedes aprovechar el uso de Snyk dentro de tu instalación del motor Docker
La seguridad es el tema más relevante en la arquitectura moderna. Necesita ser manejado desde todas las diferentes perspectivas. Tener un solo equipo auditando las plataformas y los desarrollos que construimos no es suficiente.
La introducción de DevSecOps como la nueva normalidad, incluyendo a los equipos de seguridad y las políticas como parte del proceso de desarrollo para evitar que la seguridad se convierta en un obstáculo para la innovación y asegurar que los artefactos que desplegamos estén seguros, ha dejado esto claro.
El escaneo de imágenes Docker es uno de los temas más importantes que podemos cubrir respecto a las imágenes de contenedores para saber que todos los componentes internos que forman parte de la imagen están a salvo de vulnerabilidades. Usualmente confiamos en algunos sistemas para hacerlo.
Escribí un artículo sobre el uso de una de las opciones más relevantes (Harbor) del mundo de código abierto para hacer este trabajo.
Y esto también está siendo realizado por diferentes repositorios Docker de proveedores de nube como Amazon ECR a partir de este año. Pero, ¿por qué necesitamos esperar hasta que subamos las imágenes a un registro Docker externo? ¿Por qué no podemos hacerlo en nuestro entorno local?
Ahora podemos. La versión 2.5.0.1 del motor Docker también incluye los componentes de Snyk necesarios para inspeccionar las imágenes Docker directamente desde la línea de comandos:
Entonces, comencemos. Abramos un nuevo terminal y escribamos el siguiente comando:
docker scan <nombre-de-imagen>
Tan pronto como escribamos esto, el comando nos dirá que este proceso de escaneo usará Snyk para hacerlo y necesitamos autorizar el acceso a esos servicios para realizar el proceso de escaneo.
Después de eso, obtenemos una lista de todas las vulnerabilidades detectadas, como puedes ver en la imagen a continuación:
Escaneo de vulnerabilidades usando tu cliente Docker local
Para cada una de las vulnerabilidades, puedes ver los siguientes datos:
Información detallada proporcionada para cada una de las vulnerabilidades detectadas
Obtenemos la biblioteca con la vulnerabilidad, el nivel de severidad y una breve descripción de la misma. Si necesitas más detalles, también puedes consultar la URL proporcionada que está vinculada a una página de descripción para esa vulnerabilidad:
Página detallada de vulnerabilidades de snyk
Finalmente, también proporciona las fuentes que introducen esta biblioteca en tu imagen para que esto pueda resolverse rápidamente.
También proporciona una vista de alto nivel de toda la imagen, como puedes ver aquí:
Visión general de tus imágenes Docker con todas las vulnerabilidades detectadas
Así que ahora no tienes excusa para no tener todas tus imágenes seguras antes de subirlas a tu repositorio local. ¡Hagámoslo!
Descubre cómo puedes mejorar el tamaño de tus imágenes de Docker para una mejor experiencia y ahorros dentro de tu organización.
La contenedorización es la nueva normalidad. Todos somos conscientes de eso. Todas las nuevas versiones del software corporativo y todos los proyectos de código abierto están incluyendo las opciones para usar una imagen de Docker para ejecutar su software. Probablemente ya hayas estado haciendo tus pruebas o incluso ejecutando cargas de trabajo en producción basadas en imágenes de Docker que has construido tú mismo. Si ese es el caso, probablemente conozcas uno de los grandes desafíos cuando realizas este tipo de tarea: ¿Cómo optimizar el tamaño de la imagen que generas? Una de las principales razones por las que la imagen de Docker puede ser tan grande es porque se construyen siguiendo un concepto de capas. Y eso significa que cada una de las imágenes se crea como la adición de capas, cada una asociada con los diferentes comandos que tienes en tu Dockerfile.Explicación gráfica de cómo se compone una imagen de Docker.
Usa dive para analizar el tamaño de tus imágenes
dive es un proyecto de código abierto que proporciona una vista detallada de la composición de tus imágenes de Docker. Funciona como una aplicación de interfaz de línea de comandos que tiene una gran vista del contenido de las capas, como puedes ver en la imagen a continuación:Ejecución de Dive de una imagen de BusinessWorks Container Edition La herramienta sigue una interfaz n-curses (si eres lo suficientemente mayor para recordar cómo eran las herramientas antes de que las interfaces gráficas de usuario fueran algo; debería parecerte familiar) y tiene estas características principales:
Esta herramienta proporcionará la lista de capas en la parte superior izquierda de la pantalla y el tamaño asociado con cada una de ellas.
Proporciona estadísticas generales sobre la eficiencia de la imagen (un valor porcentual), una vista potencial del tamaño desperdiciado y el tamaño total de la imagen.
Para cada una de las capas seleccionadas, obtienes una vista en el sistema de archivos para esta vista con los datos del tamaño de cada carpeta.
También obtén una vista de los elementos más grandes y el número de replicaciones de estos objetos.
Ahora, tienes una herramienta que te ayudará primero a saber cómo se construye tu imagen y obtener datos de rendimiento de cada uno de los ajustes que haces para mejorar ese tamaño. Así que, comencemos con los trucos.
1.- ¡Limpia tu imagen!
Este primero es bastante obvio, pero eso no significa que no sea importante. Por lo general, cuando creas una imagen de Docker, sigues el mismo patrón:
Declaras una imagen base para aprovechar.
Agregas recursos para hacer algún trabajo.
Haces algún trabajo.
Por lo general, olvidamos un paso adicional: ¡Limpiar los recursos agregados cuando ya no son necesarios! Por lo tanto, es importante asegurarse de eliminar cada uno de los archivos que ya no necesitamos. Esto también se aplica a otros componentes como la caché de apt cuando estamos instalando un nuevo paquete que necesitamos o cualquier carpeta temporal que necesitemos para realizar una instalación o algún trabajo para construir la imagen.
2.- Ten cuidado con cómo creas tu Dockerfile
Como ya mencionamos, cada uno de los comandos que declaramos en nuestro Dockerfile genera una nueva capa. Por lo tanto, es importante tener mucho cuidado con las líneas que tenemos en el Dockerfile. Incluso si esto es un compromiso con respecto a la legibilidad del Dockerfile, es importante intentar fusionar comandos en la misma primitiva RUN para asegurarnos de no estar creando capas adicionales.Ejemplo de un Dockerfile con comandos fusionados También puedes usar linters de Docker como Hadolint que te ayudarán con esto y otros anti-patrones que deberías evitar cuando estás creando un Dockerfile.
3.- Opta por docker build — squash
Las últimas versiones del motor de Docker proporcionan una nueva opción cuando construyes tus imágenes para crear con el tamaño minimizado squashing de las capas intermedias que pueden ser creadas como parte del proceso de creación del Dockerfile. Eso funciona, proporcionando una nueva bandera cuando estás haciendo la construcción de tu imagen. Así que, en lugar de hacer esto:
Para poder usar esta opción, debes habilitar las características experimentales en tu Docker Engine. Para hacer eso, necesitas habilitarlo en tu archivo daemon.json y reiniciar el motor. Si estás usando Docker para Windows o Docker para Mac, puedes hacerlo usando la interfaz de usuario como se muestra a continuación:
Resumen
Estos ajustes te ayudarán a hacer tus imágenes de Docker más delgadas y mucho más agradable el proceso de extraer y empujar y, al mismo tiempo, incluso ahorrar algo de dinero con respecto al almacenamiento de las imágenes en el repositorio de tu elección. Y no solo para ti, sino para muchos otros que pueden aprovechar el trabajo que estás haciendo. Así que piensa en ti mismo, pero también piensa en la comunidad.
En el post anterior de esta serie sobre cómo configurar un clúster EKS híbrido utilizando tanto máquinas EC2 tradicionales como opciones sin servidor usando Fargate, pudimos crear el clúster EKS con ambas modalidades de implementación disponibles. ¡Si aún no lo has visto, hazlo ahora! https://medium.com/@alexandrev/hybrid-aws-kubernetes-cluster-using-eks-ec2-and-fargate-13198d864baa En ese punto, tenemos un clúster vacío con todo listo para desplegar nuevas cargas de trabajo, pero aún necesitamos configurar algunas cosas antes de realizar el despliegue. Lo primero es decidir qué cargas de trabajo se van a desplegar usando la opción sin servidor y cuáles usarán la opción tradicional de EC2. Por defecto, todas las cargas de trabajo desplegadas en los espacios de nombres default y kube-system como puedes ver en la imagen a continuación desde la Consola de AWS: Eso significa que todas las cargas de trabajo del espacio de nombres default y del espacio de nombres kube-system se desplegarán de manera sin servidor. Si eso es lo que deseas, perfecto. Pero a veces te gustaría comenzar con un conjunto delimitado de espacios de nombres donde te gustaría usar la opción sin servidor y confiar en el despliegue tradicional. Podemos verificar esa misma información usando eksctl y para hacerlo necesitamos escribir el siguiente comando:
eksctl get fargateprofile --cluster cluster-test-hybrid -o yaml
La salida de ese comando debería ser algo similar a la información que podemos ver en la Consola de AWS:
NOTA: Si no recuerdas el nombre de tu clúster solo necesitas escribir el comando eksctl get clusters
Entonces, esto es lo que vamos a hacer y para hacerlo lo primero que necesitamos hacer es crear un nuevo espacio de nombres llamado “serverless” que va a contener nuestro despliegue sin servidor y para hacerlo usamos un comando kubectl de la siguiente manera:
kubectl create namespace serverless
Y ahora, solo necesitamos crear un nuevo perfil de fargate que va a reemplazar el que tenemos en este momento y para hacerlo necesitamos usar nuevamente eksctl para manejar ese trabajo:
NOTA: También podemos usar no solo el espacio de nombres para limitar el alcance de nuestro despliegue sin servidor sino también etiquetas, por lo que podemos tener en el mismo espacio de nombres cargas de trabajo que se despliegan usando el despliegue tradicional y otras usando la modalidad sin servidor. Eso nos dará todas las posibilidades para diseñar tu clúster como desees. Para hacerlo, añadiremos el argumento labels en un formato clave=valor.
Y obtendremos una salida similar a esta:
[ℹ] creando perfil de Fargate “fp-serverless-profile” en el clúster EKS “cluster-test-hybrid”
[ℹ] creado perfil de Fargate “fp-serverless-profile” en el clúster EKS “cluster-test-hybrid”
Si ahora verificamos el número de perfiles que tenemos disponibles deberíamos obtener dos perfiles manejando tres espacios de nombres (los que son gestionados por el perfil por defecto — default y kube-system — y el que — serverless — es gestionado por el que acabamos de crear ahora) Solo usaremos el siguiente comando para eliminar el perfil por defecto:
Y la salida de ese comando debería ser similar a esta:
[ℹ] eliminado perfil de Fargate “fp-default” en el clúster EKS “cluster-test-hybrid”
Y después de eso, ahora tenemos listo nuestro clúster con un alcance limitado para despliegues sin servidor. En el próximo post de la serie, solo desplegaremos cargas de trabajo en ambas modalidades para ver la diferencia entre ellas. Así que, no te pierdas las actualizaciones sobre esta serie asegurándote de seguir mis publicaciones, y si te gustó el artículo, o tienes algunas dudas o comentarios, por favor deja tus comentarios usando los comentarios a continuación!
Cluster de Kubernetes EKS Fargate AWS: Aprende cómo crear un clúster de Kubernetes que también pueda utilizar todo el poder de la computación sin servidor usando AWS Fargate
Sabemos que hay varios movimientos y paradigmas que nos están empujando fuertemente a cambiar nuestras arquitecturas tratando de aprovechar mucho más los servicios gestionados y cuidando el nivel operativo para que podamos centrarnos en lo que realmente es importante para nuestro propio negocio: crear aplicaciones y entregar valor a través de ellas.
AWS de Amazon ha sido un socio crítico durante ese viaje, especialmente en el mundo de los contenedores. Con el lanzamiento de EKS hace algún tiempo, pudieron proporcionar un servicio de Kubernetes gestionado que todos pueden usar, pero también introduciendo la solución CaaS Fargate también nos da el poder de ejecutar una carga de trabajo de contenedor de manera sin servidor, sin necesidad de preocuparse por nada más.
Pero podrías estar pensando si esos servicios pueden trabajar juntos. Y la respuesta corta es sí. Pero aún más importante que eso, estamos viendo que también pueden trabajar en un modo mixto:
Así que puedes tener un clúster EKS que tiene algunos nodos que son servicios Fargate y algunos nodos que son máquinas EC2 normales para cargas de trabajo que están trabajando de manera con estado o se ajustan mejor a un enfoque tradicional de EC2. Y todo funciona bajo las mismas reglas y es gestionado por el mismo clúster EKS.
Entonces, eso suena increíble, pero, ¿cómo podemos hacer eso? Vamos a ver.
eksctl
Para llegar a ese punto hay una herramienta que necesitamos presentar primero, y esa herramienta se llama eksctl y es una utilidad de línea de comandos que nos ayuda a realizar cualquier acción para interactuar con el servicio EKS y simplifica mucho el trabajo a realizar y también permite automatizar la mayoría de las tareas en un modo no requerido por humanos. Así que, lo primero que necesitamos es tener eksctl listo en nuestras plataformas. Veamos cómo podemos obtener eso.
Aquí tenemos todos los detalles de Amazon sobre cómo instalar eksctl en diferentes plataformas, no importa si estás usando Windows, Linux o MacOS X:
Installing or updating eksctl – Amazon EKS
Learn how to install or update the eksctl command line tool. This tool is used to create and work with an Amazon EKS cluster.
Después de hacer eso, podemos verificar que hemos instalado el software eksctl ejecutando el comando:
eksctl version
Y deberíamos obtener una salida similar a esta:
Salida del comando eksctl version
Así que después de hacer eso, podemos ver que tenemos acceso a todo el poder detrás del servicio EKS simplemente escribiendo estos simples comandos en nuestra ventana de consola.
Creando el Clúster Híbrido EKS
Ahora, vamos a crear un entorno mixto con algunas máquinas EC2 y habilitar el soporte Fargate para EKS. Para hacer eso, comenzaremos con el siguiente comando:
eksctl create cluster --version=1.15 --name=cluster-test-hybrid --region=eu-west-1 --max-pods-per-node=1000 --fargate
[ℹ] eksctl version 0.26.0
[ℹ] usando la región eu-west-1
[ℹ] configurando zonas de disponibilidad a [eu-west-1c eu-west-1a eu-west-1b]
[ℹ] subredes para eu-west-1c - pública:192.168.0.0/19 privada:192.168.96.0/19
[ℹ] subredes para eu-west-1a - pública:192.168.32.0/19 privada:192.168.128.0/19
[ℹ] subredes para eu-west-1b - pública:192.168.64.0/19 privada:192.168.160.0/19
[ℹ] usando la versión de Kubernetes 1.15
[ℹ] creando el clúster EKS "cluster-test-hybrid" en la región "eu-west-1" con perfil Fargate
[ℹ] si encuentras algún problema, revisa la consola de CloudFormation o intenta 'eksctl utils describe-stacks --region=eu-west-1 --cluster=cluster-test-hybrid'
[ℹ] el registro de CloudWatch no estará habilitado para el clúster "cluster-test-hybrid" en "eu-west-1"
[ℹ] puedes habilitarlo con 'eksctl utils update-cluster-logging --region=eu-west-1 --cluster=cluster-test-hybrid'
[ℹ] el acceso al punto final de la API de Kubernetes usará el valor predeterminado de {publicAccess=true, privateAccess=false} para el clúster "cluster-test-hybrid" en "eu-west-1"
[ℹ] 2 tareas secuenciales: { crear el plano de control del clúster "cluster-test-hybrid", crear perfiles fargate }
[ℹ] construyendo la pila del clúster "eksctl-cluster-test-hybrid-cluster"
[ℹ] desplegando la pila "eksctl-cluster-test-hybrid-cluster"
[ℹ] creando el perfil Fargate "fp-default" en el clúster EKS "cluster-test-hybrid"
[ℹ] creado el perfil Fargate "fp-default" en el clúster EKS "cluster-test-hybrid"
[ℹ] "coredns" ahora es programable en Fargate
[ℹ] "coredns" ahora está programado en Fargate
[ℹ] los pods de "coredns" ahora están programados en Fargate
[ℹ] esperando la disponibilidad del plano de control...
[✔] guardado kubeconfig como "C:Usersavazquez/.kube/config"
[ℹ] sin tareas
[✔] todos los recursos del clúster EKS para "cluster-test-hybrid" han sido creados
[ℹ] el comando kubectl debería funcionar con "C:Usersavazquez/.kube/config", intenta 'kubectl get nodes'
[✔] el clúster EKS "cluster-test-hybrid" en la región "eu-west-1" está listo
Este comando configurará el clúster EKS habilitando el soporte Fargate.
NOTA: Lo primero que deberíamos notar es que el soporte Fargate para EKS aún no está disponible en todas las regiones de AWS. Por lo tanto, dependiendo de la región que estés utilizando, podrías obtener un error. En este momento, esto solo está habilitado en US East (N. Virginia), US East (Ohio), US West (Oregon), Europa (Irlanda), Europa (Frankfurt), Asia Pacífico (Singapur), Asia Pacífico (Sídney), Asia Pacífico (Tokio) según la información de los Anuncios de AWS: https://aws.amazon.com/about-aws/whats-new/2020/04/eks-adds-fargate-support-in-frankfurt-oregon-singapore-and-sydney-aws-regions/
Así que, ahora, deberíamos agregar a ese clúster un Grupo de Nodos. Un Grupo de Nodos es un conjunto de instancias EC2 que van a ser gestionadas como parte de él. Y para hacer eso, utilizaremos el siguiente comando:
eksctl create nodegroup --cluster cluster-test-hybrid --managed
[ℹ] eksctl version 0.26.0
[ℹ] usando la región eu-west-1
[ℹ] se usará la versión 1.15 para el/los nuevo(s) grupo(s) de nodos basado en la versión del plano de control
[ℹ] el grupo de nodos "ng-1262d9c0" está presente en la configuración dada, pero falta en el clúster
[ℹ] 1 grupo de nodos (ng-1262d9c0) fue incluido (basado en las reglas de inclusión/exclusión)
[ℹ] se creará una pila de CloudFormation para cada uno de los 1 grupos de nodos gestionados en el clúster "cluster-test-hybrid"
[ℹ] 2 tareas secuenciales: { corregir la compatibilidad del clúster, 1 tarea: { 1 tarea: { crear grupo de nodos gestionado "ng-1262d9c0" } } }
[ℹ] comprobando la pila del clúster para recursos faltantes
[ℹ] la pila del clúster tiene todos los recursos requeridos
[ℹ] construyendo la pila del grupo de nodos gestionado "eksctl-cluster-test-hybrid-nodegroup-ng-1262d9c0"
[ℹ] desplegando la pila "eksctl-cluster-test-hybrid-nodegroup-ng-1262d9c0"
[ℹ] sin tareas
[✔] creado 0 grupo(s) de nodos en el clúster "cluster-test-hybrid"
[ℹ] el grupo de nodos "ng-1262d9c0" tiene 2 nodo(s)
[ℹ] el nodo "ip-192-168-69-215.eu-west-1.compute.internal" está listo
[ℹ] el nodo "ip-192-168-9-111.eu-west-1.compute.internal" está listo
[ℹ] esperando que al menos 2 nodo(s) estén listos en "ng-1262d9c0"
[ℹ] el grupo de nodos "ng-1262d9c0" tiene 2 nodo(s)
[ℹ] el nodo "ip-192-168-69-215.eu-west-1.compute.internal" está listo
[ℹ] el nodo "ip-192-168-9-111.eu-west-1.compute.internal" está listo
[✔] creado 1 grupo(s) de nodos gestionado(s) en el clúster "cluster-test-hybrid"
[ℹ] comprobando la configuración del grupo de seguridad para todos los grupos de nodos
[ℹ] todos los grupos de nodos tienen la configuración actualizada
Así que ahora deberíamos poder usar kubectl para gestionar este nuevo clúster. Si no tienes instalado kubectl o no has oído hablar de él. Esta es la herramienta de línea de comandos que nos permite gestionar tu Clúster de Kubernetes y puedes instalarla basándote en la documentación mostrada aquí:
Installing or updating eksctl – Amazon EKS
Learn how to install or update the eksctl command line tool. This tool is used to create and work with an Amazon EKS cluster.
Así que, ahora, deberíamos empezar a echar un vistazo a la infraestructura que tenemos. Así que si escribimos el siguiente comando para ver los nodos a nuestra disposición:
kubectl get nodes
Vemos una salida similar a esta:
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-102-22.eu-west-1.compute.internal Ready <none> 10m v1.15.10-eks-094994
fargate-ip-192-168-112-125.eu-west-1.compute.internal Ready <none> 10m v1.15.10-eks-094994
ip-192-168-69-215.eu-west-1.compute.internal Ready <none> 85s v1.15.11-eks-bf8eea
ip-192-168-9-111.eu-west-1.compute.internal Ready <none> 87s v1.15.11-eks-bf8eea
Como puedes ver, tenemos 4 “nodos”, dos que comienzan con el nombre fargate que son nodos fargate y dos que solo comienzan con ip-… y esos son las instancias EC2 tradicionales. Y después de ese momento, eso es todo, tenemos nuestro entorno mixto listo para usar.
Podemos verificar el mismo clúster usando la página de AWS EKS para ver esa configuración con más detalle. Si ingresamos en la página de EKS para este clúster, vemos en la pestaña de Computación la siguiente información:
Vemos bajo Grupos de Nodos los datos sobre las máquinas EC2 que son gestionadas como parte de este clúster y como puedes ver vimos 2 como la Capacidad Deseada y por eso tenemos 2 instancias EC2 en nuestro clúster. Y con respecto al perfil Fargate, vemos los espacios de nombres configurados como predeterminado y kube-system y eso significa que todos los despliegues a esos espacios de nombres se van a desplegar usando Tareas Fargate.
Resumen
En los siguientes artículos de esta serie, veremos cómo progresar en nuestro clúster Híbrido, desplegar cargas de trabajo, escalarlo en función de la demanda que estamos recibiendo, habilitar la integración con otros servicios como AWS CloudWatch, y así sucesivamente. Así que, mantente atento, y no olvides seguir mis artículos para no perderte ninguna nueva actualización tan pronto como esté disponible para ti.
Lograr los beneficios de una inversión en TI es mucho más que solo comprar o implementar una tecnología. Aprende cómo puedes estar preparado para eso.
Si hay una sola verdad que este año ha proporcionado a la mayoría de las empresas es que vivimos en un mundo digital. Ya no es el futuro.
Para estar preparados para este presente, la mayoría de las empresas de todos los sectores han invertido mucho en tecnología. Han escuchado todos los beneficios que los últimos desarrollos en tecnología han proporcionado a algunas empresas y les gustaría obtener los mismos beneficios.
Pero después de un tiempo, intentaron implementar los mismos principios y herramientas y no están viendo los beneficios. Seguro, vieron alguna mejora, pero nada comparado con lo que esperaban. ¿Por qué está sucediendo esto? ¿Por qué algunas de estas empresas no están siendo capaces de desbloquear estos logros?
Una herramienta es una herramienta, nada más.
Cualquier principio o herramienta tecnológica, no importa si estamos hablando de un nuevo paradigma como la contenedorización o sin servidor, o una herramienta como una plataforma de gestión de API o una nueva arquitectura impulsada por eventos, son solo herramientas en manos de las personas.
Y, al final, lo que más importa es la forma en que esas personas trabajan y cómo usan las herramientas que tienen a mano para lograr los beneficios óptimos. Las empresas tienen computadoras desde hace quizás 30 años, ¿recuerdas cómo era el uso inicial de esas computadoras? ¿Crees que la gente en ese momento las usaba al nivel óptimo? Entonces, aquí es lo mismo.
No deberías esperar que solo porque has instalado una herramienta, implementado una nueva tecnología o comprado una nueva aplicación SaaS, en ese momento exacto la vida de tu empresa va a cambiar y vas a desbloquear todos los beneficios que vienen con ella. Es la misma historia que una agenda no te hará más productivo solo porque tienes una.
Sí, es un requisito, pero esto está lejos de ser el único paso que necesitas dar para poder lograr el éxito de esa inversión.
Lo que importa es tu forma de pensar
Un nuevo paradigma en TI requiere una forma diferente de pensar, una sensación de confianza en este paradigma para poder desbloquear esos beneficios.
Si no lo haces de esa manera, serás tú quien detenga el progreso y bloquee los beneficios que puedes obtener. Y eso siempre es difícil al principio. Al principio, si tenemos una fórmula hecha en Excel y la misma en papel, creemos que la del ordenador estaba equivocada.
Hoy es al revés. Sabemos con certeza que el ordenador lo está haciendo bien, así que tratamos de encontrar nuestro propio error para obtener el mismo resultado.
Algunos gerentes de TI ahora tienen la misma sensación con otras técnicas y tratan de gestionarlas y controlarlas usando los mismos principios que siempre han aplicado. Y seamos honestos: Eso es normal y es humano porque todos tratamos de usar los patrones que conocemos y los que han demostrado ser exitosos en el pasado cuando enfrentamos algo similar.
Pero, seamos honestos: ¿Crees que Netflix o Uber tuvieron éxito usando los mismos patrones y reglas que han estado usando en el camino? Por supuesto que no.
Pero tal vez pienses que no es una comparación justa porque tu empresa o tu sector no está en juego y en medio de una revolución, solo necesitas pequeños cambios para obtener esos beneficios. No necesitas hacer todo desde cero. Y eso es cierto.
Al final, lo que es relevante es si estás listo para dar el salto de fe al vacío. Para introducirte en la jungla solo con tu intuición y el conocimiento que has adquirido hasta ahora para guiarte durante ese camino.
Sé un investigador
En realidad, el salto al vacío es necesario, pero esto se refiere más a la forma en que piensas. Es estar listo para abrir tu mente y dejar atrás algunos prejuicios que puedas tener. Al final, esto es más similar a ser Marie Curie que a Indiana Jones.
Los investigadores y científicos siempre necesitan estar abiertos a una forma diferente de hacer las cosas. Tienen sus bases, su experiencia, el conocimiento de todo lo que se ha hecho en el pasado, pero para ir un paso más allá necesitan pensar fuera de la caja y estar abiertos a cosas que no eran ciertas hace varios años o cosas que no eran la forma correcta de hacerlo hasta ahora. Porque estás yendo más allá de lo que nadie ha ido.
TI es similar, no estás entrando en lo desconocido, pero dentro de tu empresa tal vez seas tú quien necesite guiar a todos los demás durante esa ruta y estar abierto a pensar que tal vez las viejas reglas no se aplican a esta nueva revolución y estar listo para dejar algunas prácticas antiguas para desbloquear mayores beneficios.
Resumen
Al final, cuando adoptas una nueva tecnología, necesitas pensar en las implicaciones que esa tecnología requiere para hacerla exitosa o incluso optimizar los beneficios que puedes obtener de ella.
Pensar en otros que han recorrido ese camino y aprender de sus aciertos y sus errores, para que puedas estar preparado y también ser realista. Si no vas a realizar el cambio que la tecnología requiere en tu organización, la inversión no tiene sentido. Necesitas trabajar primero en preparar a tu organización para estar lista para el cambio, y ese momento es el momento de introducirte en la jungla y obtener todos los beneficios que te están esperando.
Cómo lograr verdaderamente la agilidad en su organización enfocándose en lo que importa para su negocio y multiplicar la productividad de su equipo de desarrollo
La moda es cíclica y lo mismo ocurre en la Ingeniería de Software. Vivimos en un mundo donde cada innovación parece similar a una del pasado; avanzamos hace algún tiempo. Eso se debe a que lo que estamos haciendo es simplemente refinar una y otra vez soluciones para los mismos problemas.
Hemos vivido en los últimos años un auge de «el desarrollador es el nuevo negro», donde cualquier cosa relacionada con escribir código es excelente. Incluso los desarrolladores ahora son vistos como un personaje genial como los de Silicon Valley (el programa de HBO) en lugar de ser objeto de burla como en The I.T Crowd.
Pero, ahora, parece que estamos volviendo a un nuevo auge de lo que se llama Aplicaciones de Bajo Código (o Sin Código).
Una Aplicación de Bajo Código es un software que te ayuda a generar tus aplicaciones o servicios sin necesidad de escribir código en ningún lenguaje de programación, en lugar de hacer eso, puedes arrastrar y soltar algunas cajas que representan lo que te gustaría hacer en lugar de escribirlo tú mismo.
Eso ha proporcionado ventajas que ahora están nuevamente sobre la mesa. Echemos un vistazo a esas ventajas con más detalle.
1.- Proporciona más agilidad
Eso está claro. No importa cuán alto sea el nivel de tu lenguaje de programación, no importa cuántos arquetipos tengas para generar el esqueleto de tu proyecto o el marco y las bibliotecas que uses. Escribir siempre es más lento que arrastrar algunas cajas sobre el lienzo blanco y conectarlas con algunos enlaces.
Y soy una persona que es un tipo de terminal y usuario avanzado de VI, y me doy cuenta del poder del teclado, pero seamos honestos y hagamos una pregunta:
¿Cuántas de las palabras clave que escribes en tu código están proporcionando valor al negocio y cuántas son necesarias solo por razones técnicas?
No solo cosas como el manejo de excepciones, auditoría, registro, descubrimiento de servicios, gestión de configuración, sino cosas como la estructura de bucles, definición de firmas de funciones, definición de variables, definición de clases, y así sucesivamente…
Puedes enfocarte verdaderamente en el valor comercial que estás tratando de proporcionar a tu negocio en lugar de pasar tiempo en cómo gestionar cualquier capacidad técnica.
2.- Más fácil de mantener
Un mes después de la producción solo el desarrollador y dios saben lo que hace el código. Después de un año, solo dios sabe…
Codificar es increíble, pero al mismo tiempo es complejo de mantener. Principalmente en las empresas cuando los desarrolladores están cambiando de un proyecto a otro, de algunos departamentos a otros, y nuevas personas se están incorporando todo el tiempo para mantener y evolucionar algunos códigos.
Y los que han estado en la industria por algún tiempo, conocen por ejemplo la situación cuando la gente dice: “Prefiero no tocar eso porque no sabemos qué está haciendo”, “No podemos migrar esta aplicación de Mainframe porque no sabemos si podrá capturar toda la funcionalidad que están proporcionando.”
Y eso es malo por varias razones. En primer lugar, es costoso de mantener, más complejo de hacerlo, pero en segundo lugar también te impide evolucionar al ritmo que deseas hacerlo.
3.- Más seguro y rentable
No me malinterpretes sobre esto: Programar puede ser tan seguro como cualquier aplicación de bajo código. Eso está claro porque, al final, cualquier aplicación de bajo código termina generando el mismo binario o bytecode para ser ejecutado.
El problema es que esto va a depender de las habilidades del programador. Vivimos en una situación que, incluso programar y los desarrolladores son algo genial, ya que necesitas un gran número de desarrolladores en tu equipo, lo que implica que no todos ellos son tan experimentados y hábiles como quisieras que fueran.
La realidad es mucho más compleja y también necesitas lidiar con la realidad de tu presupuesto y encontrar la manera de obtener lo mejor de tu equipo.
Usando una aplicación de bajo código, tienes garantizada la calidad de los componentes base que son verificados por una empresa y que han mejorado con equipos dedicados incorporando comentarios de clientes de todo el mundo, lo que la hace más segura.
4.- Tan lista como una solución basada en código para necesidades específicas
Uno de los mitos que se dicen contra el Bajo Código es que es adecuado para cargas de trabajo y casos de uso genéricos, pero no es capaz de adaptarse y optimizarse para tus necesidades.
Con respecto a esta resistencia habitual, en primer lugar, necesitamos trabajar en la idea errónea del nivel de especificación que necesita nuestro software. Al final, las veces que necesitas hacer algo tan específico que no está cubierto por las opciones disponibles de inmediato son tan pocas que es complejo justificarlo. ¿Vas a hacer más lento el 99% de tu desarrollo solo para poder hacerlo más rápido en un 1%? ¿Cuánto de tus cargas de trabajo no son similares a lo que otras empresas están haciendo en la misma industria?
Pero incluso por el bien de la discusión, asumamos que eso es cierto, y necesitas una sola pieza de lógica que una aplicación de bajo código no proporciona de inmediato. Ok, Bajo Código significa que no necesitas escribir código, no que no puedas hacerlo.
La mayoría de las plataformas admiten la opción de agregar código si es necesario como una opción para cubrir estos casos. Entonces, incluso en esos casos, todavía tienes las mismas herramientas para hacerlo específico sin perder todas las ventajas de tus actividades diarias.
Resumen
Las aplicaciones de bajo código son una de las soluciones que tienes a tu disposición para mejorar tu agilidad y tu productividad en tus desarrollos para seguir el ritmo de los cambios en tu negocio.
Las soluciones que trabajan en ese espacio no son nuevas, pero han sido renovadas para adaptarse a los paradigmas modernos de los desarrolladores (microservicios, basados en contenedores, dirigidos por API, impulsados por eventos…) por lo que no vas a perder nada, sino a ganar más tiempo para proporcionar aún más valor a tu negocio.
Aprende sobre las ventajas y desventajas de un enfoque sin servidor para tomar la decisión correcta para tu pila tecnológica
Serverless es un tema apasionante para muchas personas, y es algo que ha evolucionado mucho desde su concepción. Comenzó siendo un enfoque para deshacerse de los servidores, no en el lado técnico (obviamente) sino en el lado de la gestión.
La idea detrás de esto es hacer que los desarrolladores, y las personas de TI en general, se concentren en crear código y desplegarlo en algún tipo de infraestructura gestionada. La contraposición habitual era contra plataformas basadas en contenedores. Con servicios de Kubernetes gestionados, como EKS o AKS, todavía eres responsable de los trabajadores que están ejecutando tu carga. No necesitas preocuparte por el componente de administración. Pero, de nuevo, necesitas manejar y gestionar algunas partes de la infraestructura.
Este enfoque también se incorporó en otros sistemas, como iPaaS y ofertas puras de SaaS en cuanto a low code o no code. E incluimos el concepto de función como servicio para marcar la diferencia en este enfoque. Entonces, la primera pregunta es: ¿Cuál es la principal diferencia entre una función que despliegas en tu proveedor sin servidor y una aplicación que puedes usar en tu iPaaS?
Depende de la perspectiva que quieras analizar.
Voy a omitir los detalles técnicos sobre capacidades de escalar a cero, técnicas de calentamiento, etc., y me centraré en la perspectiva del usuario. La principal diferencia es cómo estos servicios te van a cobrar en función de tu uso.
iPaaS u ofertas similares de SaaS te van a cobrar en función de la instancia de la aplicación o algo similar. Pero la plataforma sin servidor/función como servicio te va a costar en función del uso que hagas de esa función. Eso significa que te van a cobrar en función del número de solicitudes que reciba tu función.
Eso es un cambio de juego. Proporciona la implementación más precisa de las operaciones optimizadas y el enfoque de elasticidad. En este caso, es directo y claro que solo vas a pagar por el uso de tu plataforma. La economía es excelente. Echa un vistazo a la oferta de AWS Lambda hoy:
El nivel de uso gratuito de AWS Lambda incluye 1 millón de solicitudes gratuitas por mes y 400,000 GB-segundos de tiempo de cómputo por mes.
Y después de ese primer millón de solicitudes, te van a cobrar 0.20 $ por cada millón de solicitudes adicionales.
Al leer las oraciones anteriores, probablemente estés pensando: «Eso es perfecto. ¡Voy a migrar todo a ese enfoque!»
No tan rápido. Este estilo de arquitectura no es válido para todos los servicios que puedas tener. Aunque la economía es excelente, estos servicios vienen con limitaciones y anti-patrones que significan que deberías evitar esta opción.
Primero, comencemos con las restricciones que la mayoría de los proveedores de la nube definen para este tipo de servicios:
Tiempo de ejecución: Esto suele estar limitado por tu proveedor de la nube a un número máximo de segundos de ejecución. Eso es justo. Si te van a cobrar por solicitud, y puedes hacer todo el trabajo en una sola solicitud que tarda 10 horas en completarse utilizando los recursos del proveedor, ¡probablemente eso no sea justo para el proveedor!
Recursos de memoria: También limitados, por las mismas razones.
Carga útil de la interfaz: Algunos proveedores también limitan la carga útil que puedes recibir o enviar como parte de una función, algo a tener en cuenta cuando estás definiendo el estilo de arquitectura para tu carga de trabajo.
En un momento, veremos los anti-patrones o cuándo deberías evitar usar esta arquitectura y enfoque
Pero primero, una breve introducción a cómo funciona esto a nivel técnico. Esta solución puede ser muy económica porque el tiempo que tu función no está procesando ninguna solicitud no está cargado en sus sistemas. Por lo tanto, no está utilizando ningún recurso en absoluto (solo una pequeña parte de almacenamiento, pero esto es algo ridículo) y generando cualquier costo para el proveedor de la nube. Pero eso también significa que cuando alguien necesita ejecutar tu función, el sistema necesita recuperarla, lanzarla y procesar la solicitud. Eso generalmente se llama el «tiempo de calentamiento», y su duración depende de la tecnología que uses.
Servicios de baja latencia y Servicios con tiempo de respuesta crítico: Si tu servicio necesita baja latencia o el tiempo de respuesta debe ser agresivo, este enfoque probablemente no va a funcionar para ti debido al tiempo de calentamiento. Sí, hay soluciones alternativas para resolver esto, pero requieren solicitudes ficticias al servicio para mantenerlo cargado y generan costos adicionales.
Proceso por lotes o programado: Esto es para API sin estado para el mundo nativo de la nube. Si tienes un proceso por lotes que podría llevar tiempo, tal vez porque está programado por las noches o los fines de semana, podría no ser la mejor idea ejecutar este tipo de carga de trabajo.
Servicios masivos: Si pagas por solicitud, es importante evaluar el número de solicitudes que tu servicio va a recibir para asegurarte de que los números todavía estén a tu favor. Si tienes un servicio con millones de solicitudes por segundo, probablemente este no sea el mejor enfoque para tu presupuesto de TI.
Al final, serverless/función como servicio es tan genial por su simplicidad y lo económico que es. Al mismo tiempo, no es una bala de plata para cubrir todas tus cargas de trabajo.
Necesitas equilibrarlo con otros enfoques arquitectónicos y plataformas basadas en contenedores, o ofertas de iPaaS y SaaS, para mantener tu caja de herramientas llena de opciones para encontrar la mejor solución para cada patrón de carga de trabajo que tenga tu empresa.
La agregación de registros ya no es una mercancía, sino un componente crítico en plataformas basadas en contenedores
La gestión de registros no parece un tema muy fantástico. No es el tema que ves y dices: “¡Oh! ¡Increíble! Esto es con lo que he soñado toda mi vida”. No, soy consciente de que esto no es muy atractivo, pero eso no lo hace menos crítico que otras capacidades que tu arquitectura necesita tener.
Desde el principio de los tiempos, hemos usado archivos de registro como la única fuente de datos confiable cuando se trataba de solucionar problemas de tus aplicaciones o saber qué falló en tu implementación o cualquier otra acción relacionada con una computadora.
El procedimiento era fácil:
Lanzar “algo”
“Algo” falló.
Revisar los registros
Cambiar algo
Repetir
Y lo hemos estado haciendo de esa manera durante mucho, mucho tiempo. Incluso con otros enfoques más robustos de manejo y gestión de errores como el Sistema de Auditoría, también volvemos a los registros cuando necesitamos obtener el detalle minucioso sobre el error. Buscar una traza de pila allí, más detalle sobre el error que se insertó en el Sistema de Auditoría o más datos que solo el código de error y la descripción que proporcionó una API REST.
Los sistemas comenzaron a crecer, la arquitectura se volvió más complicada, pero incluso con eso, terminamos con el mismo método una y otra vez. Estás al tanto de arquitecturas de agregación de registros como la pila ELK o soluciones comerciales como Splunk o incluso ofertas SaaS como Loggly, pero simplemente piensas que no son para ti.
Son caras de comprar o caras de configurar, y conoces muy bien tu ecosistema, y es más fácil simplemente entrar en una máquina y seguir el archivo de registro. Probablemente también tengas tu caja de herramientas de scripts para hacer esto tan rápido como cualquiera puede abrir Kibana e intentar buscar algo como el ID de instancia allí para ver el error de una transacción específica.
Ok, necesito decirte algo: Es hora de cambiar, y te voy a explicar por qué.
Las cosas están cambiando, y TI y todos los nuevos paradigmas se basan en algunos fundamentos comunes:
Vas a tener más componentes que van a funcionar aislados con sus archivos de registro y datos.
Las implementaciones serán más regulares en tu entorno de producción, y eso significa que las cosas van a estar mal más a menudo (de una manera controlada, pero más a menudo)
Las tecnologías van a coexistir, por lo que los registros van a ser muy diferentes en términos de patrones y diseños, y necesitas estar preparado para eso.
Así que, discutamos estos tres argumentos que espero te hagan pensar de una manera diferente sobre las arquitecturas y enfoques de Gestión de Registros.
1.- Tu enfoque simplemente no escalable
Tu enfoque es excelente para sistemas tradicionales. ¿Cuántas máquinas gestionas? ¿30? ¿50? ¿100? Y puedes hacerlo bastante bien. Imagina ahora una plataforma basada en contenedores para una empresa típica. Creo que un número promedio podría ser alrededor de 1000 contenedores solo para propósitos comerciales, sin hablar de arquitectura o servicios básicos. ¿Eres capaz de estar listo para ir contenedor por contenedor para verificar 1000 flujos de registros para conocer el error?
Incluso si eso es posible, ¿vas a ser el cuello de botella para el crecimiento de tu empresa? ¿Cuántos registros de contenedores puedes seguir? ¿2000? Como decía al principio, eso simplemente no es escalable.
2.- Los registros no están allí para siempre
Y ahora, lees el primer tema y probablemente solo estás diciendo a la pantalla que estás usando para leer esto. ¡Vamos! Ya sé que los registros no están allí, se están rotando, se pierden, y así sucesivamente.
Sí, eso es cierto, esto es aún más importante en el enfoque nativo de la nube. Con plataformas basadas en contenedores, los registros son efímeros, y además, si seguimos el manifiesto de la aplicación de 12 factores, no hay archivo con el registro. Todas las trazas de registro deben imprimirse en la salida estándar, y eso es todo.
¿Y dónde se eliminan los registros? Cuando el contenedor falla… ¿y cuáles son los registros que más necesitas? Los que han fallado.
Así que, si no haces nada, las trazas de registro que más necesitas son las que vas a perder.
3.- Necesitas poder predecir cuándo las cosas van a fallar
Pero los registros no solo son válidos cuando algo sale mal, son adecuados para detectar cuándo algo va a estar mal, sino para predecir cuándo las cosas van a fallar. Y necesitas poder agregar esos datos para poder generar información y conocimientos a partir de ellos. Para poder ejecutar modelos de ML para detectar si algo va como se espera o si algo diferente está sucediendo que podría llevar a algún problema antes de que ocurra.
Resumen
Espero que estos argumentos te hayan hecho pensar que incluso para tu empresa de pequeño tamaño o incluso para tu sistema, necesitas poder configurar una técnica de Agregación de Registros ahora y no esperar a otro momento cuando probablemente sea demasiado tarde.
Descubra cómo TIBCO Cloud Integration puede ayudarle a aumentar la agilidad empresarial conectando todas sus aplicaciones, dispositivos y datos sin importar dónde estén alojados
Vivimos en un mundo donde el número de activos digitales que necesitan ser integrados, los tipos de activos y dónde están alojados están explotando. Hemos pasado de un panorama empresarial simple donde todos nuestros sistemas estaban alojados en un solo centro de datos, y el número de sistemas era pequeño. Si aún recuerda esos días, probablemente podría nombrar todos los sistemas que mantenía. ¿Podría imaginarse haciendo eso hoy?
Esto ha cambiado completamente. Las empresas hoy en día operan cada vez más en aplicaciones y datos en lugar de en procesos manuales documentados, y eso ha aumentado las demandas para tenerlos conectados para apoyar las operaciones del negocio. ¿Cómo puede un equipo de TI tradicional mantenerse al día con todas las solicitudes de conectividad provenientes de todas las áreas del negocio para asegurar que estos activos estén completamente integrados y funcionen sin problemas?
Además, el entorno empresarial ha cambiado completamente. Hoy en día todo está hiperacelerado. Ya no puede esperar seis meses para poner en línea sus nuevas promociones de marketing o para introducir nuevos servicios digitales.
Esto se debe a que los mercados cambian constantemente con el tiempo. A veces crecen, y otras veces se contraen. Esto obligó a las empresas a cambiar rápidamente la forma en que hacen negocios.
Entonces, si necesitamos resumir todo lo que necesitamos de una arquitectura de aplicaciones para asegurarnos de que pueda ayudarnos a cumplir con nuestros requisitos empresariales, esa palabra es «agilidad». Y la agilidad arquitectónica crea agilidad empresarial.
Se han adoptado diferentes paradigmas de TI para ayudar a aumentar la agilidad arquitectónica desde diferentes perspectivas que proporcionan una forma rápida de adaptarse, conectarse y ofrecer nuevas capacidades a los clientes:
Agilidad de Infraestructura: Basada en la adopción de la nube, los proveedores de nube ofrecen una forma ágil de aprovechar inmediatamente la capacidad de infraestructura requerida, permitiendo una rápida innovación al crear rápidamente nuevos entornos y desplegar nuevos servicios bajo demanda.
Agilidad de Operación y Gestión: Las aplicaciones basadas en SaaS le permiten adoptar suites empresariales de mejor calidad sin tener que adquirir y gestionar la infraestructura subyacente, como lo hace en su enfoque local. Esto le permite agilizar y acelerar las operaciones de su negocio.
Agilidad de Desarrollo: Basada en las tecnologías de aplicaciones que crean componentes de software pequeños y altamente escalables que pueden evolucionarse, desplegarse y gestionarse de manera autónoma. Este enfoque integra capacidades de integración directamente dentro de las aplicaciones desplegadas, haciendo que la integración ya no sea una capa separada, sino algo que está incorporado dentro de cada componente. Los conceptos de microservicios, desarrollo liderado por API y arquitectura impulsada por eventos juegan un papel esencial y expanden las personas involucradas en el proceso de desarrollo.
Entonces, todas estas formas de agilidad ayudan a construir una arquitectura de aplicaciones que es altamente ágil, capaz de responder rápidamente a los cambios en el entorno en el que opera. Y puede lograr todas ellas con TIBCO® Cloud Integration (TCI).
TCI es una Plataforma de Integración como Servicio (iPaaS), una solución de integración basada en la nube que hace extremadamente fácil para usted conectar todos sus activos sin importar dónde estén alojados. Es una oferta SaaS que se ejecuta tanto en AWS como en Microsoft Azure, por lo que no tiene que gestionar la infraestructura subyacente para asegurarse de que los activos de integración que son críticos para su negocio estén siempre disponibles y se escalen a cualquier nivel de demanda.
Desde la perspectiva del desarrollo, TCI le proporciona todas las herramientas necesarias para que su negocio desarrolle y conecte todos sus activos digitales, incluidas sus aplicaciones, fuentes de datos, dispositivos, suites empresariales, procesos y soluciones SaaS, utilizando los estándares más modernos dentro de una experiencia inmersiva.
Aborda patrones de integración desde enfoques tradicionales, como en la replicación de datos, hasta enfoques modernos, incluyendo arquitecturas lideradas por API e impulsadas por eventos. También admite los últimos estándares de conectividad como REST, GraphQL, AsyncAPI y gRPC. Y para reducir el tiempo de comercialización de sus integraciones, también incluye un número significativo de conectores preempaquetados que simplifican la conectividad a suites empresariales heredadas y modernas, fuentes de datos y más, sin importar si residen en su centro de datos o en la nube. Estos conectores son fácilmente accesibles dentro de un mercado de conectores integrado directamente en la experiencia del usuario para ser utilizados en toda la plataforma.
TCI mejora el desarrollo basado en equipos. Con TIBCO® Cloud Mesh, accesible a través de TCI, sus integradores pueden compartir, descubrir y reutilizar fácilmente activos digitales creados en toda la empresa dentro de TIBCO Cloud, como APIs y aplicaciones, y utilizarlos muy rápidamente dentro de las integraciones de manera segura sin necesidad de preocuparse por aspectos técnicos.
Esta capacidad promueve la reutilización de activos existentes y una mejor colaboración entre equipos. Combinado con conectores preempaquetados que son directamente accesibles dentro de TCI, el tiempo de desarrollo para introducir nuevas integraciones se reduce significativamente.
Acceda fácilmente a conectores preempaquetados dentro de un mercado de conectores integrado
TCI también amplía el número de personas en su negocio que pueden crear integraciones, con múltiples experiencias de desarrollo que están adaptadas para diferentes roles, proporcionando su propia experiencia y habilidades. Ahora no solo los especialistas en integración pueden participar en el proceso de integración, sino también los desarrolladores, propietarios de productos API e integradores ciudadanos.
Esto aumenta drásticamente la agilidad empresarial porque sus diversas unidades de negocio pueden crear integraciones de manera autoservicio, colaborar para proporcionar soluciones incluso si abarcan diferentes unidades de negocio, y reducir sus dependencias en equipos de TI sobrecargados. Esto libera a sus especialistas en integración para que se concentren en proporcionar las mejores prácticas de integración para su empresa y en diseñar una arquitectura de aplicaciones receptiva.
TCI aborda una serie de casos de uso de integración, incluyendo:
Conectar aplicaciones, datos y dispositivos que residen en cualquier lugar (por ejemplo, en las instalaciones, SaaS, nube privada/pública)
Diseñar, orquestar y gestionar APIs y microservicios
Rearquitecturar aplicaciones monolíticas inflexibles en aplicaciones nativas de la nube altamente escalables.
Construir aplicaciones impulsadas por eventos que procesan flujos de datos (por ejemplo, de dispositivos IoT o Apache Kafka)
TCI también proporciona información detallada sobre el rendimiento y el estado de ejecución de sus integraciones para que pueda optimizarlas según sea necesario o detectar y resolver fácilmente cualquier problema potencial con ellas. Esto asegura que los procesos empresariales que dependen de sus integraciones se vean mínimamente interrumpidos.
Obtenga vistas rápidas de la ejecución de aplicaciones y detalles de rendimiento.Profundice para obtener información ampliada sobre los historiales de ejecución de aplicaciones y las tendencias de rendimiento.
Al incorporar a más personas en su proceso de integración, empoderándolas con una vista inmersiva que les ayuda a trabajar juntos sin problemas en sus integraciones, proporcionando capacidades como TIBCO Cloud Mesh y conectores preempaquetados dentro de un mercado de conectores unificado que acelera el desarrollo de integraciones, su negocio digital puede conectarse y reconectarse muy rápidamente para responder a los mercados cambiantes, lo que aumenta enormemente su agilidad empresarial.
Para experimentar lo fácil que es conectar todos sus activos digitales para aumentar su agilidad empresarial, regístrese hoy para una prueba gratuita de 30 días de TIBCO Cloud Integration.
TIBCO Cloud Integration es un servicio proporcionado dentro de la Plataforma de Inteligencia Conectada de TIBCO, que proporciona un conjunto completo de capacidades para conectar su negocio.
