Codificación dentro de las limitaciones de la empresa

Suponiendo que haya al menos algún nivel de desarrollo de software que ocurre en todos los negocios, debe funcionar de manera óptima, ser de alta calidad y ser lo más rentable posible. Al mismo tiempo, la pandemia ha demostrado que se puede recurrir a algunos software para hacer cosas que van mucho más allá de sus objetivos de diseño originales.

Parece haber algunas áreas de la tecnología que resuenan entre los expertos con los que Computer Weekly ha hablado sobre lo que define el desarrollo de software moderno. Encabezando la lista están los microservicios en contenedores. Uno de los principales beneficios de este enfoque es que el código se puede desarrollar, probar, implementar y ejecutar en producción de una manera que limita su impacto en la estabilidad del sistema de TI en general.

Organización para microservicios

Ley de Conway establece que cualquier organización que diseñe un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicaciones de la organización. Según Perry Krug, director de éxito del cliente en Couchbase, la ley de Conway no puede combatirse, pero cree que al comprender su influencia, es posible trabajar dentro de sus limitaciones.

Su influencia se extiende al ámbito del desarrollo de software, lo que significa que las prácticas modernas de desarrollo de software deben conocer la estructura organizativa que existe dentro de una empresa.

En un nivel, esto puede parecer contradecir las prácticas de trabajo más colaborativas que definen el desarrollo de software moderno. «Es necesario colaborar para desarrollar aplicaciones con éxito», dice Krug. “Si las nuevas formas de trabajar dificultan la colaboración estrecha, colabore de forma flexible. Si los recursos compartidos están causando limitaciones y cuellos de botella, acople el software de forma más flexible a sus cimientos. Tendencias como los microservicios son un reconocimiento explícito de estas limitaciones y ahora deberían estar cobrando fuerza «.

Algunos expertos de la industria creen que la arquitectura de microservicios potencia la innovación de software.

Uno de ellos es Arup Chakrabarti, director senior de ingeniería de PagerDuty. “Los microservicios permiten un enfoque mucho mayor en la experiencia del cliente que antes”, dice. “Aislar áreas de la base de código general permite la creación de mini fábricas de innovación en toda la empresa, cada una operando a su propio ritmo. Con menos para integrar, hay menos pasos «.

Sin embargo, en la experiencia de Chakrabarti, el uso de microservicios en sí mismo puede conducir a una explosión en la complejidad y todos los desafíos que conlleva.

Bloomberg, por ejemplo, ha dividido algunas de sus aplicaciones monolíticas en microservicios en contenedores que se ejecutan como parte de una malla de servicios. Pero esta arquitectura ha traído consigo su propio conjunto de desafíos, especialmente porque a veces puede ser difícil para los desarrolladores comprender completamente lo que está sucediendo realmente.

Peter Wainwright, ingeniero senior del equipo de experiencia del desarrollador (DevX) en Bloomberg, dice que el seguimiento distribuido puede ayudar, ya que permite que un ingeniero vea todas las dependencias de un servicio. Los servicios descendentes también pueden ver qué servicios ascendentes dependen de ellos.

“Un buen ejemplo es nuestro servicio de cálculo de campo de valores para toda la empresa. Los cálculos sobre el universo de valores se pueden realizar en muchos lugares. Saber dónde enrutar las solicitudes para tales cálculos no es trivial, por lo que usamos una especie de proxy inteligente que se convierte en un enrutador de ‘caja negra’ para las solicitudes ”, dice.

“Los servicios proporcionan datos para las solicitudes sin necesidad de saber quién pregunta. Desafortunadamente, esto presenta un obstáculo cuando hay problemas de rendimiento. El seguimiento distribuido restaura la visibilidad de ‘a quién estoy llamando’ y ‘quién me está llamando’ que el monolito les daba implícitamente a los ingenieros ”.

Para garantizar que sus ingenieros pudieran centrarse en sus aplicaciones, Bloomberg ha construido plataformas escalables utilizando productos de código abierto como Kubernetes, Redis, Kafka y Cocinero. Esto, dice Wainwright, permite a los desarrolladores usar infraestructura llave en mano para el trabajo pesado y dejar caer el código de su aplicación.

Pruebas en el desarrollo de software moderno

En términos de reducción de errores, hay muchas cosas que se pueden extraer de cómo se prueba el código fuente abierto.

«Proyectos de código abierto exitosos, como el Colección de compiladores GNU (GCC) que crea grandes partes de una distribución de Linux, durante décadas ha requerido ejecutar un conjunto de pruebas antes de enviar un parche para su inclusión ”, dice Gerald Pfeifer, director de tecnología (CTO) de SUSE.

Dice proyectos de código abierto como LibreOffice utilice herramientas como Gerrit para realizar un seguimiento de los cambios e integre estrechamente aquellas con herramientas de automatización como Jenkins que realizan compilaciones y pruebas.

“Para que estas pruebas de integración sean efectivas a largo plazo, debemos tomarlas en serio y no omitirlas ni ignorar las regresiones introducidas”, dice Pfeifer.

Él cree que la automatización extensa es un factor clave de éxito, al igual que la aplicación de políticas, para garantizar la calidad del código. «Si su flujo de trabajo implica revisiones y aprobaciones de código, realizar pruebas automatizadas antes de que comience el proceso de revisión es un buen enfoque», dice.

Según Pfeifer, LibreOffice y GCC comparten un rasgo importante con otros proyectos exitosos que se centran en la calidad. “Siempre que se corrige un error, se agrega una nueva prueba a sus conjuntos de pruebas de regresión en constante crecimiento y evolución”, dice. “Eso asegura que la red que se lanza constantemente mejora en la captura y, por lo tanto, evita que no solo los viejos problemas vuelvan a aparecer, sino que también los nuevos se permeen. Lo mismo debería aplicarse a las nuevas funciones, aunque cuando los mismos desarrolladores aportan tanto código nuevo como cobertura de prueba para ellas, tiende a existir el riesgo de quedarse ciego «.

Al describir cómo se prueba su arquitectura de malla de servicios, Wainwright de Bloomberg dice: “En lugar de agrupar los cambios en un cronograma fijo, una mejor prueba nos permite realizar cambios más rápidamente. Los cambios son más pequeños, por lo que hay menos cosas que pueden salir mal y la mitigación es más simple «.

Si bien la calidad del código a menudo se mide en términos de tasas de defectos, presupuestos de errores y similares, Wainwright desmiente que el beneficio real de las pruebas más sencillas es psicológico. “Los equipos que confían en que sus herramientas los respaldan harán más progresos en menos tiempo”, dice. «Eso significa que entregamos más valor a nuestros clientes más rápido».

Sin embargo, como señala Chakrabarti de PagerDuty, uno de los mayores cambios de los últimos años es la intolerancia de los clientes hacia cualquier cosa que no sea la perfección en lo que respecta al rendimiento. “Muchos creen que los ingenieros tienen su propia ‘regla de los cien milisegundos’ con la que lidiar. ‘Vuelve más tarde’ ya no es una respuesta aceptable ”, dice.

Según Chakrabarti, la idea de diseñar aplicaciones a escala web se da prácticamente por sentada en estos días, particularmente a raíz del coronavirus, que ha visto a las empresas luchar para apoyar nuevas formas de trabajo. Los datos de PagerDuty muestran que el código nuevo y los volúmenes de tráfico más pesados ​​han provocado más incidentes, hasta 11 veces más en algunos sectores.

“Como industria, hemos mejorado en solucionar problemas sin afectar la experiencia del cliente, incluso a través de un enfoque automatizado para la gestión de operaciones digitales. Todavía son los primeros días para la corrección automática, pero estamos comenzando a ceder más control a la tecnología. Con el tiempo y los avances adicionales en el aprendizaje automático, deberíamos poder enseñar a algunos de nuestros sistemas a autocurarse en función de eventos pasados, incluso en circunstancias que solo ocurren una vez en una luna azul ”, dice Chakrabarti.

La influencia de la pandemia en el desarrollo de software

Más allá de los aspectos técnicos del desarrollo de código libre de errores, construido de una manera moderna, como las arquitecturas de TI autónomas y el enfoque de microservicios discutidos anteriormente, la pandemia de coronavirus ha hecho de las comunicaciones del equipo una prioridad máxima.

“En un mundo socialmente distanciado, los gerentes de producto son más importantes que nunca. Los desarrolladores sabrán lo que se debe hacer para crear una solución, si saben lo que se supone que deben resolver ”, dice Krug de Couchbase. “Sin embargo, resolver estos problemas significa meterse en la cabeza del cliente. Esperar que los desarrolladores se conviertan en psicólogos es un paso demasiado lejos. En su lugar, debe haber una comunicación clara entre los gerentes de producto y los desarrolladores sobre cuáles son los problemas de los clientes e idealmente cuál quieren que sea su estado final «.

Esto significa que la comunicación rápida con equipos distribuidos es esencial, agrega Krug. «Si no está en su lugar, una prioridad para todos los equipos de una empresa debería ser asegurarse de que lo esté».

Salir de la versión móvil