Tendencias de desarrolladores del Radar de tecnología de Thoughtworks 27

El radar de tecnología de Thoughtworks es un momento habitual para echar un vistazo a lo que los expertos de la industria creen que podría ser la próxima ola de herramientas, prácticas y tecnologías para considerar o dejar de usar.

Siempre espero agregar muchos "puntos" nuevos a mi lista, o ver cuáles están creciendo en adopción desde la última vez que echaste un vistazo.

La versión 27 ya está disponible y continúa algunas tendencias que el radar ha estado siguiendo durante un tiempo, como "plataforma como servicio" o formas de programación grupal. Este resumen está lejos de ser completo, pero solo los puntos que me atrajeron o que, pensé, podrían atraerlo a usted.

Si alguno de ellos te interesa, o si tienes una opinión sobre algo que he presentado, dirígete a tu perfil y cuéntaselo a nuestros lectores .

Integración del aprendizaje automático

Realmente parece que en los últimos 6 meses más o menos, el aprendizaje automático pasó de ser algo con lo que en su mayoría solo interactuaban los desarrolladores y científicos de datos a algo de lo que el público era consciente.

Hubo un anuncio tras otro de otra herramienta basada en ML o IA que escupía algún tipo de contenido multimedia después de introducir algo en ella, y nos inundaron miles de imágenes y videos de celebridades de aspecto extraño.

Esto también significa que los desarrolladores interesados en experimentar con ML también tienen muchos más recursos disponibles en forma de conjuntos de datos y marcos para usar esos conjuntos de datos.

De relevancia para los desarrolladores experimentados es TinyML , un campo de aprendizaje automático que permite una variedad de casos de uso siempre activos y apunta a dispositivos que funcionan con baterías.

Otro son las tiendas de características , un método para crear canalizaciones de ML que pueden ser más familiares para los desarrolladores de otros entornos.

Este radar también cubrió herramientas relacionadas con ML para mejorar la experiencia del desarrollador de construir y entrenar modelos, por ejemplo, la práctica de "aprendizaje automático federado" para agregar datos de modelos a través de máquinas para procesamiento o datos sintéticos para pruebas de modelos iniciales.

Observabilidad continua

A pesar de ser un término relativamente nuevo, "observabilidad" ha pasado rápidamente de ser una colección suelta de prácticas y estándares para crear una mejor imagen de un sistema en funcionamiento a convertirse en un término más amplio que significa todo tipo de cosas.

La última área del flujo de trabajo del desarrollador para recibir información es una que me sorprende que tomó tanto tiempo, la observabilidad para la integración continua y las canalizaciones de entrega.

Si bien CI y CD sin duda brindan beneficios, los procesos suelen fallar con muy poca información sobre lo que sucede hasta que lo intenta, vuelva a intentarlo.

Ahora, un puñado de proveedores de observabilidad existentes y proyectos de código abierto están trayendo visualizaciones de estilo de seguimiento de procesos continuos para ayudarlo a depurar lo que estaba sucediendo.

Lista de materiales del software

A medida que los desarrolladores se apoyan cada vez más en contenedores y paquetes semianónimos para su trabajo, los que se centran en la seguridad y la legalidad miraban y se preguntaban: "¿Confiamos en esto?".

Esta preocupación ha llevado a una carrera por estandarizar y normalizar (en la empresa, especialmente) una "lista de materiales de software", a menudo denominada por el acrónimo cómico, SBOM.

Si bien, en teoría, "cualquiera" puede profundizar en un proyecto de código abierto y ver cuáles son sus componentes, generalmente es más fácil decirlo que hacerlo y no es posible en absoluto con proyectos de código cerrado.

Las recientes vulnerabilidades de alto perfil en el software revelaron cómo las dependencias pequeñas pueden traer problemas tan grandes. Si bien los SBOM podrían ser de gran ayuda, me pregunto cuántas empresas querrán revelar su funcionamiento interno y ser honestas al respecto.

Codificación sostenible

Este es un tema que me inspiré a cubrir después de hablar con alguien de Thoughtworks sobre su herramienta de huella de nube de carbono.

La tendencia a lanzar continuamente nuevos marcos, herramientas y marcos en la nube a un problema ha llevado a muchos de nosotros a olvidar que todas estas líneas de código en realidad se ejecutan en alguna parte de algo.

Y eso conduce a las emisiones de carbono. El agua motivada por razones altruistas o económicas, y una recesión ecuménica conduce al ahorro de costes, este es un tema del que más se habla y se piensa.

Estrechamente relacionado con el costo ambiental de los proyectos y su infraestructura, y una opción que he visto que usan los equipos de producción es el infracosto , que estima el impacto en el costo de los cambios que realiza en las definiciones de Terraform.

Responsabilidades como Código

Cualquier empresa SaaS define indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO) que sus clientes pueden esperar.

Sin embargo, la forma en que las empresas los definieron a menudo ha sido un poco aleatoria y no estándar, y con tantas otras cosas definidas en canalizaciones codificadas, ¿por qué no este componente fundamental también?

Varios proveedores de Observability ahora ofrecen esta opción y, por supuesto, un grupo de personas comenzó un estándar, OpenSLO .

Un no al nodo

Hago incursiones en JavaScript y TypeScript y recientemente noté un puñado de alternativas de tiempo de ejecución emergentes para Node. No estoy seguro de qué tiene de malo Node, además de ser bastante viejo ahora, para garantizar alternativas, pero supongo que la competencia es buena 🤷‍♂️.

Bun es una alternativa más nueva que probé hace unos meses, y admito que no estaba muy seguro de los beneficios que me brindaba, pero usa JavaScriptCore de WebKit en lugar del motor V8 de Chrome.

Una vez más, la variedad no es algo malo. Bun está escrito en Zig , del que nunca había oído hablar antes, y afirma ser un reemplazo de C/C++ "directo".

Lo que lleva muy bien a…

C++

Si Zig, Rust y otros lenguajes son válidos, muchas personas sienten que C ++ necesita un reemplazo más moderno. Google ha lanzado otra opción a la lista de contendientes con Carbon .

El lenguaje aún se encuentra en etapas experimentales, pero afirma ser más fácil de entender y de incorporar. Google tiene una tendencia a poner en marcha muchos proyectos experimentales y luego volcarlos de nuevo, por lo que la sugerencia de Thoughtworks actualmente es "esperar y ver".