Cualquier lenguaje, cualquier nube: por qué seguimos siendo agnósticos

Una de las primeras preguntas que escuchamos es qué tecnología usamos. Es una pregunta justa, y nuestra respuesta puede sonar evasiva al principio: usamos la que encaja. Trabajamos con los lenguajes y los frameworks en los que una organización ya se apoya, desplegamos en la nube que eligió o en un alojamiento que gestionamos nosotros mismos, y seguimos operando lo que construimos.

No es un eslogan. Es una posición de diseño, y tiene consecuencias en cómo se da forma a las aplicaciones, cómo se gobiernan y cómo se mantienen. Este artículo explica el razonamiento.

Agnóstico no significa indiferente

Ser agnósticos no significa no tener opiniones. Nuestros arquitectos tienen ideas firmes sobre lo que hace que un sistema sea mantenible, seguro y agradable de cambiar. Lo que evitamos es partir de una tecnología favorita y adaptar la organización a ella.

Cada decisión tecnológica cambia un conjunto de restricciones por otro. El equilibrio correcto depende de la organización, no del proveedor. Una opción excelente para un cliente puede ser un lastre para el siguiente, porque las personas, los sistemas y las obligaciones alrededor de la aplicación son distintos.

Las restricciones que deciden

Cuando damos forma a una aplicación, la tecnología se desprende de un puñado de preguntas propias de la organización.

• ¿Quién va a convivir con ella? Si un equipo interno va a mantener partes del sistema, los lenguajes que conoce importan más que los que preferimos nosotros.
• ¿Con qué tiene que comunicarse? Una aplicación rara vez está sola. El ERP, el CRM, el proveedor de identidad y las herramientas de informes que ya existen determinan qué se integra de forma limpia.
• ¿Dónde pueden residir los datos? Las leyes de privacidad, los contratos y las políticas internas pueden decidir qué regiones y qué proveedores son aceptables antes de que cualquier preferencia técnica entre en la conversación.
• ¿Cómo se va a operar? La supervisión, las copias de seguridad, las actualizaciones y la respuesta a incidentes tienen que encajar con las personas y los procesos que se harán cargo de ellas, de día y de noche.
• ¿Cómo saldrías? Todo sistema debería tener una salida creíble: hacia otro proveedor, hacia otro equipo o de vuelta a la propia organización.

Estas preguntas se hacen pronto, y las respuestas se registran con el resto del diseño. No se dejan para el final de un proyecto, cuando cambiarlas sale caro.

Dónde se ejecuta es una decisión de diseño

El alojamiento suele tratarse como un detalle operativo que se resuelve después de construir la aplicación. Nosotros lo tratamos como parte del diseño. Una aplicación puede ejecutarse en la nube de la organización, en su propio centro de datos o en infraestructura que gestiona Croo. Cada opción implica responsabilidades distintas en seguridad, disponibilidad y costos, y la decisión le corresponde a la organización.

Para que esa decisión sea real, el entorno de destino se describe en la configuración en lugar de quedar entretejido en el código. Un registro simplificado, a modo de ilustración, se ve así:

# Dónde se ejecuta el portal de compras queda registrado con su diseño.
application: purchasing-portal
packaging: container
environments:
  - name: acceptance
    hosting: client-cloud
    data-residency: canada
  - name: production
    hosting: client-cloud
    data-residency: canada
fallback:
  hosting: croo-managed
  reason: sigue disponible si el equipo de plataforma cambia de rumbo

El valor no está en el formato del archivo. Está en la disciplina: la aplicación no da por sentado dónde vive, así que moverla es un proyecto deliberado y no una reescritura.

Mantener abierta la puerta de salida

La dependencia de un proveedor rara vez viene de una sola decisión. Se acumula a través de pequeñas comodidades: un servicio propietario aquí, un script sin documentar allá. Ser agnósticos significa resistir esa acumulación en nombre del cliente.

En la práctica, eso significa algunos hábitos.

• Empaquetado portable. Las aplicaciones se empaquetan para que funcionen igual en cualquier entorno que admita contenedores estándar, de modo que la organización no quede atada al entorno de ejecución de un solo proveedor.
• Infraestructura descrita como código. Los entornos se crean a partir de definiciones revisadas, no se configuran a mano, para poder recrearlos en otro lugar.
• Datos abiertos. La organización puede exportar sus datos en formatos documentados, en cualquier momento, sin nuestra ayuda.
• Documentación que viaja. Las decisiones, la arquitectura y los procedimientos de operación viven en el registro compartido, para que otro equipo pueda hacerse cargo.

Nada de esto impide usar el mejor servicio que ofrece un proveedor. Significa saber, y dejar por escrito, lo que costaría esa elección si las circunstancias cambian.

Lo que ser agnósticos nos exige

Trabajar con muchos lenguajes y nubes es más difícil que especializarse en uno. Exige amplitud en el equipo y disciplina en la forma de conservar el conocimiento.

Dos cosas lo hacen sostenible. La primera es la memoria compartida de la Factory: los patrones, las decisiones y las lecciones de una tecnología quedan registrados de manera que el siguiente trabajo pueda aprovecharlos. La segunda es la producción asistida por IA, que reduce el esfuerzo de trabajar con un framework menos conocido o de leer un código que no se conoce. El criterio sobre arquitectura, seguridad y concesiones sigue en manos de personas sénior que responden por él.

Gobernanza desde el diseño

Elegir dónde se ejecuta una aplicación también es una decisión de gobernanza. La residencia de los datos, el control de acceso, el cifrado, las copias de seguridad y el tratamiento de la información personal se definen en la misma conversación que la tecnología, y se registran con ella.

Por eso situamos este tema bajo la gobernanza desde el diseño. Una organización debería poder decir, en cualquier momento, dónde se ejecutan sus aplicaciones, quién puede acceder a ellas, por qué se tomaron esas decisiones y cómo podría cambiarlas. Ser agnósticos es nuestra forma de mantener esas respuestas en manos de la organización.

En resumen

No vendemos un conjunto de tecnologías. Construimos aplicaciones empresariales en los lenguajes y en las nubes que le sirven a la organización, o las operamos nosotros cuando esa es la mejor respuesta. Las restricciones deciden, las decisiones quedan registradas y la puerta de salida sigue abierta.