Opinion Archives - Alexandre Vazquez

Enfrentémoslo: ¡Los mejores desarrolladores no están en Twitch o YouTube!

2022-05-072021-09-19 por Alexandre Vazquez

Los creadores de contenido están educando a los desarrolladores junior en plataformas sociales que probablemente idealizan su visión incluso cuando no son los mejores de su clase.

Estamos viviendo un momento de máxima exposición a la creación de contenido con temas de desarrollo de software. La última noticia sobre este tema es la creación de una sección específica sobre Canales de Desarrollo de Software en la popular plataforma de streaming Twitch:

Twitch introduces new “Software & Game Development” streaming category, boosting gamedev content discoverability | Game World Observer

Twitch announced that it’s introducing new Software & Game Development streaming category to improve the discoverability of content for devs.

Y eso es solo una etapa adicional en la tendencia que estamos viendo en los últimos años donde el contenido creado y las personas que invierten su tiempo en compartir su conocimiento en internet están explotando.

Prácticamente puedes encontrar un Canal en Vivo que te enseñará o compartirá contigo mucho conocimiento y experiencia sobre todos los temas relacionados con el desarrollo de software. No importa qué tema estés buscando, lo tendrás allí. Por ejemplo, hoy más temprano fui. Encontré los siguientes canales en vivo: Creando un MMO desde cero, Desarrollo de Maya, Programación en Java, Programación en GoLang, Programación de CMS usando Django y Python, y mucho más.

Esto es algo grandioso. Vivimos en una era donde tenemos contenido de gran calidad a nuestra disposición, especialmente en nuestra industria, que nos ayudará a mejorar nuestras habilidades y base de conocimientos. Todos estos creadores de contenido son los principales contribuyentes a eso. Y esos están aumentando la popularidad de los mejores creadores de contenido alcanzando niveles sobresalientes.

Pero esa situación también está creando la circunstancia de que los desarrolladores junior o simplemente personas que comienzan una nueva habilidad comiencen a pensar que las personas que muestran su visión o experiencia sobre un tema son los mejores desarrolladores en esa área, y eso está muy lejos de la verdad. Así que se está inclinando hacia una situación peligrosa.

Para ser claro: Los Creadores de Contenido no suelen ser Grandes Desarrolladores. Normalmente son desarrolladores regulares con habilidades de comunicación impresionantes. Y eso es más importante con una voluntad de compartir lo que saben con su audiencia. Incluso que están ganando dinero con esto, para ser justos, tienen una determinación inequívoca de desempeñar un papel social de compartir el conocimiento con el mundo, y eso es muy importante.

Esto no es solo intentar avergonzar a los creadores de contenido por su calidad; esto está sucediendo en todas las industrias. El mejor conocimiento compartido no suele ser el mejor de su práctica. Puedes pensar en cualquier tema: Matemáticas, Física, pero también Deportes. ¿Son los mejores narradores de Fútbol los mejores jugadores? No, seguro.

Pero por esta razón, es importante tener en cuenta esto cuando asistimos a esos canales o vemos esos videos que no son los verdaderos expertos, por lo que siempre debes verificar sus declaraciones para asegurarte de que estén alineadas con las mejores prácticas y procesos.

Si te gustaría ver lo que los verdaderos buenos desarrolladores están haciendo, es mucho más fácil encontrarlo cerca de donde reside el código. Usando plataformas como GitHub o SourceForge, los proyectos con más estrellas que proporcionan valor y leyendo sus conversaciones o analizando sus commits, te proporcionaremos una visión mucho más clara de lo que los verdaderos desarrolladores de alto nivel están haciendo.

Otra opción es suscribirse a la lista de correo de esos proyectos donde puedes ver la discusión real de los desarrolladores, los puntos principales que están haciendo y el razonamiento detrás de esas decisiones.

Este es un conocimiento mucho más importante que lo que puedes ver en una sesión en vivo de alguien programando en una plataforma de streaming, pero esto también es parte del proceso porque necesitarás tener la base para estar listo para entender a qué se refiere la discusión y para ese nivel de introducción la forma en que este increíble creador de contenido está compartiendo el conocimiento es la mejor manera para que cualquiera lo entienda y lo asimile.

Terminología de API: Estamos Usando Mal el Término API y Me Está Volviendo Loco

2022-09-142021-09-07 por Alexandre Vazquez

Cuando el marketing se apropia de una palabra técnica, conduce a la locura y a un cambio completo de su significado.

API es el siguiente en la lista. Siempre es el mismo patrón con respecto a los términos técnicos cuando van más allá del foro realmente técnico normal y alcanzan un nivel más «mainstream» en la industria. Tan pronto como esto sucede, el término comienza a perder su significado y empieza a ser como una palabra comodín que puede significar cosas muy diferentes para personas muy diferentes. Si no me crees, acompáñame a este conjunto de ejemplos.

Puedes argumentar que los términos necesitan evolucionar y que la misma palabra puede significar cosas diferentes siempre que la industria continúe evolucionando, y eso es cierto. Por ejemplo, el término paquete que en el pasado se refería a la forma de empaquetar software para poder compartirlo, generalmente a través de correo o un servidor FTP como un paquete TAR, ha sido redefinido con la eclosión de los gestores de paquetes en los años 90 y después con la gestión de artefactos para manejar dependencias con enfoques como Maven, npm, etc.

Pero no estoy hablando de estos ejemplos. Estoy hablando de cuando un término se usa mucho porque es elegante y significa evolución o modernización, por lo que intentas usarlo tanto como sea posible, incluso para significar cosas diferentes. Y uno de estos términos es API.

API significa Interfaz de Programación de Aplicaciones, y como su nombre indica, es una interfaz. Desde el principio de los tiempos de la computación, se ha creado para referirse al contrato y cómo necesitas interactuar con un programa de aplicación específico. Sin embargo, el término se usaba principalmente para bibliotecas para definir su contrato para otras aplicaciones que necesitaban la capacidad.

Así que si quisiéramos mostrar esto en una forma gráfica, esto es a lo que se refiere la API:

Con la eclosión de los Servicios REST y las aplicaciones móviles, el término API se expandirá más allá de su uso normal y se convertirá en una palabra normal en el mundo de hoy porque todos los desarrolladores necesitan alguna API para trabajar. Comenzando desde las capacidades comunes como la Autenticación hasta que solo se necesitan capacidades concretas para realizar su trabajo.

La explosión de servicios que expusieron su propia API requirió una forma de proporcionar gestión central a las interfaces expuestas, especialmente cuando comenzamos a publicar algunas de estas capacidades al mundo exterior. Necesitábamos asegurarlas, identificar quién las estaba usando y a qué nivel, y una forma para que los desarrolladores encontraran la documentación necesaria para poder usar sus servicios. Y debido a eso, tenemos el auge de las soluciones de Gestión de API.

Y luego vinieron los microservicios a revolucionar cómo se realizan las aplicaciones, y eso supone que ahora tenemos más servicios, cada uno de ellos proporcionando su propia API a un nivel que prácticamente tenemos un servicio para una capacidad y debido a eso una API para una capacidad, algo como puedes ver en la imagen a continuación:

Y el uso de API se volvió tan popular que algunas personas comenzaron a usar el término para referirse a la interfaz y al servicio completo que implementa esta API, lo que lleva y está llevando a mucha confusión. Así que debido a eso, cuando hablamos ahora sobre Desarrollo de API, podemos hablar de cosas muy diferentes:

Podemos hablar sobre la definición y el modelo de la interfaz en sí misma y su gestión.
Podemos hablar sobre una implementación de servicio con una API expuesta para ser utilizada y gestionada adecuadamente.
Incluso podemos hablar sobre un servicio que utiliza varias APIs como parte de su implementación de capacidad.

Y el problema principal cuando usamos el mismo término para referirse a tantas cosas diferentes es que la palabra pierde todo su significado y con eso complica nuestra comprensión en cualquier conversación y eso lleva a muchos problemas que podríamos evitar simplemente usando las palabras adecuadas e intentando mantener todo el ruido y el marketing un poco fuera de las conversaciones técnicas.

Los 3 mejores trucos para usar Medium y mantenerte al día en la industria tecnológica

2022-05-062021-07-12 por Alexandre Vazquez

Medium puede ser uno de tus mejores aliados en esta tarea interminable de mantenerse al día con las actualizaciones en la industria tecnológica.

Todos los que estamos aquí usamos Medium. Estoy siendo un poco Capitán Obvio aquí porque si estás leyendo esto, estoy seguro de que ya estás usando Medium para el crecimiento profesional y para aprender cosas nuevas, pero me gustaría destacar cómo lo uso para mantenerme al día con la situación actual.

Sabes que las cosas cambian muy rápido. Por supuesto, esto está sucediendo en todas las industrias y negocios, pero es aún más urgente en la industria tecnológica.

Estamos viendo nuevas tecnologías cada semana o incluso cada día. Los frameworks cambian tan rápido como podemos imaginar, y tratar de mantener el ritmo de eso es bastante complejo para cualquiera de nosotros. Por lo tanto, debemos usar todas las herramientas a nuestra disposición para asegurarnos de hacer lo mejor en esta situación.

#1 Ajusta tus Recomendaciones Personalizadas

Una de las grandes cosas de Medium es que utiliza tus intereses y los artículos que has estado leyendo y cuánto tiempo pasaste leyéndolos para recomendarte nuevos artículos relevantes.

Así que, aquí las recomendaciones son claras: Usa Medium todo el tiempo. Intenta usar la capacidad de búsqueda para buscar en muchos artículos disponibles porque cuanto más lo uses, más precisas serán las recomendaciones para ti.

Tuve un tiempo, hace unas semanas, cuando estaba realmente interesado en Arquitecturas de Datos Modernas y Nativas de la Nube debido a algunas responsabilidades profesionales. Así que comencé a buscar esos artículos en Medium. Desde ese momento, las recomendaciones han sido bastante precisas sobre lo que estaba buscando y me ayudaron a mejorar mi conocimiento y encontrar artículos que no tenía idea de que estaban disponibles en Medium.

Además de eso, necesitas asegurarte de que tus intereses estén bien configurados. Por lo general, cuando configuramos una cuenta y nos preguntan sobre nuestros intereses, probablemente no lo pensamos mucho tiempo porque lo único que queremos es acceder al contenido de inmediato (¡culpable aquí!).

Por lo tanto, debes tomarte tu tiempo ahora para asegurarte de que los intereses que seleccionaste cuando te uniste sigan siendo los más relevantes para ti hoy. Si deseas verificar tus intereses actuales, necesitas ir a tu perfil y hacer clic en «Controla tus Recomendaciones», como puedes ver en la imagen a continuación:

Además, verás los temas que te interesan ahora y un montón de sugerencias de nuevos temas basados en tu historial de lectura que creen que podrían interesarte. Por lo tanto, es importante visitar la página de vez en cuando para asegurarte de que sean precisos y verificar las recomendaciones que te están proporcionando.

#2: Función Leer Más Tarde

Otra característica clave es guardar todos los artículos interesantes para continuar leyéndolos más tarde o mantenerlos como tu propia biblioteca. Este es el uso principal que le doy a ese concepto. Intento usar la función Leer Más Tarde para crear y gestionar mi propia «biblioteca basada en Medium».

Y la razón principal detrás de este enfoque es porque todos hemos sufrido esta situación cuando encontramos un gran artículo sobre un tema. Sin embargo, cambiamos a otra tarea, y más tarde, cuando necesitamos encontrar ese artículo nuevamente, no recordamos el título o el autor, y pasamos mucho tiempo tratando de localizarlo nuevamente.

#3: Capacidad de Búsqueda

Incluso cuando estamos acostumbrados a usar Google como nuestra principal opción de búsqueda para buscar cualquier cosa, creo que es importante usar las capacidades de búsqueda en el sitio de Medium por varias razones:

El contenido que tenemos disponible en Medium es enorme, y la mayoría de ellos es de gran calidad debido al proceso de curación.
Es importante que Medium te conozca mejor, y eso afinará todas las recomendaciones que ya hemos comentado.

Y todo esto sin preocuparte de que encontrarás muchos anuncios basados en tu historial de búsqueda 🙂

#4: Miembro de Medium

Y he dejado para el final lo que creo que es la parte más importante: Convertirse en Miembro de Medium.

Medium es genial, no importa si eres miembro o no. Aún así, cuando no era miembro de Medium, era simplemente molesto encontrar el artículo que necesitaba, pero no podía leerlo porque ya había gastado los artículos «destacados» del mes, y necesitaba esperar un mes adicional. Así que sabemos que esto no es válido si quieres mantenerte actualizado en la industria tecnológica, así que por favor, hazte un favor y conviértete en miembro de Medium. Te sentirás más cómodo en la plataforma y comenzarás a vivir dentro de ella.

Por qué rechacé una oferta de una popular empresa tecnológica

2022-01-252021-06-25 por Alexandre Vazquez

No, no era una cuestión de salario. Se trataba de confianza

Todos pasamos por varios procesos de reclutamiento cada año. Puede que no nos sintamos cómodos con nuestra empresa o rol actual. Tiendo a usarlos para ver qué hay disponible afuera y asegurarme de que no me estoy quedando obsoleto.

No suelo postularme a ofertas en línea en situaciones normales, pero cuando alguien se acerca a mí con una propuesta interesante, tiendo a escucharlos para ver qué tienen para ofrecer.

Así es como comencé mi último proceso de reclutamiento.

La razón principal para estar a bordo con el proceso fue que la empresa (no la nombraré aquí) y el rol eran lo que tenía en mi radar como mi próximo paso.

El Proceso

Comenzó con una charla básica con el reclutador para obtener una visión general del rol de la empresa (la empresa es bastante conocida por todos, así que fue rápido) y lo que esperaban. Acordamos los términos, y los números que compartió respecto al salario me convencieron de avanzar con los siguientes pasos para invertir algo de tiempo en esta oportunidad.

Debo admitir que no soy alguien que se prepara y estudia para entrevistas. Soy quien soy. Si mis conocimientos y habilidades son adecuados para la empresa, no quiero pretender ser otra persona o mostrar que soy más inteligente de lo que soy.

Comenzamos con un proceso virtual y algunas tareas virtuales — primero, un modelo de rol que me gustó porque fue inesperado. Tienes un buzón virtual, recibes correos electrónicos de tu jefe o colegas, y necesitas decidir cuál es la respuesta más adecuada.

Luego pasamos a un cuestionario técnico que fue como se esperaba. Cosas normales de bajo nivel para el rol que estaba tratando de obtener (Arquitecto de Soluciones Senior), pero eso estaba bien.

Así que, fuimos a la primera llamada con mi futuro Gerente de Contratación, y fue más basada en el rol que técnica. Quería saber sobre mi experiencia previa que había mostrado algunos aspectos que consideraba relevantes para el trabajo. Eso estuvo bien, y fue una discusión cómoda. Pero esta fue la primera entrevista, y comencé a detectar que algo no estaba bien. Todo se aclararía en la última parte del proceso.

Antes de eso, tuve otra tarea técnica que fue bastante fácil. Se centró en resolver un problema, proporcionando mejoras a mediano y largo plazo. Fue un gran ejercicio de una hora. Como dije, nada complicado pero aún así divertido.

La última parte del proceso consistió en una serie de entrevistas con diferentes perfiles en la empresa. Siguió el mismo enfoque que la anterior. La mayoría de ellas se centraron en preguntas de modelo de rol y otras se centraron en temas relacionados con tecnologías que usaría en mi trabajo o preguntas generales relacionadas con TI.

La Resolución

Aparte del proceso que consume mucho tiempo (al final, hice nueve entrevistas con RRHH), no tuve ningún problema con esas entrevistas. Estuvieron bien y todas me hicieron sentir muy cómodo, pero el proceso tomó el enfoque equivocado en varios aspectos:

Las preguntas técnicas no se centraron en las cosas correctas. He hecho muchas entrevistas en mi vida en ambos lados de la mesa, y en este caso, se sintió más como un examen de TI que como una entrevista. La mayoría de las preguntas eran de muy bajo nivel para un Arquitecto Senior y más similares a las cosas que ves cuando recién sales de la universidad. Nunca me gustó este enfoque de entrevistas como si fuera un examen que necesitas aprobar. Fue la primera advertencia.
Pero la segunda advertencia fue durante cada una de las entrevistas. Todas las entrevistas incluían cinco minutos para que yo hiciera preguntas sobre mi rol o la empresa. Si tuve siete entrevistas (no contaré las de RRHH), tuve cinco minutos en cada una de ellas. Tuve 35 minutos para hacer mis preguntas (que preparé de antemano), y ellos tuvieron 385 minutos para sus preguntas. Eso me dejó con el 9% del tiempo de la entrevista para decidir si esta era la empresa adecuada para mí.

Resumen

Finalmente, recibí la oferta y decidí rechazarla porque este no era el enfoque que esperaría cuando estás contratando a alguien adecuadamente. Puedo entender que las grandes empresas necesitan tener un proceso definido para asegurarse de que solo contratan a los mejores entre un gran grupo de candidatos. Aún así, creo que hay un aspecto que no están cubriendo.

Esto es una calle de dos vías: Como empresa, debería ser tan importante para mí seleccionar al candidato adecuado como lo es para ellos. Fallaron en ese sentido. No me sentí cómodo ni como si tuviera suficiente información. Aún peor, no creo que siquiera les importara si estaba teniendo alguna duda sobre la empresa.

No pretenderé que este artículo hará que las empresas reconsideren sus procesos. Solo quería mostrar mi proceso de pensamiento y por qué el trabajo adecuado y el salario adecuado en una empresa increíble no fueron suficientes. Si ni siquiera pude sentirme cómodo durante el proceso, esta empresa no sería una buena opción para mí a largo plazo.

Espero que hayas disfrutado este artículo. Por favor, siéntete libre de compartir tus opiniones y puntos de vista — especialmente si piensas que actué como un tonto.

Apache NetBeans sigue siendo mi opción preferida para el desarrollo en Java

2022-05-062021-06-22 por Alexandre Vazquez

Descubre cuáles son las razones por las que, para mí, Apache NetBeans sigue siendo el mejor IDE de Java que puedes usar

Permíteme empezar desde el principio. Siempre he sido un Desarrollador Java desde mi tiempo en la Universidad. Aunque primero aprendí otro lenguaje de programación menos conocido (Modula-2), rápidamente pasé a Java para hacer todas las diferentes tareas y prácticamente cada tarea en mi camino como estudiante y luego como ingeniero de software.

Siempre estaba buscando el mejor IDE que pudiera encontrar para acelerar mis tareas de programación. La principal opción era Eclipse en la universidad, pero nunca fui fan de Eclipse, y eso se convirtió en un problema.

Si estás en la industria del Software Empresarial, habrás notado que prácticamente todas las herramientas basadas en Desarrolladores están basadas en Eclipse porque su licencia y la comunidad detrás lo hacen la mejor opción. Pero nunca pensé que Eclipse fuera un gran IDE, era demasiado flexible pero al mismo tiempo demasiado complejo.

Así que en ese momento es cuando descubrí NetBeans. Creo que la primera versión que probé fue en la rama 3.x, y Sun Microsystem lo desarrolló en ese momento. Era mucho mejor que Eclipse. De hecho, la cantidad de plugins disponibles no era comparable con Eclipse, pero las cosas que hacía, las hacía increíblemente bien.

Para mí, si necesito declarar por qué en ese momento NetBeans era mejor que Eclipse, probablemente las principales cosas serían estas:

Simplicidad en la Configuración de Ejecución: Aún creo que la mayoría de los IDE de Java hacen las cosas demasiado complejas solo para ejecutar el código. NetBeans simplemente ejecuta sin necesidad de crear una Configuración de Ejecución y configurarla (puedes hacerlo, pero no estás obligado a hacerlo)
Mejor Apariencia: Esto se basa más en una preferencia personal, pero prefiero la configuración predeterminada de NetBeans en comparación con Eclipse.

Así que por eso, NetBeans se convirtió en mi aplicación predeterminada para hacer mi Programación Java, pero Oracle llegó, y las cosas cambiaron un poco. Con la adquisición de Sun Microsystems por parte de Oracle, NetBeans se estancó como muchos otros proyectos de código abierto. Durante años no hubo muchas actualizaciones y progreso.

No es que hayan dejado de lado el producto, pero Oracle tenía un IDE diferente en ese momento, JDeveloper, que era la opción principal. Esto es fácil de entender. Continué siendo leal a NetBeans incluso cuando teníamos otro gran competidor: IntelliJ IDEA.

Esta es la opción elegante, la que la mayoría de los desarrolladores usan hoy en día para la programación en Java, y puedo entender por qué. He intentado varias veces en mi idea tratar de sentir las mismas sensaciones que otros tuvieron, y pude leer los diferentes artículos, y reconozco algunas de las ventajas de la solución:

Mejor rendimiento: Está claro que el tiempo de respuesta del IDE es mejor con IntelliJ IDEA que con NetBeans porque no proviene de un viaje de casi 20 años, y pudo comenzar desde cero y usar enfoques modernos para la GUI.
Menos Recursos de Memoria: Seamos honestos: Todos los IDE consumen toneladas de memoria. Ninguno lo hace genial aquí (a menos que estés hablando de editores de texto con compilador de Java; esa es otra historia). NetBeans de hecho requiere más recursos para funcionar correctamente.

Así que, hice el cambio y comencé a usar la solución de JetBrains, pero nunca me convenció, porque para mí sigue siendo demasiado complejo. Muchas cosas elegantes, pero menos enfoque en las que necesito. O, simplemente porque estaba demasiado acostumbrado a cómo NetBeans hace las cosas, no pude hacer el cambio mental que se requiere para adoptar una nueva herramienta.

Y entonces… cuando todo parecía perdido, algo increíble sucedió: NetBeans fue donado a la Fundación Apache y se convirtió en Apache NetBeans. Parece una nueva vida para la herramienta proporcionando cosas simples como el Modo Oscuro y manteniendo la solución actualizada con el progreso en el Desarrollo de Java.

Así que, hoy, Apache NetBeans sigue siendo mi IDE preferido, y no podría recomendar más el uso de esta increíble herramienta. Y estos son los puntos principales que me gustaría destacar aquí:

Mejor Gestión de Maven: Para mí, la forma y la simplicidad con la que puedes gestionar tu proyecto Maven con NetBeans está fuera de esta liga. Es simple y se enfoca en el rendimiento, agregando una nueva dependencia sin ir al archivo pom.xml, actualizando dependencias sobre la marcha.
Configuración de Ejecución: Nuevamente, esto sigue siendo un diferenciador. Cuando estoy codificando algo rápido debido a un nuevo tipo de utilidad, no me gusta perder tiempo creando configuraciones de ejecución o agregando un plugin maven exec a mi pom.xml para ejecutar el software que acabo de codificar. En su lugar, necesito hacer clic en Ejecutar, un botón verde, y dejar que la magia comience.
No hay necesidad de todo lo demás: Las cosas evolucionan demasiado rápido en el mundo de la programación Java, pero incluso hoy, nunca siento que me falte alguna capacidad o algo en mi IDE NetBeans que podría obtener si me muevo a una alternativa más moderna. Así que, no hay concesiones aquí a este nivel.

Así que, soy consciente de que probablemente mi elección se deba a que tengo una visión sesgada de esta situación. Después de todo, esta ha sido mi solución principal durante más de una década, y simplemente estoy acostumbrado a ella. Pero me considero una persona abierta, y si viera una diferencia clara, no tendría dudas en abandonar NetBeans como lo hice con muchas otras soluciones en el pasado (Evernote, OneNote, Apple Mail, Gmail, KDE Basket, Things, Wunderstling.. )

Así que, si tienes curiosidad por ver cómo ha progresado Apache NetBeans, por favor echa un vistazo a la última versión y dale una oportunidad. O, si sientes que no conectas con la herramienta actual, dale una oportunidad de nuevo. ¡¡¡Quizás tengas la misma visión sesgada que yo!!!

Arquitectura Orientada a Eventos: Mejorando la Capacidad de Respuesta de su Empresa para Tener Éxito

2022-09-152021-04-06 por Alexandre Vazquez

La arquitectura impulsada por eventos proporciona más agilidad para enfrentar los cambios de un ecosistema de clientes más exigente.

Tabla de contenidos

¿Qué es un Evento?
EDA vs Arquitecturas Tradicionales
Capas de una Arquitectura Impulsada por Eventos
Resumen

El mercado está cambiando a una velocidad que requiere estar listo para cambiar muy rápidamente, los clientes se están volviendo cada vez más exigentes y necesitamos ser capaces de entregar lo que esperan, y para hacerlo necesitamos una arquitectura que sea lo suficientemente receptiva para poder adaptarse al ritmo que se requiere.

Las arquitecturas impulsadas por eventos (generalmente conocidas como EDA) son arquitecturas donde los eventos son la parte crucial y diseñamos componentes listos para manejar esos eventos de la manera más eficiente. Una arquitectura que está lista para reaccionar a lo que sucede a nuestro alrededor en lugar de simplemente establecer un camino específico para nuestros clientes.

Este enfoque proporciona muchos beneficios a las empresas debido a sus características, pero al mismo tiempo requiere una mentalidad diferente y un conjunto diferente de componentes en su lugar.

¿Qué es un Evento?

Comencemos por el principio. Un evento es cualquier cosa que pueda suceder y que sea importante para ti. Si piensas en un escenario donde un usuario simplemente está navegando por un sitio web de comercio electrónico, todo lo que tiene es un evento. Si llegamos al sitio de comercio electrónico porque tenía un enlace de referencia, eso es un evento.

Los eventos no solo ocurren en la vida virtual, sino también en la vida real. Una persona que simplemente entra al vestíbulo del hotel es un evento, ir frente al mostrador de recepción para hacer el check-in es otro, simplemente caminar a su habitación es otro… todo es un evento.

Los eventos en aislamiento proporcionan una pequeña pieza de información, pero juntos pueden proporcionar mucha información valiosa sobre los clientes, sus preferencias, sus expectativas y también sus necesidades. Y todo eso nos ayudará a proporcionar la experiencia más personalizada a cada uno de nuestros clientes.

EDA vs Arquitecturas Tradicionales

Las arquitecturas tradicionales funcionan en modo pull, lo que significa que un consumidor envía una solicitud a un servicio, ese servicio necesita otros componentes para hacer la lógica, obtiene la respuesta y responde. Todo está predefinido.

Los eventos funcionan de manera diferente porque operan en modo push, los eventos se envían y eso es todo, podría desencadenar una acción, muchas acciones o ninguna. Tienes una serie de componentes esperando, escuchando hasta que el evento o la secuencia de eventos que necesitan activar aparece frente a ellos y cuando lo hace, simplemente activa su lógica y como parte de esa ejecución genera uno o más eventos para poder ser consumidos nuevamente.

Para poder construir una arquitectura impulsada por eventos, lo primero que necesitamos es tener componentes impulsados por eventos. Necesitamos componentes de software que se activen en función de eventos y también generen eventos como parte de su lógica de procesamiento. Al mismo tiempo, esta secuencia de eventos también se convierte en la forma de completar flujos complejos en un modo de cooperación sin la necesidad de un componente maestro que esté al tanto de todo el flujo de principio a fin.

Simplemente tienes componentes que saben que cuando sucede esto, necesitan hacer su parte del trabajo y otros componentes escucharán la salida de esos componentes y se activarán.

Este enfoque se llama Coreografía porque funciona de la misma manera en una compañía de ballet donde cada uno de los bailarines puede estar haciendo diferentes movimientos, pero cada uno de ellos sabe exactamente lo que debe hacer y todos juntos en sincronía generan la pieza completa.

Capas de una Arquitectura Impulsada por Eventos

Ahora que tenemos componentes de software que se activan usando eventos, necesitamos alguna estructura alrededor de eso en nuestra arquitectura para cubrir todas las necesidades en la gestión de los eventos, por lo que necesitamos manejar las siguientes capas:

Ingesta de Eventos: Necesitamos una serie de componentes que nos ayuden a introducir y recibir eventos en nuestros sistemas. Como explicamos, hay toneladas y toneladas de formas de enviar eventos, por lo que es importante que ofrezcamos flexibilidad y opciones en ese proceso. Los adaptadores y las API son cruciales aquí para asegurarse de que todos los eventos puedan ser recopilados y formar parte del sistema.
Distribución de Eventos: Necesitamos un Bus de Eventos que actúe como nuestro Océano de Eventos donde todos los eventos fluyen para poder activar todos los componentes que están escuchando ese evento.
Procesamiento de Eventos: Necesitamos una serie de componentes para escuchar todos los eventos que se envían y hacerlos significativos. Estos componentes deben actuar como guardias de seguridad: Filtran los eventos que no son importantes, también enriquecen los eventos que reciben con información de contexto de otros sistemas o fuentes de datos, y transforman el formato de algunos eventos para que sea fácil de entender para todos los componentes que están esperando esos eventos.
Acción de Eventos: Necesitamos una serie de componentes que escuchen esos eventos y estén listos para reaccionar a lo que se ve en el Bus de Eventos tan pronto como detecten que esperan comenzar a hacer su lógica y enviar la salida nuevamente al bus para ser utilizada por alguien más.

Resumen

La arquitectura impulsada por eventos puede proporcionar un ecosistema mucho más ágil y flexible donde las empresas pueden abordar los desafíos actuales para ofrecer una experiencia atractiva a los usuarios y clientes y al mismo tiempo proporcionar más agilidad a los equipos técnicos al poder crear componentes que trabajen en colaboración pero acoplados de manera flexible, haciendo que los componentes y los equipos sean más autónomos.

Transmisión de Eventos, API e Integración de Datos: 3 Pilares que Deberías Dominar en la Nube

2022-09-132021-02-18 por Alexandre Vazquez

Transmisión de Eventos, API y Datos son los tres mosqueteros que cubren todos los aspectos de dominar la integración en la nube.

La Integración de Aplicaciones Empresariales ha sido uno de los temas más desafiantes en el panorama de TI desde el principio de los tiempos. Tan pronto como el número de sistemas y aplicaciones en grandes corporaciones comenzó a crecer, esto se convirtió en un problema que debíamos abordar. La eficiencia de este proceso también definirá qué empresas tendrán éxito y cuáles fracasarán, ya que la cooperación entre aplicaciones se vuelve crítica para responder al ritmo que el negocio demanda.

Usualmente me gusta usar la «analogía de la carretera» para definir esto:

No importa si tienes los autos más rápidos, si no tienes carreteras adecuadas no llegarás a ninguna parte

Esta situación genera muchas inversiones por parte de las empresas. Además, se lanzaron muchos proveedores y productos para apoyar esa situación. Algunas soluciones están comenzando a emerger: EAI, ESB, SOA, Middleware, Plataformas de Integración Distribuida, solución Nativa de la Nube e iPaaS.

Cada uno de los enfoques proporciona una solución para los desafíos existentes. A medida que el resto de la industria evolucionaba, las soluciones cambiaron para adaptarse a la nueva realidad (contenedores, microservicios, DevOps, API-led, Event-Driven..)

Entonces, ¿cuál es la situación hoy? Hoy en día está extendida la idea errónea de que la integración es lo mismo que API y también que API es HTTP asincrónico basado en (REST, gRPC, GraphQL) API. Pero es mucho más que esto.

1.- API

API-led es clave para la solución de integración, especialmente enfocándose en el enfoque filosófico detrás de ella. Cada componente que creamos hoy se crea con la colaboración en mente para trabajar con componentes existentes y futuros para beneficiar al negocio de una manera fácil y ágil. Esto trasciende completamente la discusión del protocolo.

API cubre todo tipo de soluciones desde API REST existentes hasta AsyncAPI para cubrir la API basada en eventos.

2.- Transmisión de Eventos

La comunicación asincrónica es necesaria porque los patrones y los requisitos cuando se habla de grandes empresas y diferentes aplicaciones hacen que esto sea esencial. Requisitos como el enfoque pub-sub para aumentar la independencia entre servicios y aplicaciones, control de flujo para gestionar la ejecución de flujos de alta demanda que pueden exceder la limitación para aplicaciones, especialmente cuando se habla de soluciones SaaS.

Entonces, puedes pensar que esta es una visión muy opinada, pero al mismo tiempo, esto es algo que la mayoría de los proveedores en este espacio han realizado basándose en sus acciones:

AWS lanza SNS/SQS, su primer sistema de mensajería, como su única solución.
Nov 2017 AWS lanza Amazon MQ, otro sistema de mensajería en cola para cubrir los escenarios que SQS no puede cubrir.
May 2019 AWS lanza Amazon MSK, un servicio gestionado para soluciones Kafka para proporcionar capacidades de distribución y procesamiento de datos en streaming.

Y esa situación es porque cuando nos alejamos de aplicaciones más pequeñas, cuando estamos migrando de un enfoque monolítico a una aplicación de microservicios, se necesitan más patrones y más requisitos, y aquí es donde las soluciones de integración han demostrado en el pasado que esto es crítico para las soluciones de integración.

3.- Integración de Datos

Usualmente, cuando hablamos de integración, hablamos de Integración de Aplicaciones Empresariales porque tenemos este sesgo del pasado. Incluso yo uso este término para cubrir este tema, EAI, porque usualmente nos referimos a estas soluciones. Pero desde los últimos años, estamos más enfocados en la distribución de datos en la empresa en lugar de cómo las aplicaciones se integran porque lo que realmente importa son los datos que están intercambiando y cómo podemos transformar estos datos en bruto en conocimientos que podamos usar para conocer mejor a nuestros clientes u optimizar nuestros procesos o descubrir nuevas oportunidades basadas en eso.

Hasta hace poco, esta parte se manejaba aparte de las soluciones de integración. Probablemente dependías de un ETL (Extract-Transform-Load) enfocado que ayuda a mover los datos de una base de datos a otra o a un tipo diferente de almacenamiento como un Data Warehouse para que tus Científicos de Datos puedan trabajar con ellos.

Pero nuevamente, la agilidad ha hecho que esto necesite cambiar, y todos los principios de integración en términos de proporcionar más agilidad al negocio también se aplican a cómo intercambiamos datos. Tratamos de evitar el movimiento técnico de los datos y tratamos de facilitar el acceso y la organización adecuada de estos datos. La Virtualización de Datos y la Transmisión de Datos son las capacidades centrales que abordan y manejan esos desafíos proporcionando una solución optimizada para cómo se distribuyen los datos.

Resumen

Mi principal expectativa con este artículo es hacerte consciente de que cuando piensas en integrar tu aplicación, esto es mucho más que la API REST que estás exponiendo, tal vez usando algún API Gateway, y las necesidades pueden ser muy diferentes. Cuanto más fuerte sea tu plataforma de integración, más fuerte será tu negocio.

Principios SOA que sobrevivieron en la arquitectura nativa de la nube

2022-09-152021-01-12 por Alexandre Vazquez

El mundo del desarrollo ha cambiado mucho, pero eso no significa que todas las cosas no sean válidas. Aprende qué principios debes tener en cuenta.

El mundo cambia rápido, y en TI, cambia aún más rápido. Todos sabemos eso, lo que generalmente significa que necesitamos enfrentar nuevos desafíos y encontrar nuevas soluciones. Ejemplos de ese enfoque son las tendencias que hemos visto en los últimos años: Contenedores, DevSecOps, Microservicios, GitOps, Service Mesh…

Pero al mismo tiempo, sabemos que TI es un ciclo en términos de que los desafíos que enfrentamos hoy son diferentes evoluciones de desafíos que se han abordado en el pasado. El objetivo principal es evitar reinventar la rueda y evitar cometer los mismos errores que las personas antes que nosotros.

Por lo tanto, creo que vale la pena revisar los principios que las Arquitecturas Orientadas a Servicios (SOA) nos proporcionaron en las últimas décadas y ver cuáles son relevantes hoy en día.

Definición de Principios

Utilizaré los principios del libro de Thomas Erl SOA Principles of Service Design y las definiciones que podemos encontrar en el artículo de Wikipedia:

1.- Abstracción de Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios para que la información publicada en un contrato de servicio se limite a lo que se requiere para utilizar efectivamente el servicio.

El objetivo principal detrás de estos principios es que un consumidor de servicios no debe ser consciente del componente particular. La principal ventaja de ese enfoque es que necesitamos cambiar el proveedor de servicios actual. Podemos hacerlo sin afectar a esos consumidores. Esto sigue siendo totalmente relevante hoy en día por diferentes razones:

Comunicación de servicio a servicio: Los Service Meshes y proyectos similares proporcionan capacidades de registro y descubrimiento de servicios basadas en los mismos principios para evitar conocer el pod que proporciona la funcionalidad.
Modo de protección SaaS habilitado: Algunos sistemas backend todavía están aquí para quedarse, incluso si tienen formas más modernas de configurarse como plataformas SaaS. Esa flexibilidad también proporciona una manera más fácil de alejarse o cambiar la aplicación SaaS que proporciona la funcionalidad. Pero toda esa flexibilidad no es real si tienes esa aplicación SaaS totalmente acoplada con el resto de los microservicios y la aplicación nativa de la nube en tu espacio.

2.- Autonomía del Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para proporcionar servicios con mayor independencia de sus entornos de ejecución.

Todos conocemos la importancia del aislamiento de servicios que los patrones de desarrollo nativos de la nube proporcionan basados en las capacidades de los contenedores para proporcionar independencia entre entornos de ejecución.

Cada servicio debe tener su propio contexto de ejecución aislado tanto como sea posible del contexto de ejecución de los otros servicios para evitar cualquier interferencia entre ellos.

Por lo tanto, eso sigue siendo relevante hoy en día, pero alentado por los paradigmas actuales como la nueva forma normal de hacer las cosas debido a los beneficios mostrados.

3.- Ausencia de Estado del Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para diseñar servicios escalables separándolos de sus datos de estado siempre que sea posible.

Los microservicios sin estado no mantienen su propio estado dentro de los servicios a través de las llamadas. Los servicios reciben una solicitud, la manejan y responden al cliente que solicita esa información. Si es necesario almacenar alguna información de estado, esto debe hacerse externamente a los microservicios utilizando un almacén de datos externo como una base de datos relacional, una base de datos NoSQL o cualquier otra forma de almacenar información fuera del microservicio.

4.- Composibilidad del Servicio

Diseño de servicios que pueden ser reutilizados en múltiples soluciones que están compuestas por servicios compuestos. La capacidad de recomponer el servicio es idealmente independiente del tamaño y la complejidad de la composición del servicio.

Todos sabemos que la reutilización no es uno de los principios detrás de los microservicios porque argumentan que la reutilización va en contra de la agilidad; cuando tenemos un servicio compartido entre muchas partes, no tenemos una manera fácil de evolucionarlo.

Pero esto se trata más de aprovechar los servicios existentes para crear nuevos que son el mismo enfoque que seguimos con el paradigma de Orquestación y Coreografía de API y la agilidad que proporciona aprovechar los existentes para crear servicios compuestos que cumplan con los objetivos de innovación del negocio.

Resumen

Los paradigmas de desarrollo de aplicaciones nativas de la nube son una evolución suave de los principios existentes. Debemos aprovechar los que aún son relevantes y proporcionar una visión actualizada de ellos y actualizar los que se necesiten.

Al final, en esta industria, lo que hacemos cada día es dar un nuevo paso en el largo viaje que es la historia de la industria, y aprovechamos todo el trabajo que se ha hecho en el pasado, y aprendemos de ello.

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

2022-09-152020-10-12 por Alexandre Vazquez

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

2022-05-092020-07-13 por Alexandre Vazquez

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.