La famosa valla publicitaria de Twilio ‘Ask Your Developer’ (y el libro del mismo nombre del CEO Jeff Lawson) dice mucho sobre la nueva relación entre los desarrolladores y la empresa para la que trabajan. La nube y la economía de API permiten a las empresas aprovechar las nuevas innovaciones en lo que ahora está disponible ‘como servicio’. Pero desde cambiar su proveedor de pago hasta dictar sus plataformas de base de datos y nube, o incluso qué aplicaciones heredadas migra a la nube, las opciones tecnológicas de los desarrolladores pueden tener implicaciones a largo plazo para la organización.
Incluso cuando las organizaciones pensaron que estaban especificando rígidamente qué base de datos o marco de programación usar, las opciones de los desarrolladores se convirtieron en parte de la deuda técnica con la que esas empresas tendrían que lidiar durante años. Las decisiones separadas, individualmente sensatas, sobre qué tecnología usar para su base de datos de clientes, sitio web y sistema de comercio electrónico podrían dejarlo ejecutando un sitio importante orientado al cliente en una pila sin soporte.
El código PHP es ampliamente utilizado, pero también muy detestado (es el noveno lenguaje más temido en la encuesta de desarrolladores de Stack Overflow de 2021). Es menos fácil de mantener que algunas alternativas, pero es posible que todavía lo admita años más tarde, siguiendo la decisión de los desarrolladores de usarlo porque era fácil de aprender y de implementar.
En estos días, tales elecciones son aún más fáciles de tomar para los desarrolladores, y las consecuencias no deseadas pueden afectar su negocio de maneras que se extienden desde la aplicación específica que están creando. Ya sea que esté agregando servicios para vender junto con sus productos físicos, integrando funciones inteligentes en los dispositivos para hacerlos más sofisticados y más valiosos para los clientes, o simplemente trabajando en la transformación del negocio digital por la que está pasando cada organización para volverse más eficiente y productiva, ¿qué los desarrolladores construyen es una parte clave de lo que su negocio realmente hace.
La conveniencia gana
Los servicios en la nube, las API y las plataformas de código abierto de nivel empresarial significan que cualquier codificador puede usar la misma plataforma en la que Google ejecuta YouTube si se registra en PlanetScale o la tecnología de motor de búsqueda impulsada por IA detrás de Bing mediante el uso de Azure Cognitive Search. Pero también significan que los desarrolladores pueden tomar decisiones en función de la conveniencia, la familiaridad, la productividad personal o lo que parece interesante, y esa decisión establece efectivamente una estrategia tecnológica para la organización.
Los servicios en la nube se basan en la adopción viral por parte de empleados individuales que se generaliza tanto que las empresas comienzan a comprar puestos en lugar de procesar todas las declaraciones de gastos individuales. Ese podría ser el equipo de marketing que mueve los datos de los clientes a Salesforce, los desarrolladores que ponen máquinas virtuales de prueba en AWS, llaman a un servicio de mapeo en una aplicación o simplemente usan un IDE en la nube.
Las preocupaciones sobre la competencia de Amazon con sus propios clientes de AWS pueden ser algo exageradas, pero es posible que las empresas de industrias reguladas deban pensar en la ubicación de esos servicios en la nube. Y teniendo en cuenta las recientes interrupciones en la nube, cada organización debe comprender si depende de los servicios en la nube para tener la estrategia de replicación geográfica adecuada para la resiliencia.
Hay una API para casi todo, desde hacer llamadas telefónicas y enviar correos electrónicos o mensajes de Facebook, hasta el reconocimiento y la transcripción de imágenes, buscar las especificaciones de un automóvil a partir de un número VIN y pagar a los proveedores.
La mayoría de las organizaciones tienen acuerdos con procesadores de pago, operadores de telefonía móvil y otros proveedores de servicios, incluidos acuerdos de facturación y presupuesto central. Es poco probable que los desarrolladores que agreguen una API de pago de Stripe a una aplicación, soliciten tarjetas SIM de Twilio para dispositivos IoT, elijan una API de autenticación para iniciar sesión en aplicaciones o llamen a una API de firma electrónica para aprobaciones en flujos de trabajo de documentos, tengan los detalles de esos servicios corporativos.
Si las aplicaciones despegan, es posible que una parte sustancial del presupuesto operativo se desplace a través de estos nuevos canales. Estos nuevos servicios pueden ser más potentes y valiosos para la empresa que los arreglos anteriores, pero también está adquiriendo servicios externos cuya latencia y tiempo de actividad tal vez desee comenzar a monitorear. Y dependiendo de la ubicación de los datos en su organización, también puede depender de que su red interna sea completamente confiable y esté disponible (lo que puede no ser siempre cierto para las aplicaciones heredadas en plataformas más antiguas). Si su organización depende de una API que entrega información defectuosa, ¿quién es responsable de los problemas que eso cause?
Cada vez más, los equipos de desarrollo toman decisiones de compra sobre plataformas que alguna vez habrían estado centralizadas. Es bien sabido que MongoDB atrajo a los desarrolladores porque se empaquetaba por conveniencia: la capacidad de simplemente desempaquetar una descarga y comenzar a trabajar en 15 minutos era algo que una herramienta relacional como MySQL no podía ofrecer hace una década (y MySQL era más fácil para comenzar que Postgres porque estaba en un repositorio). Aunque los valores predeterminados han cambiado desde entonces, si un desarrollador de su organización eligió MongoDB hace varios años por la comodidad de los servicios en la nube en lugar de las características, podría terminar con una base de datos que estaba expuesta a Internet de forma predeterminada porque no tenía la características de seguridad correctas habilitadas.
VER: La computación en la nube es la clave del éxito empresarial. Pero desbloquear sus beneficios es un trabajo duro.
Del mismo modo, el uso de componentes de proyectos de código abierto puede acelerar el desarrollo, brindándole las mejores prácticas de codificación de una gran comunidad, por ejemplo, con herramientas como el escaneo de código de GitHub y las alertas de Dependabot para mejorar la calidad del código. Pero también podría generarle vulnerabilidades en paquetes como Log4j o algunos de los 1300 paquetes npm maliciosos que WhiteSource detectó solo en 2021. Los mantenedores de los paquetes más populares en npm ahora deben usar MFA, pero la mayoría de los paquetes npm incluyen dependencias en docenas de otros paquetes en los que también debe confiar.
Las decisiones arquitectónicas también tienen impactos más amplios. Los microservicios permiten a los desarrolladores separar el código en unidades funcionales que pueden actualizar o reemplazar de forma independiente, reutilizar en diferentes proyectos y orquestar en sistemas más grandes que brindan escalabilidad y disponibilidad. Pero esa orquestación significa que lo que estás creando es un sistema distribuido potencialmente complejo donde debe preocuparse por administrar el estado, tratar con la red y comprender los modelos de consistencia: todas las cosas de las que se ocupaban las transacciones en las bases de datos relacionales. Esta puede ser exactamente la dirección correcta para que su arquitectura tecnológica evolucione, pero debe ser una decisión estratégica en lugar de una elección hecha por desarrolladores individuales.
Administrar las opciones
Las implicaciones de las elecciones de los desarrolladores no son necesariamente malas. Lo que los desarrolladores experimentan y encuentran efectivo puede convertirse en la mejor práctica que lo ayuda a adoptar gradualmente nuevas tecnologías y técnicas.
Cuando los desarrolladores pueden ejecutar secuencias de comandos en una instancia de MongoDB que les permite ver lo que sucede directamente en la base de datos, ya no están a distancia de la producción. En lugar de llamar a un administrador de la base de datos cuando hay un problema, podrían trabajar en los problemas de la base de datos a medida que surjan sin esperar a que se involucren las operaciones. Ese es exactamente el tipo de ‘cambio a la izquierda’ que inicia a las organizaciones en el cambio a DevOps, donde los equipos operativos y de desarrollo se comunican y trabajan más estrechamente, utilizando el monitoreo y la automatización para acelerar la puesta en producción de nuevas características.
De manera similar, los desarrolladores pueden adoptar Docker porque hace que instalar nuevas herramientas y compartir código con colegas sea más conveniente y mucho menos frágil. Pero ese puede ser un paso natural hacia la creación de contenedores de aplicaciones que desea mover a la nube y refactorizar con nuevas funciones que aprovechan los servicios en la nube, las arquitecturas sin servidor y basadas en eventos y los patrones de microservicio.
Busque herramientas y prácticas que lo ayuden a administrar las opciones de los desarrolladores y establecer las políticas correctas para las opciones de código abierto y otras tecnologías. Las herramientas de Lista de materiales de software (SBOM) usan manifiestos como SPDX para ayudarlo a comprender su cadena de suministro de software. ClearlyDefined rastrea licencias, ubicaciones de origen y problemas de seguridad para proyectos de código abierto. Busque los cuadros de mando de Open Source Security Foundation (OpenSSF) que muestran si los componentes clave de código abierto cumplen con las mejores prácticas de seguridad (por ejemplo, si el proyecto requiere revisiones de código y fuzzing, firma versiones o tiene vulnerabilidades no corregidas).
Necesitas lograr un equilibrio aquí. No se trata de microgestionar a los desarrolladores; se trata de comprender las implicaciones de las opciones de desarrollo de la misma manera que pensaría sobre la elección de servicios y proveedores en los que confía en cualquier otra área de su negocio.
