La creciente complejidad de los sistemas de software modernos está matando lentamente a los desarrolladores de software. ¿Cómo puede recuperar el control sin perder lo mejor que estas tecnologías tienen para ofrecer?
por Scott Carey
“La complejidad mata”, escribió Ray Ozzie, creador de Lotus Notes y veterano de Microsoft, en un memorando interno de 2005 . “Le quita la vida a los desarrolladores; hace que los productos sean difíciles de planificar, construir y probar; presenta desafíos de seguridad; y causa frustración al usuario y al administrador”.
Si Ozzie pensó que las cosas eran complicadas en ese entonces, no puede evitar preguntarse qué pensaría de la complejidad que enfrentan los desarrolladores de software en la era nativa de la nube.
El cambio de crear aplicaciones en una arquitectura monolítica alojada en un servidor que se puede tocar, a dividirlas en múltiples microservicios , empaquetados en contenedores, orquestados con Kubernetes y alojados en un entorno de nube distribuida, marca un claro salto en el nivel de complejidad de nuestro software. Agregue a eso las expectativas de experiencias ricas en funciones y de nivel de consumidor, que son seguras y resistentes por diseño, y nunca se les ha pedido más a los desarrolladores.
“Hay un claro aumento en la complejidad cuando se pasa a un entorno de microservicios tan generalizado”, dijo el CTO de Amazon, Werner Vogels , durante la Cumbre de AWS en 2019 . “¿Era más fácil en los días en que todo estaba en un monolito? Sí, para algunas partes definitivamente”.
O, como dijo su colega, la jefa de marketing de productos de desarrollo en AWS, Emily Freeman, en 2021, el desarrollo de software moderno es “un estudio de entropía, y no se vuelve más simple”.
Por otro lado, las tecnologías complejas nunca han sido tan fáciles de consumir listas para usar, a menudo a través de una sola API, desde bibliotecas y marcos básicos hasta capacidades de reconocimiento de imágenes o incluso pilas de pagos completas. Simplemente ensamble y construya su lógica de negocios en la parte superior. Pero, ¿es realmente así de simple?
“Nunca ha sido tan difícil ser un desarrollador de software como lo es hoy”, dijo Nigel Simpson, consultor y exdirector de estrategia de tecnología empresarial de Walt Disney. “Si bien hemos visto una mejora de las capacidades que permiten a los desarrolladores hacer más mediante el uso de marcos de trabajo de alto nivel para el desarrollo de aplicaciones y el aprendizaje automático, esto tiene un costo. La explosión de opciones y el ritmo de desarrollo hacen que sea un desafío para los desarrolladores mantenerse al día con el espíritu de la época, y muchos desarrolladores quedan atrapados en los faros”.
Complejidad esencial versus accidental
Justin Etheredge, cofundador de la agencia de software Simple Thread, diferencia útilmente entre complejidad esencial y accidental. Le dijo a InfoWorld: “Es esencial la complejidad en el dominio comercial en el que está trabajando, el hecho de que las empresas son entornos extremadamente complicados, por lo que los problemas que intentan resolver son inherentemente complejos. La otra área es accidental; esta es la complejidad que viene con nuestras herramientas y lo que superponemos al resolver un problema”.
La era nativa de la nube ha dado paso al potencial de una mayor complejidad accidental que nunca, estableciendo un curso de colisión entre los desarrolladores, que quieren aprovechar el conjunto completo de herramientas disponible para ellos, y sus jefes, que quieren que se centren en ofrecer valor a los clientes. .
“Dada la demanda actual de desarrolladores de software , las empresas no tienen la influencia para empujar a los desarrolladores hacia un modelo mental de entregar principalmente valor a sus clientes”, dijo Etheridge. “Hacer que más ingenieros piensen de esa manera es un desafío”.
La desventaja de elegir
La popularidad combinada de la computación en la nube y el movimiento del software de código abierto ha hecho que la cantidad de opciones disponibles para que los desarrolladores construyan y ejecuten aplicaciones más escalables, resistentes, modulares y actualizables aumente a un ritmo inexorable.
“Antes todo era mucho más simple, no porque cometiéramos un error como industria, sino porque la demanda de esos sistemas creció tan dramáticamente que tenemos que enviar más rápido”, dijo Kaspar von Grünberg, fundador de Humanitec, una startup que ayuda a las empresas. construir sus propias plataformas de desarrollo, en una entrevista con InfoWorld.
La Cloud Native Computing Foundation (CNCF) mantiene un gráfico interactivo de los casi 1000 servicios únicos que conforman el ecosistema nativo de la nube, muchos de los cuales son gratuitos y de código abierto. Además, cada uno de los tres grandes proveedores de la nube (Amazon Web Services, Microsoft Azure y Google Cloud) ofrece alrededor de 200 servicios únicos a los clientes, en computación, almacenamiento, base de datos, análisis, redes, dispositivos móviles, herramientas para desarrolladores, herramientas de administración, IoT, seguridad y aplicaciones empresariales.
“El proceso de desarrollo de aplicaciones simplemente está demasiado fragmentado en este momento; los días en que todas las arquitecturas empresariales tenían tres niveles, todas las bases de datos eran relacionales y todas las aplicaciones comerciales se escribían en Java y se implementaban en un servidor de aplicaciones han terminado”, escribió Stephen O’Grady, analista de RedMonk, en una publicación de blog de 2020 . “La característica más definitoria de la infraestructura actual es que no existe una característica definitoria única. Es diverso hasta la exageración”.
O, como escribió el ex CTO de Tumblr, Marco Arment, en 2015 : “El desarrollo web nunca ha sido más complicado o enrevesado de lo que es hoy en día debido a la gran cantidad de herramientas (y su rápida tasa de cambio) involucradas en la mayoría de los sitios web modernos. entornos de desarrollo”.
Una de las consecuencias del enfoque comprobado que los proveedores de la nube han adoptado para el desarrollo de productos (pequeños equipos independientes de dos pizzas que crean servicios en respuesta a las demandas de los clientes) es que los desarrolladores han sido en gran medida facultados para elegir cómo ensamblar esta multitud. de componentes básicos juntos de una manera que ofrece valor comercial.
“Eres como un niño en la tienda de golosinas en la nube”, dijo Camille Fournier, directora de ingeniería de plataformas de la firma de servicios financieros Two Sigma, en una entrevista con InfoWorld. “Pero a medida que creces y tratas de hacer que las cosas encajen, la complejidad se multiplica absolutamente”.
Lo que lleva a muchos a preguntarse si este nivel de elección es positivo para el desarrollador de software promedio. O, como concluyó O’Grady en esa publicación de blog de 2020 , “La complejidad inherente a un enorme catálogo de servicios disponibles puede convertirse, en ciertos entornos, en una desventaja más que en una fortaleza”.
Construyamos una plataforma interna
Este creciente nivel de complejidad ha llevado a muchas organizaciones a adoptar un modelo de plataforma central, en el que un equipo de plataforma interna tiene la tarea de examinar las herramientas que más necesitan los ingenieros, crear plantillas y trazar caminos dorados para facilitar su viaje hacia la producción , al mismo tiempo que centraliza funciones. como operaciones financieras , seguridad y gobernanza para aliviar la carga cognitiva de los desarrolladores individuales.
Tomemos como ejemplo al gigante de la transmisión de música Spotify. “Al retroceder unos seis años, Spotify estaba (y sigue estando) comprometido con una cultura de ingeniería ágil con equipos autónomos”, escribió el gerente de producto de Spotify, Gary Niemen, en una publicación de blog de 2020 . “Con todas las ventajas que trae, también generó complejidades, incluido un ecosistema fragmentado de herramientas para desarrolladores donde la única forma de averiguar cómo hacer algo era preguntarle a su colega”.
A medida que Spotify escalaba, descubrió que el enfoque que había impulsado su rápido crecimiento en realidad estaba comenzando a ralentizarlo. Necesitaba consolidar y simplificar. “Las herramientas bendecidas o recomendadas deben ser fácilmente detectables. El viaje a través de esa herramienta debe ser claro. Debe haber instrucciones de calidad para el usuario a lo largo del camino. Y, si los usuarios se atascan, debería ser obvio dónde obtener soporte”, escribió Niemen.
Entonces, la clave para una buena plataforma de desarrollo interna es encontrar ese equilibrio entre el autoservicio para los desarrolladores que quieren continuar con el trabajo y abstraer las tareas que son menos valiosas, sin hacer que los desarrolladores se sientan restringidos, escribió von Grünberg de Humanitec en una publicación de blog de 2021 .
“La idea detrás de tener caminos dorados no es limitar ni sofocar a los ingenieros, ni establecer estándares por el simple hecho de hacerlo. Con caminos dorados en su lugar, los equipos no tienen que reinventar la rueda, tienen menos decisiones que tomar y pueden usar su productividad y creatividad para objetivos más altos. Pueden volver a moverse rápidamente”, escribió el gerente de producto de Spotify, Niemen .
El problema es que “a los desarrolladores les encanta reinventar la rueda. Nada me satisface más que construir una ratonera mejor”, dijo el consultor Simpson. Pero en un mundo donde muchas de las respuestas se encuentran en Stack Overflow, ¿es este el mejor uso del tiempo de los desarrolladores?
Amanda Silver, CVP de Producto, División de Desarrolladores de Microsoft, dijo: “Siempre habrá algunas organizaciones que intenten tomar medidas drásticas y otras que intenten empoderar a los desarrolladores. El núcleo es la noción de velocidad del revelador. Podemos crear sistemas en los que el desarrollador pueda escribir el código que solo él puede escribir y no se distraiga ni se sienta agobiado por aprender dominios que no se diferencian para él”.
Fundada en 1987, la empresa de tecnología de viajes Amadeus ha sobrevivido a estas oleadas de cambios tecnológicos, ya que creó sus aplicaciones originales en el mainframe, pasó a construir sobre una plataforma Linux abierta a principios de la década de 2000 y ahora se inclina fuertemente hacia las aplicaciones en contenedores orquestadas con Kubernetes .
“Nuestros desarrolladores deben poder desarrollarse sobre el núcleo que ofrecemos, por lo que la idea es un enfoque de plataforma en el que les proporcionemos capacidades”, dijo a InfoWorld Edouard Hubin, jefe de infraestructura y nube de Amadeus. “Las nuevas tecnologías traen más complejidad para la seguridad y la estabilidad. Cuando abres un sistema como este, quieres estabilidad. El auge de las aplicaciones basadas en datos es un nivel de complejidad completamente diferente para nosotros… Trae una nueva forma de escribir aplicaciones y crear ciclos de retroalimentación. Todas estas cosas son nuevas y traen complejidad”.
Como resultado, Hubin quiere ocultar la complejidad donde pueda, ya sea a través de un equipo interno que diseñe soluciones o pagando por servicios administrados donde tengan sentido. Tomemos las bases de datos como ejemplo. Amadeus solía gestionar sus propias instancias de MongoDB, pero ahora utiliza la opción MongoDB Atlas gestionada por el proveedor . La compañía está adoptando una visión similar sobre los Kubernetes administrados .
Eso no significa que los ingenieros no presionen para que se traigan nuevas herramientas al ecosistema. “A veces tienes que decir que no”, dijo Hubin. “Recientemente, tuvimos gente tratando de incorporar una nueva base de datos. Tenían razón, pero si la opción estándar no es tan buena, [todavía] en general es mejor para la empresa controlar la cantidad de bases de datos que usamos”.
Cada gran organización tiene una amplia cohorte de ingenieros, algunos que se enfocan en construir sistemas resilientes y que brindan funciones a los clientes a gran velocidad, y otros que desean desesperadamente jugar con la última tecnología. Ambos tienen valor, pero deben administrarse con cuidado, dijo Fournier de Two Sigma.
“Quieres personas que estén emocionadas por mirar debajo del capó y comprender cosas nuevas, porque necesito personas que administren Kubernetes sin sistema operativo, pero también necesito personas que estén emocionadas por investigar cosas nuevas, comprender cómo funciona, identificar dónde puede ser útil en toda la empresa: buenos socios para crear prototipos y determinar si vale la pena invertir para desbloquearlo”, dijo.
Cómo los proveedores se enfrentan a la complejidad
Al igual que muchos de sus pares en el negocio del software en la nube, Kelsey Hightower, principal defensora de los desarrolladores en Google Cloud, considera que el nivel actual de opciones disponible para los desarrolladores es tanto un “regalo como una maldición”.
El regalo es la disponibilidad de un catálogo casi ilimitado de tecnología para construir. La maldición es que los desarrolladores “se ven arrastrados a situaciones en las que filtramos la infraestructura en su flujo de trabajo”. Ahora, con muchos proveedores centrados en los servicios gestionados y la abstracción , el péndulo parece estar oscilando hacia el otro lado. Después de la gran fragmentación, ¿nos espera una gran consolidación?
“Hay más en esta profesión que escribir código; ese es el medio para un fin”, dijo Hightower. “Tal vez estamos diciendo que hemos construido lo suficiente y podemos hacer una pausa en la construcción de cosas nuevas, para madurar lo que tenemos y volver a nuestros respectivos roles de consumo de tecnología. Tal vez este sea el final feliz del movimiento de desarrollo y colaboración que hemos visto en la última década”.
El mercado está respondiendo a esta complejidad con una lista cada vez mayor de servicios obstinados, opciones administradas, marcos, bibliotecas y plataformas para ayudar a los desarrolladores a lidiar con la complejidad de su entorno.
“Ningún proveedor está o estará en condiciones de proporcionar todas las piezas necesarias, por supuesto. Incluso AWS, con la cartera de aplicaciones más diversa y una cadencia de lanzamiento históricamente sin precedentes, no puede satisfacer todas las necesidades de los desarrolladores y no puede poseer todas las comunidades de desarrolladores relevantes”, escribió O’Grady en una publicación de blog de 2020.
Dicho esto, “existe amplia evidencia que sugiere que nos estamos alejando de enviar a compradores y desarrolladores por igual a un laberinto de pasillos, cargándolos con la tarea de elegir primitivos y ensamblarlos desde cero. Si la primera era de la nube está definida por primitivos, sus días están llegando a su fin. Es probable que el próximo se defina, como lo ha hecho la industria informática desde sus inicios, las abstracciones que construimos sobre esas primitivas”, escribió O’Grady, en una publicación diferente .
Si bien el ensamblaje de estas primitivas en plataformas internas coherentes ya ha demostrado ser una solución exitosa para muchas organizaciones dirigidas por ingeniería, las empresas más tradicionales definitivamente buscarán a sus proveedores para ayudarlas a aliviar esta complejidad.
Fuente: https://www.infoworld.com/article/3639050/complexity-is-killing-software-developers.html