Dos veces al año creamos el Radar Tecnológico, una mirada crítica a lo que está ocurriendo en el mundo de tecnología empresarial. En él, cubrimos herramientas, técnicas, lenguajes y plataformas generalmente ubicando más de cien 'blips'. Junto con todo este detalle, organizamos el contenido en ciertos 'temas' que pueden ayudar al lector a ver el bosque entre los árboles, y en este artículo, intento capturar no sólo temas en el Radar, sino también tendencias más amplias presentes hoy en la industria tecnológica. Estos artículos de "macro-tendencias" son sólo posibles gracias a la ayuda de la inmensa comunidad de tecnología en Thoughtworks, así que quisiera agradecer a cada persona que ha contribuído ideas y comentado en los borradores.
Pero lo cuántico aún no está listo para la hora estelar
El computador cuántico (no clasificado) más grande disponible, al momento de esta escritura, es pequeño: sólo 72 qubits. Existen muchos titulares en la prensa indicando la próxima caída de la criptografía convencional, pero las llaves RSA de 2048 bits probablemente requerirán un computador cuántico de al menos 6.000 qubits en tamaño, y algoritmos más modernos como AES tienen, probablemente, mejor seguridad contra ataques cuánticos. Se espera que un computador cuántico comercial tenga al menos 100 qubits, como también mejor estabilidad y corrección de errores con respecto a lo que está disponible hoy. Los usos prácticos de la computación cuántica aún están en el reino de ejercicios de investigación, por ejemplo, modelamiento de propiedades de moléculas complejas en la química. Por ahora, al menos, el uso común de la computación cuántica en la industria parece bastante lejos.
Mi colega George Earle y yo escribimos recientemente una serie de dos partes detallando el imperativo de modernizar así como un plan para hacerlo.
En el espacio actual de la nube vemos más y más organizaciones moverse exitosamente a la nube pública, con conversaciones y entendimientos más maduros alrededor de lo que esto significa. Compañías más grandes, hasta bancos y otras industrias reguladas, están moviendo flujos de trabajo más grandes y sensibles a la nube, y trayendo a sus reguladores en el viaje. En algunos casos, esto significa que obligatoriamente deben perseguir una estrategia multi-nube para esas cargas de trabajo. Muchos de los blips en el Radar de hoy: uso sensible de la multi-nube, simpatía financiera, entre otros, son indicadores que la nube finalmente es parte de la cultura dominante para todas las organizaciones y que la ‘larga cola’ de la migración ya llegó.
Donde las cosas se complican es si una organización simplemente asume que su carga de trabajo es apropiada para las técnicas serverless y continúa de todas formas, o no hace los cálculos sobre si sería mejor pagar por funcionalidades en uso o configurar y mantener una instancia de servidor dedicada. Nos gustaría destacar dos áreas claves donde el serverless necesita madurar:
Como un contrapunto feliz a los problemas de anti-patrones persistentes, en este Radar, destacamos que las buenas prácticas han perdurado en la industria. Cuando una nueva tecnología aparece, todas las personas experimentan con ella, intentamos comprender qué casos de uso caben mejor y cuáles son los límites de lo que puede y no puede hacer. Un buen ejemplo de esto es el énfasis reciente en data y aprendizaje automatizado. Una vez que esa cosa nueva ha sido experimentada, y hemos aprendido para lo que es buena y lo que puede hacer, necesitamos aplicar buenas prácticas de ingeniería sobre ella. En el caso del aprendizaje automatizado, recomendaríamos aplicar pruebas automatizadas y prácticas de entrega contínua; que combinadas llamamos Continuous Intelligence. El punto es que todas las prácticas que hemos desarrollado a través de los años para construir un buen software siguen siendo aplicables para todas las cosas nuevas. El hacer un buen trabajo con la ‘artesanía’ de la creación del software sigue siendo importante, sin importar cómo la tecnología subyacente cambie.
Eso es todo en esta edición de macro-tendencias. Si disfrutaste este comentario, te podría también gustar nuestra recientemente relanzada serie de podcasts, donde yo soy un anfitrión junto con varias de mis colegas de Thoughtworks. Estrenamos un podcast cada dos semanas cubriendo temas como ciencia de datos ágil, sistemas distribuidos, inteligencia continua y IoT. ¡Échale un vistazo!
Traducción al español realizada por: David Corrales y Felipe Ramirez
La Computación Cuántica ya llegó pero, a la vez, todavía no
Seguimos viendo tracción en el campo de la computación cuántica. Las instituciones académicas se están asociando con organizaciones comerciales, se están haciendo grandes inversiones y la comunidad de startups y spinouts universitarios está brotando. El lenguaje Q# de Microsoft permite a los desarrolladores iniciarse en computación cuántica y correr algoritmos contra máquinas simuladas, así como también experimentar con computadores cuánticos reales basados en la nube. El IBM Q es su competidor, que de forma similar ha establecido alianzas con grandes organizaciones comerciales, la academia, y startups. A nivel local, hemos sido anfitriones de hack nights de computación cuántica con una asistencia de la comunidad extremadamente buena.Pero lo cuántico aún no está listo para la hora estelar
El computador cuántico (no clasificado) más grande disponible, al momento de esta escritura, es pequeño: sólo 72 qubits. Existen muchos titulares en la prensa indicando la próxima caída de la criptografía convencional, pero las llaves RSA de 2048 bits probablemente requerirán un computador cuántico de al menos 6.000 qubits en tamaño, y algoritmos más modernos como AES tienen, probablemente, mejor seguridad contra ataques cuánticos. Se espera que un computador cuántico comercial tenga al menos 100 qubits, como también mejor estabilidad y corrección de errores con respecto a lo que está disponible hoy. Los usos prácticos de la computación cuántica aún están en el reino de ejercicios de investigación, por ejemplo, modelamiento de propiedades de moléculas complejas en la química. Por ahora, al menos, el uso común de la computación cuántica en la industria parece bastante lejos.
Ritmo de cambio hiperquinético
Frecuentemente observamos que el ritmo de cambio en la tecnología no sólo es rápido, sino que además se está acelerando. Cuando iniciamos el Radar hace una década, por defecto, las entradas se presentaban por dos ediciones (aproximadamente un año) sin movimiento antes que desaparecieran automáticamente. Sin embargo, tal como se indica en uno de nuestros temas del Radar —ritmo = distancia / tiempo— el cambio en el ecosistema de desarrollo de software continúa acelerando. El tiempo ha permanecido constante (aún creamos el Radar dos veces al año), pero la distancia recorrida en términos de innovación tecnológica ha aumentado notablemente, entregando aún más evidencia de lo que es obvio para cualquier observador astuto: el ritmo de cambio en la tecnología continúa incrementándose. Vemos un ritmo incrementado en todos los cuadrantes del Radar, y también en el apetito de nuestros clientes por adoptar nuevas y diversas tecnologías. Dado que casi todo en el mundo hoy en negocios, política, y sociedad está dirigido por tecnología, el ritmo de cambio en todas estas áreas se incrementa también. Un corolario importante para los negocios es que habrá mucho menos tiempo disponible para adoptar nuevas tecnologías y modelos de negocio; es aún “adáptate o muere”, pero la presión es ahora mayor que nunca.Para que las compañías compitan, se requiere modernización continua
La necesidad de actualizar y reemplazar tecnología antigua no es nueva. Desde que las computadoras han existido un nuevo modelo ha estado en planes o justo a la vuelta de la esquina, pero se siente que el “nivel de volumen” que necesita modernizarse ha incrementado. Los negocios necesitan moverse rápido, y no pueden hacerlo cuando están siendo detenidos por sus bienes de tecnología legada. Los negocios modernos compiten para ofrecer las mejores experiencias a sus clientes; la lealtad a las marcas está casi muerta, y los que se muevan más rápido a menudo ganan. Este asunto pega a todas las compañías, hasta a las queridas de Silicon Valley y a los unicornios startup del mundo, porque casi tan pronto como algo está en producción, ya puede ser considerado tecnología legada y un ancla en vez de una ventaja. El éxito de estas compañías está en actualizar constantemente y refinar su tecnología y plataformas.Mi colega George Earle y yo escribimos recientemente una serie de dos partes detallando el imperativo de modernizar así como un plan para hacerlo.
La industria se pone al día con los grandes cambios
Fue obvio para nosotros que los contenedores (especialmente Docker) y las plataformas de contenedores (especialmente Kubernetes) eran importantes desde un principio. Hace un par de Radares, declaramos que Kubernetes había ganado la batalla y era la plataforma moderna preferida; la industria ahora parece estar de acuerdo. Hay una cantidad fenomenal de blips relacionados a Kubernetes en esta edición del Radar: Knative, gVisor, Rook, SPIFFE, kube-bench, Jaeger, Pulumi, Heptio Ark y acs-engine, por nombrar sólo unos pocos. Todas estas ayudan con el ecosistema Kubernetes, escaneo de configuraciones, auditoría de seguridad, recuperamiento de desastres y más. Todas estas herramientas nos ayudan a construir clusters más fácil y fiablemente.Anti-patrones empresariales persistentes
En esta edición del Radar, muchas de las entradas en ‘Resistir’ son simplemente nuevas maneras de estar equivocado al construir sistemas empresariales. Tenemos nuevas herramientas y plataformas, pero tendemos a seguir cometiendo los mismos errores. Aquí algunos ejemplos:- Recreando anti-patrones ESB con Kafka—esta es la “enorme caja de spaghetti” una vez más, donde una tecnología perfectamente buena (Kafka) está siendo abusada en nombre de la centralización o eficiencia.
- Portales de API demasiado ambiciosos—una tecnología perfectamente buena para la gestión de accesos y limitación de velocidad en las APIs también resulta tener lógica de transformación y negocios añadidos.
- Paquetes hambrientos de Datos—compramos un paquete de software para hacer una cosa, pero termina apoderándose de nuestra organización, alimentándose de más y más datos y accidentalmente, convirtiéndose en ‘dueño’ de todo, mientras también requiere de mucho trabajo de integración.
La Comunidad de JavaScript empieza a silenciarse
Previamente hemos escrito sobre las rotaciones frecuentes en el ecosistema de JavaScript pero la comunidad al parecer está emergiendo de un periodo de crecimiento rápido a uno con menos emoción. Nuestros contactos dentro de la industria de la publicación nos dicen que búsquedas de contenidos relacionados a JavaScript han sido reemplazadas por un interés en un grupo de lenguajes liderados por Go, Rust, Kotlin, y Python. ¿Será que la Ley de Atwood ha pasado: que todo lo que puede ser escrito en JavaScript ya ha sido escrito en JavaScript, y que el desarrollo se ha movido hacia nuevos lenguajes? Esto también puede ser un efecto del auge de los microservicios, donde un enfoque políglota es mucho más viable, permitiendo que las personas desarrolladoras experimenten con el uso del mejor lenguaje para cada componente. De cualquier manera, hay mucho menos JavaScript en esta edición de nuestro Radar.La nube ocurrió y sigue ocurriendo
Uno de nuestros temas en este Radar es la sorprendente ‘adherencia’ a los proveedores de la nube, quienes están en una carrera apretada para ganar negocios de hosting y a menudo añaden funcionalidades y servicios para hacer su producto más atractivo. El uso de estas funcionalidades específicas de un proveedor puede accidentalmente amarrar a los clientes a ellos aunque, por supuesto, acelerará la entrega, así que son una espada de doble filo.Como siempre, recomendamos entrar con los ojos abiertos y evaluando casos de uso, potencial bloqueo con un proveedor, y el costo e impacto en el caso de necesitar cambiar de proveedores.
En el espacio actual de la nube vemos más y más organizaciones moverse exitosamente a la nube pública, con conversaciones y entendimientos más maduros alrededor de lo que esto significa. Compañías más grandes, hasta bancos y otras industrias reguladas, están moviendo flujos de trabajo más grandes y sensibles a la nube, y trayendo a sus reguladores en el viaje. En algunos casos, esto significa que obligatoriamente deben perseguir una estrategia multi-nube para esas cargas de trabajo. Muchos de los blips en el Radar de hoy: uso sensible de la multi-nube, simpatía financiera, entre otros, son indicadores que la nube finalmente es parte de la cultura dominante para todas las organizaciones y que la ‘larga cola’ de la migración ya llegó.
Serverless gana tracción, pero aún no es contundente
Las arquitecturas “serverless” son una de las tendencias más grandes en el ambiente actual de TI, pero quizás también la más malentendida. En esta edición del Radar, de hecho, no destacamos ningún blip de la tecnología serverless. Lo hemos hecho en el pasado pero esta vez sentimos que nada cumplió con lo esperado. Sin embargo, esto no quiere decir que las cosas se han calmado en el espacio serverless. Amazon recientemente liberó SLAs para Lambda, algo que es relativamente raro para servicios de AWS y casi todo en la plataforma AWS tiene algún lazo a Lambda. Los otros grandes proveedores ofrecen servicios que compiten (pero son similares) y tienden a responder siempre que Amazon hace algún movimiento en este espacio.Donde las cosas se complican es si una organización simplemente asume que su carga de trabajo es apropiada para las técnicas serverless y continúa de todas formas, o no hace los cálculos sobre si sería mejor pagar por funcionalidades en uso o configurar y mantener una instancia de servidor dedicada. Nos gustaría destacar dos áreas claves donde el serverless necesita madurar:
- Patrones de uso: Modelos arquitectónicos y de carga de trabajo donde el enfoque es o no el indicado. Se necesita un mejor entendimiento sobre cómo componer una aplicación de componentes serverless tal como con contenedores y máquinas virtuales.
- Modelo de precios: No son bien entendidos o fáciles de afinar, lo que lleva a facturas altas y aplicabilidad limitada. Idealmente, deberíamos comparar el Coste Total de Propiedad incluyendo cosas como tiempo de ingeniería DevOps, mantenimiento de servidores y otros.
Ingeniería para fallas
En el pasado, hemos destacado las herramientas de prueba Simian Army de Netflix que causan deliberadamente fallas en un sistema en producción, para asegurar que tu arquitectura puede tolerar fallas. Este Chaos Engineering se ha esparcido y extendido a áreas relacionadas. En este Radar, destacamos el 1% Canary y Security Chaos Engineering como instancias específicas de la ingeniería para fallas.
Buenas prácticas duraderas
Como un contrapunto feliz a los problemas de anti-patrones persistentes, en este Radar, destacamos que las buenas prácticas han perdurado en la industria. Cuando una nueva tecnología aparece, todas las personas experimentan con ella, intentamos comprender qué casos de uso caben mejor y cuáles son los límites de lo que puede y no puede hacer. Un buen ejemplo de esto es el énfasis reciente en data y aprendizaje automatizado. Una vez que esa cosa nueva ha sido experimentada, y hemos aprendido para lo que es buena y lo que puede hacer, necesitamos aplicar buenas prácticas de ingeniería sobre ella. En el caso del aprendizaje automatizado, recomendaríamos aplicar pruebas automatizadas y prácticas de entrega contínua; que combinadas llamamos Continuous Intelligence. El punto es que todas las prácticas que hemos desarrollado a través de los años para construir un buen software siguen siendo aplicables para todas las cosas nuevas. El hacer un buen trabajo con la ‘artesanía’ de la creación del software sigue siendo importante, sin importar cómo la tecnología subyacente cambie.
Eso es todo en esta edición de macro-tendencias. Si disfrutaste este comentario, te podría también gustar nuestra recientemente relanzada serie de podcasts, donde yo soy un anfitrión junto con varias de mis colegas de Thoughtworks. Estrenamos un podcast cada dos semanas cubriendo temas como ciencia de datos ágil, sistemas distribuidos, inteligencia continua y IoT. ¡Échale un vistazo!
Traducción al español realizada por: David Corrales y Felipe Ramirez
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.