Beneficios de TI: ¿Por qué algunas empresas nunca pueden lograr los beneficios de su inversión?

Beneficios de TI: ¿Por qué algunas empresas nunca pueden lograr los beneficios de su inversión?

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.

Cuatro razones por las que las aplicaciones de bajo código pueden ayudarte a aumentar tu productividad

Cuatro razones por las que las aplicaciones de bajo código pueden ayudarte a aumentar tu productividad

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.

Beneficios de Serverless: Principales Ventajas Desde la Perspectiva Empresarial

Beneficios de Serverless: Principales Ventajas Desde la Perspectiva Empresarial

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.

Tres razones por las que necesitas una arquitectura de agregación de registros hoy

Tres razones por las que necesitas una arquitectura de agregación de registros hoy

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.

Mayor agilidad a través de la conectividad digital moderna

Mayor agilidad a través de la conectividad digital moderna

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.

Mayor agilidad a través de la conectividad digital moderna
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:

  1. Conectar aplicaciones, datos y dispositivos que residen en cualquier lugar (por ejemplo, en las instalaciones, SaaS, nube privada/pública)
  2. Diseñar, orquestar y gestionar APIs y microservicios
  3. Rearquitecturar aplicaciones monolíticas inflexibles en aplicaciones nativas de la nube altamente escalables.
  4. 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.

Mayor agilidad a través de la conectividad digital moderna
Obtenga vistas rápidas de la ejecución de aplicaciones y detalles de rendimiento.
Mayor agilidad a través de la conectividad digital moderna
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.

Regístrese para la prueba gratuita en https://www.tibco.com/products/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.

Plataforma de Contenedores Gestionada: Ventajas y Beneficios Clave

Plataforma de Contenedores Gestionada: Ventajas y Beneficios Clave

La Plataforma de Contenedores Gestionada ofrece ventajas a cualquier sistema dentro de cualquier empresa. Echa un vistazo a las tres críticas.

La Plataforma de Contenedores Gestionada está revolucionando todo. Estamos viviendo en una época donde el desarrollo y el panorama de TI están cambiando, nuevos paradigmas como microservicios y contenedores parecen estar presentes desde hace algunos años, y si confiamos en la realidad que los blogs y artículos muestran hoy, todos los usuarios ya los estamos usando todo el tiempo.

¿Has visto alguna publicación de blog sobre cómo desarrollar una aplicación J2EE que se ejecute en tu servidor Tomcat local? Probablemente no. El artículo más similar probablemente debería ser cómo contenerizar tu aplicación basada en Tomcat.

¿Pero sabes qué? La mayoría de las empresas todavía están trabajando de esa manera. Así que incluso si todas las empresas tienen un nuevo enfoque digital en algunos departamentos, también tienen otros que son más tradicionales.

Entonces, parece que necesitamos encontrar una manera diferente de traducir las principales ventajas de una plataforma basada en contenedores a un tipo de discurso que puedan ver y darse cuenta de los beneficios tangibles que pueden obtener de allí y tener el espíritu de «¡Hey, esto puede funcionar para mí!».

1. Obtendrás todos los componentes aislados y actualizados más rápidamente

Esa es una de las grandes cosas sobre las plataformas basadas en contenedores en comparación con enfoques anteriores como las plataformas basadas en servidores de aplicaciones. Cuando tienes un clúster de servidores de aplicaciones, todavía tienes un clúster con varias aplicaciones. Así que usualmente haces algo de aislamiento, mantienes aplicaciones relacionadas, proporcionas infraestructura independiente para las críticas, y así sucesivamente.

Pero incluso con eso, a algún nivel, la aplicación continúa estando acoplada, por lo que algunos problemas con algunas aplicaciones podrían derribar otra que no se esperaba por razones comerciales.

Con una plataforma basada en contenedores, obtienes cada aplicación en su burbuja, por lo que cualquier problema o error afectará a esa aplicación y nada más. La estabilidad de la plataforma es una prioridad para todas las empresas y todos los departamentos dentro de ellas. Solo pregúntate: ¿Quieres terminar con esas «cadenas de dominó» de fallos? ¿Cuánto mejorarán tus operaciones? ¿Cuánto aumentará tu felicidad?

Además, basado en el enfoque de contenedores, obtendrás componentes más pequeños. Cada uno de ellos realizará una sola tarea proporcionando una única capacidad a tu negocio, lo que significa que será mucho más fácil de actualizar, probar y desplegar en producción. Así que, al final, generará más despliegues en el entorno de producción y reducirá el tiempo de comercialización de tus capacidades empresariales.

Podrás desplegar más rápido y tener operaciones más estables al mismo tiempo.

2.- Optimizarás el uso de tu infraestructura

Costos, todo se trata de costos. No hay conversaciones con clientes que no estén tratando de pagar menos por su infraestructura. Así que, enfrentémoslo. Deberíamos poder ejecutar operaciones de manera optimizada. Así que, si el costo de nuestra infraestructura está aumentando, eso necesita significar que nuestro negocio está creciendo.

Las plataformas basadas en contenedores permitirán optimizar la infraestructura de dos maneras diferentes. Primero, si se utilizan dos conceptos principales: Elasticidad y Compartición de Infraestructura.

La elasticidad está relacionada porque solo voy a tener la infraestructura que necesito para soportar la carga que tengo en este momento. Así que, si la carga aumenta, mi infraestructura aumentará para manejarla, pero después de que ese momento pase, volverá a lo que necesita ahora después de que ese pico haya ocurrido.

La compartición de infraestructura se trata de usar cada parte del servidor que está libre para desplegar otras aplicaciones. Imagina un enfoque tradicional donde tengo dos servidores para mi conjunto de aplicaciones. Probablemente no tengo un uso del 100% de esos servidores porque necesito tener algo de capacidad de reserva para poder actuar cuando la carga aumente. Probablemente tengo un 60–70% de uso. Eso significa un 30% libre. Si tenemos diferentes departamentos con diferentes sistemas, y cada uno tiene su infraestructura con un 30% libre, ¿cuánta de nuestra infraestructura estamos simplemente desperdiciando? ¿Cuántos dólares/euros/libras estás simplemente tirando por la ventana?

Las plataformas basadas en contenedores no necesitan herramientas o software específicos instalados en la plataforma para ejecutar un tipo diferente de aplicación. No es necesario porque todo reside dentro del contenedor, por lo que puedo usar cualquier espacio libre para desplegar otras aplicaciones haciendo un uso más eficiente de esos.

3.- No necesitarás infraestructura para administración

Cada sistema que es lo suficientemente grande tiene algunos recursos dedicados para poder gestionarlo. Sin embargo, incluso la mayoría de las arquitecturas recomendadas recomiendan colocar esos componentes aislados de tus componentes de tiempo de ejecución para evitar cualquier problema relacionado con el administrador o el mantenimiento que pueda afectar tus cargas de trabajo de tiempo de ejecución, lo que significa infraestructura específica que estás usando para algo que no está ayudando a tu negocio. Por supuesto, puedes explicar a cualquier usuario de negocio que necesitas una máquina para ejecutar que proporcione las capacidades requeridas. Pero es más complejo que usar infraestructura adicional (y generar costo) para colocar otros componentes que no están ayudando al negocio.

Así que, las plataformas de contenedores gestionadas eliminan ese problema porque vas a proporcionar la infraestructura que necesitas para ejecutar tus cargas de trabajo, y se te proporcionarán de forma gratuita o por una tarifa tan baja las capacidades de administración. Y además de eso, ni siquiera necesitas preocuparte de que las funciones de administración estén siempre disponibles y funcionando bien porque esto se apoya en el propio proveedor.

Conclusión y próximos pasos

Como puedes ver, describimos beneficios muy tangibles que no están basados en la industria o enfocados en el desarrollo. Por supuesto, podemos tener muchos más para agregar a esta lista, pero estos son los críticos que afectan a cualquier empresa en cualquier industria en todo el mundo. Así que, por favor, tómate tu tiempo para pensar en cómo estas capacidades pueden ayudar a mejorar tu negocio. Pero no solo eso, tómate tu tiempo para cuantificar cómo eso mejorará tu negocio. ¿Cuánto puedes ahorrar? ¿Cuánto puedes obtener de este enfoque?

Y cuando tengas frente a ti un caso de negocio sólido basado en este enfoque, obtendrás todo el apoyo y el coraje que necesitas para avanzar en esa ruta. ¡Así que te deseo una transición pacífica!

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?

Aprende cómo puedes incluir el registro de Harbor en tu conjunto de herramientas DevSecOps para aumentar la seguridad y gestión en tu plataforma basada en contenedores

Con la transición a un proceso de desarrollo más ágil donde el número de implementaciones ha aumentado de manera exponencial. Esa situación ha hecho que sea bastante complejo mantener el ritmo para asegurarnos de que no solo estamos implementando código más a menudo en producción que proporciona las capacidades requeridas por el negocio. Sino que, al mismo tiempo, podemos hacerlo de manera segura y confiable.

Esa necesidad está llevando hacia la idea de DevSecOps para incluir la seguridad como parte de la cultura y prácticas de DevOps como una forma de garantizar la seguridad desde el principio en el desarrollo y a lo largo de todos los pasos estándar desde la máquina del desarrollador hasta el entorno de producción.

Además de eso, debido al paradigma de los contenedores, tenemos un enfoque más políglota con diferentes tipos de componentes ejecutándose en nuestra plataforma utilizando una imagen base diferente, paquetes, bibliotecas, etc. Necesitamos asegurarnos de que sigan siendo seguros de usar y necesitamos herramientas para poder gobernar eso de manera natural. Para ayudarnos en esa tarea es donde componentes como Harbor nos ayudan a hacerlo.

Harbor es un proyecto de CNCF en la etapa de incubación en el momento de escribir este artículo, y proporciona varias capacidades sobre cómo gestionar imágenes de contenedores desde una perspectiva de proyecto. Ofrece un enfoque de proyecto con su registro de docker y también un museo de gráficos si queremos usar Helm Charts como parte de nuestro desarrollo de proyectos. Pero también incluye características de seguridad, y esa es la que vamos a cubrir en este artículo:

  • Escaneo de Vulnerabilidades: te permite escanear todas las imágenes de docker registradas en los diferentes repositorios para verificar si tienen vulnerabilidades. También proporciona automatización durante ese proceso para asegurarse de que cada vez que empujamos una nueva imagen, esta se escanea automáticamente. Además, permitirá definir políticas para evitar extraer cualquier imagen con vulnerabilidades y también establecer el nivel de vulnerabilidades (bajo, medio, alto o crítico) que nos gustaría tolerar. Por defecto, viene con Clair como el escáner predeterminado, pero también puedes introducir otros.
  • Imágenes firmadas: el registro de Harbor proporciona opciones para desplegar notary como parte de sus componentes para poder firmar imágenes durante el proceso de empuje para asegurarse de que no se realicen modificaciones a esa imagen
  • Inmutabilidad de Etiquetas y Reglas de Retención: el registro de Harbor también proporciona la opción de definir la inmutabilidad de etiquetas y reglas de retención para asegurarse de que no haya ningún intento de reemplazar imágenes con otras usando la misma etiqueta.

El registro de Harbor se basa en docker, por lo que puedes ejecutarlo localmente usando docker y docker-compose siguiendo el procedimiento disponible en su página web oficial. Pero también admite ser instalado sobre tu plataforma Kubernetes usando el helm chart y el operador que están disponibles.

Una vez que la herramienta está instalada, tenemos acceso al Portal Web de la UI, y podemos crear un proyecto que tenga repositorios como parte de él.

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?
Lista de Proyectos dentro del Portal UI de Harbor

Como parte de la configuración del proyecto, podemos definir las políticas de seguridad que nos gustaría proporcionar a cada proyecto. Eso significa que diferentes proyectos pueden tener diferentes perfiles de seguridad.

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?
Configuraciones de seguridad dentro de un Proyecto en el Portal UI de Harbor

Y una vez que empujamos una nueva imagen al repositorio que pertenece a ese proyecto, vamos a ver los siguientes detalles:

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?

En este caso, he empujado una aplicación de TIBCO BusinessWorks Container Edition que no contiene ninguna vulnerabilidad y solo muestra eso y también dónde se verificó.

Además, si vemos los detalles, podemos verificar información adicional como si la imagen ha sido firmada o no, o poder verificarla nuevamente.

Registro de Harbor: ¿Cómo usarlo para aumentar la seguridad en tu plataforma?
Detalles de la imagen dentro del Portal UI de Harbor

Resumen

Así que, estas son solo algunas características que Harbor proporciona desde la perspectiva de seguridad. Pero Harbor es mucho más que solo eso, así que probablemente cubramos más de sus características en futuros artículos. Espero que, basado en lo que leíste hoy, te gustaría darle una oportunidad y comenzar a introducirlo en tu conjunto de herramientas DevSecOps.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Guerras tecnológicas: Solución de Gestión de API vs Malla de Servicios

Guerras tecnológicas: Solución de Gestión de API vs Malla de Servicios

Service Mesh vs. Solución de Gestión de API: ¿es lo mismo? ¿Son compatibles? ¿Son rivales?

Cuando hablamos de comunicación en un mundo distribuido nativo de la nube y especialmente cuando hablamos de arquitecturas basadas en contenedores basadas en la plataforma Kubernetes como AKS, EKS, Openshift, etc., dos tecnologías generan mucha confusión porque parecen estar cubriendo las mismas capacidades: Esas son Service Mesh y Soluciones de Gestión de API.

Ha sido un tema controvertido donde se han hecho diferentes declaraciones audaces: Personas que piensan que esas tecnologías trabajan juntas de manera complementaria, otras que creen que están tratando de resolver los mismos problemas de diferentes maneras e incluso personas que piensan que una es solo la evolución de la otra hacia la nueva arquitectura nativa de la nube.

Soluciones de Gestión de API

Las Soluciones de Gestión de API han sido parte de nuestras arquitecturas durante mucho tiempo. Es un componente crucial de cualquier arquitectura hoy en día que se crea siguiendo los principios de la Arquitectura Guiada por API, y son una evolución del Gateway de API preexistente que hemos incluido como una evolución de los proxies puros a finales de los 90 y principios de los 2000.

La Solución de Gestión de API es un componente crítico de su Estrategia de API porque permite a su empresa trabajar en un Enfoque Guiado por API. Y eso es mucho más que el aspecto técnico de ello. Usualmente tratamos de simplificar el Enfoque Guiado por API al lado técnico con el desarrollo basado en API y los microservicios que estamos creando y el espíritu colaborativo en mente que usamos hoy para hacer cualquier pieza de software que se despliega en el entorno de producción.

Pero es mucho más que eso. Las Arquitecturas Guiadas por API se tratan de crear productos a partir de nuestra API, proporcionando todos los artefactos (técnicos y no técnicos) que necesitamos para hacer esa conversión. Una lista rápida de esos artefactos (pero no es una lista exhaustiva) son los siguientes:

  • Soporte de Documentación de API
  • Definición de Planes de Paquetes
  • Capacidades de Suscripción
  • Capacidades de Monetización
  • Descubrimiento de API de Autoservicio
  • Capacidades de Versionado

Tradicionalmente, la solución de Gestión de API también viene con capacidades de Gateway de API integradas para cubrir incluso el aspecto técnico de ello, y que también proporcionan algunas otras capacidades más a nivel técnico:

  • Exposición
  • Enrutamiento
  • Seguridad
  • Limitación

Service Mesh

Service Mesh es más una palabra de moda en estos días y una tecnología que ahora está en tendencia porque ha sido creada para resolver algunos de los desafíos que son inherentes al enfoque de microservicios y contenedores y todo bajo la etiqueta de nativo de la nube.

En este caso, proviene del lado técnico, por lo que es mucho más un enfoque de abajo hacia arriba porque su existencia es para poder resolver un problema técnico e intentar proporcionar una mejor experiencia de usuario a los nuevos desarrolladores y administradores de sistemas en este nuevo mundo mucho más complicado. ¿Y cuáles son los desafíos que se han creado en esta transición? Echemos un vistazo a ellos:

El Registro y Descubrimiento de Servicios es una de las cosas críticas que necesitamos cubrir porque con el paradigma elástico del mundo nativo de la nube hace que los servicios cambien su ubicación de vez en cuando comenzando en nuevas máquinas cuando sea necesario, eliminándolos cuando no hay suficiente carga para requerir su presencia, por lo que es esencial proporcionar una manera de gestionar fácilmente esa nueva realidad que no necesitábamos en el pasado cuando nuestros servicios estaban vinculados a una máquina específica o conjunto de dispositivos.

La seguridad es otro tema importante en cualquier arquitectura que podamos crear hoy, y con el enfoque poliglota que hemos incorporado en nuestras arquitecturas es otra cosa desafiante porque necesitamos proporcionar una manera segura de comunicar nuestros servicios que son compatibles con cualquier tecnología que estemos usando y cualquiera que podamos usar en el futuro. Y no estamos hablando solo de Autenticación pura sino también de Autorización porque en una comunicación de servicio a servicio también necesitamos proporcionar una manera de verificar si el microservicio que está llamando a otro está permitido para hacerlo y hacerlo de una manera ágil para no detener todas las nuevas ventajas que su arquitectura nativa de la nube proporciona debido a su concepción.

Los requisitos de enrutamiento también han cambiado en estas nuevas arquitecturas. Si recuerdas cómo solíamos desplegar en arquitecturas tradicionales, normalmente intentamos encontrar un enfoque de cero tiempo de inactividad (cuando es posible) pero un procedimiento muy estándar. Desplegar una nueva versión, validar su funcionamiento y abrir el tráfico para cualquiera, pero hoy los requisitos exigen paradigmas mucho más complejos. Las tecnologías de Service Mesh soportan estrategias de implementación como Pruebas A/B, Enrutamiento basado en peso, Implementaciones Canary.

¿Rival o Compañero?

Entonces, después de hacer una vista rápida del propósito de estas tecnologías y el problema que intentaron resolver, ¿son rivales o compañeros? ¿Deberíamos elegir una u otra o intentar colocar ambas en nuestra arquitectura?

Como siempre, la respuesta a esas preguntas es la misma: «¡Depende!». Depende de lo que estás tratando de hacer, lo que tu empresa está tratando de lograr, lo que estás construyendo…

  • Se necesita una solución de Gestión de API siempre que estés implementando una Estrategia de API en tu organización. La tecnología de Service Mesh no está tratando de llenar ese vacío. Pueden proporcionar capacidades técnicas para cubrir lo que tradicionalmente ha hecho el componente de Gateway de API, pero este es solo uno de los elementos de la Solución de Gestión de API. Las otras partes que proporcionan las capacidades de gestión y gobernanza no están cubiertas por ningún Service Mesh hoy en día.
  • Se necesita Service Mesh si tienes una arquitectura nativa de la nube basada en la plataforma de contenedores que se basa firmemente en la comunicación HTTP para la comunicación sincrónica. Proporciona tantas capacidades técnicas que harán tu vida mucho más manejable que tan pronto como lo incluyas en tu arquitectura, no podrás vivir sin él.
  • Service Mesh solo va a proporcionar sus capacidades en un enfoque de plataforma de contenedores. Entonces, si tienes un panorama más heterogéneo como muchas empresas tienen hoy en día, (tienes una plataforma de contenedores pero también otras plataformas como aplicaciones SaaS, algunos sistemas aún en las instalaciones y arquitecturas tradicionales que todas ellas están proporcionando capacidades que te gustaría aprovechar como parte de los productos de API), necesitarás incluir una Solución de Gestión de API.

Por lo tanto, estas tecnologías pueden jugar juntas en una arquitectura completa para cubrir diferentes tipos de requisitos, especialmente cuando estamos hablando de arquitecturas heterogéneas complejas con la necesidad de incluir un enfoque Guiado por API.

En próximos artículos, cubriremos cómo podemos integrar ambas tecnologías desde el aspecto técnico y cómo fluye la información entre los diferentes componentes de la arquitectura.

Los 3 mejores trucos de Bash para mejorar tu rendimiento

Los 3 mejores trucos de Bash para mejorar tu rendimiento

Encuentra la lista de los trucos de rendimiento de bash que uso todo el tiempo y que pueden ayudarte a ahorrar mucho tiempo en tu trabajo diario.

El conocimiento de trucos de bash es una de las formas de mejorar tu rendimiento. Pasamos muchas horas dentro de ellos y hemos desarrollado patrones y hábitos cuando iniciamos sesión en una computadora. Por ejemplo, si tienes dos personas con un nivel de habilidad similar y les das la misma tarea para hacer, probablemente, usen herramientas diferentes y diferentes caminos para llegar al mismo resultado.

Y eso es porque la cantidad de opciones disponibles para realizar cualquier tarea es tan significativa que cada uno de nosotros aprende una o dos formas de hacer algo, y nos aferramos a ellas, y simplemente las automatizamos, así que no estamos pensando cuando las escribimos.

Entonces, la idea de hoy es proporcionar una lista de algunos comandos que uso todo el tiempo que probablemente ya conozcas, pero para mí son como ahorros de tiempo cada día de mi vida laboral. Así que, comencemos con ellos.

1.- CTRL + R

Este comando es mi truco de bash predilecto. Es el que uso todo el tiempo; tan pronto como inicio sesión en una máquina remota que es nueva o simplemente regreso a ellas, lo uso para casi todo. Desafortunadamente, este comando solo te permite buscar en el historial de comandos.

Te ayuda a autocompletar basado en los comandos que ya estás escribiendo. Es como lo mismo que escribir history | grep <algo> pero simplemente más rápido y más natural para mí.

Este truco de bash también me permite autocompletar rutas que no recuerdo el nombre exacto de la subcarpeta o lo que sea. Hago este comando complicado cada dos semanas para limpiar algo de memoria de procesos o aplicar alguna configuración. O simplemente para solucionar problemas en qué máquina estoy iniciando sesión en un momento específico.

2.- find + action

El comando find es algo que todos conocemos, pero la mayoría de ustedes probablemente lo usen como una funcionalidad limitada de todas las disponibles del comando find. Y eso es porque ese comando es increíble. Proporciona tantas características. Pero esta vez, solo voy a cubrir un tema específico. Acciones después de localizar los archivos que estamos buscando.

Usualmente usamos el comando find para encontrar archivos o carpetas, lo cual es evidente para un comando que se llama de esa manera. Pero también nos permite agregar el parámetro -exec para concatenar una acción que se realizará para cada uno de los archivos que coincidan con tus criterios, por ejemplo, algo como esto

Encuentra todos los archivos yaml en tu carpeta actual y simplemente renómbralos para moverlos a una carpeta diferente. Puedes hacerlo directamente con este comando:

find . -name “*.yaml” -exec mv {} /tmp/folder/yamlFiles/ ;

3.- cd –

Un truco de bash tan simple y tan útil. Al igual que nuestro comando de bash para CTRL-Z. El comando cd - nos permite volver a la carpeta anterior en la que estábamos.

Tan valioso para cuando nos equivocamos de carpeta a la que queremos ir, solo para cambiar rápidamente entre dos carpetas y así sucesivamente. Es como volver atrás en tu navegador o el CTRL-Z en tu procesador de textos.

Conclusión

Espero que ames este comando tanto como yo, y si ya lo conoces, por favor déjame en las respuestas los trucos de bash que son más relevantes para ti diariamente. Puede ser porque lo usas todo el tiempo como yo hago con estos o porque incluso si no lo usas tantas veces, las veces que lo haces, ¡te ahorra una cantidad masiva de tiempo!

Observabilidad en un Ecosistema de Microservicios Políglota

Observabilidad en un Ecosistema de Microservicios Políglota

Aprende a gestionar los requisitos de observabilidad como parte de tu ecosistema de microservicios

“Que vivas en tiempos interesantes” es la traducción al inglés de la maldición china, y esto no podría ser más cierto como descripción de los tiempos en los que vivimos en cuanto a nuestra arquitectura de aplicaciones y desarrollo de aplicaciones.

Todos los cambios del enfoque nativo de la nube, incluyendo todas las nuevas tecnologías que vienen con él, como contenedores, microservicios, API, DevOps, etc., han transformado completamente la situación para cualquier arquitectura, desarrollador o administración de sistemas.

Es algo similar si te fuiste a la cama en 2003 y te despiertas en 2020, todos los cambios, todas las nuevas filosofías, pero también todos los desafíos únicos que vienen con los cambios y nuevas capacidades son cosas con las que necesitamos lidiar hoy.

Creo que todos podemos estar de acuerdo en que el presente es políglota en términos de desarrollo de aplicaciones. Hoy no se espera que ninguna gran empresa o corporación encuentre una tecnología disponible, un lenguaje disponible para soportar todos sus productos internos. Hoy todos seguimos y estamos de acuerdo con el principio de “la herramienta adecuada para el trabajo adecuado” para intentar crear nuestro conjunto de herramientas de tecnologías que vamos a usar para resolver diferentes casos de uso o patrones que necesitas enfrentar.

Pero ese acuerdo y movimiento también vienen con su desafío respecto a cosas en las que usualmente no pensamos, como el rastreo y la observabilidad en general.

Cuando usamos una sola tecnología, todo es más sencillo. Definir una estrategia común para rastrear tus flujos de extremo a extremo es fácil; solo necesitas incrustar la lógica en tu marco de desarrollo común o biblioteca que todos tus desarrollos están usando. Probablemente definir una arquitectura de encabezado típica con todos los datos que necesitas para poder rastrear efectivamente todas las solicitudes y definir un protocolo estándar para enviar todos esos rastros a un sistema estándar que pueda almacenarlos y correlacionarlos todos y explicar el flujo de extremo a extremo. Pero intenta mover eso a un ecosistema políglota: ¿Debería escribir mi marco o biblioteca para cada lenguaje o tecnología que necesitaría usar, o también puedo usar en el futuro? ¿Tiene sentido eso?

Pero no solo eso, ¿debería ralentizar la adopción de una nueva tecnología que puede ayudar rápidamente al negocio porque necesito proporcionar desde un equipo compartido este tipo de componentes estándar? Ese es el mejor caso en el que tengo suficiente gente que sabe cómo funcionan los internos de mi marco y tiene las habilidades en todos los lenguajes que estamos adoptando para poder hacerlo rápidamente y de manera eficiente. Parece poco probable, ¿verdad?

Entonces, a nuevos desafíos también nuevas soluciones. Ya he estado hablando sobre Service Mesh respecto a las capacidades que proporciona desde una perspectiva de comunicación, y si no lo recuerdas, puedes echar un vistazo a esas publicaciones:

Pero también proporciona capacidades desde otras perspectivas y el rastreo y la observabilidad es una de ellas. Porque cuando no podemos incluir esas características en cualquier tecnología que necesitemos usar, podemos hacerlo en una tecnología general que sea compatible con todas ellas, y ese es el caso con Service Mesh.

Como Service Mesh es la forma estándar de comunicar sincrónicamente tus microservicios en una comunicación de este a oeste cubriendo la comunicación de servicio a servicio. Entonces, si puedes incluir en ese componente también la capacidad de rastreo, puedes tener un rastreo de extremo a extremo sin necesidad de implementar nada en cada una de las diferentes tecnologías que puedes usar para implementar la lógica que necesitas, así que, has cambiado de la Figura A a la Figura B en la imagen a continuación:

Observabilidad en un Ecosistema de Microservicios Políglota
Implementación de lógica de rastreo en la aplicación vs. Soporte de rastreo de Service Mesh 

Y eso es lo que la mayoría de las tecnologías de Service Mesh están haciendo. Por ejemplo, Istio, como una de las opciones predeterminadas cuando se trata de Service Mesh, incluye una implementación del estándar OpenTracing que permite la integración con cualquier herramienta que soporte el estándar para poder recopilar toda la información de rastreo para cualquier tecnología que se use para comunicarse a través de la malla.

Entonces, ese cambio de mentalidad nos permite integrar fácilmente diferentes tecnologías sin necesidad de ningún soporte excepcional de esos estándares para cualquier tecnología específica. ¿Significa eso que la implementación de esos estándares para esas tecnologías no es necesaria? En absoluto, eso sigue siendo relevante, porque las que también soportan esos estándares pueden proporcionar aún más información. Después de todo, el Service Mesh solo conoce parte de la información que es el flujo que está sucediendo fuera de cada tecnología. Es algo similar a un enfoque de caja negra. Pero también agregar el soporte para cada tecnología al mismo estándar proporciona un enfoque adicional de caja blanca como puedes ver gráficamente en la imagen a continuación:

Observabilidad en un Ecosistema de Microservicios Políglota
Combinación de datos de rastreo de caja blanca y datos de rastreo de caja negra 

Ya hablamos sobre el cumplimiento de algunas tecnologías con el estándar OpenTracing como TIBCO BusinessWorks Container Edition que puedes recordar aquí:

Entonces, también, el soporte de estas tecnologías de los estándares de la industria es necesario e incluso una ventaja competitiva porque sin necesidad de desarrollar tu marco de rastreo, puedes lograr un enfoque de Datos de Rastreo Completo adicional a lo que ya proporciona el nivel de Service Mesh en sí mismo.