AWS crece. Su control debe crecer con él.

Un piloto surge a menudo bajo presión de tiempo y con un número reducido de usuarios. Sin embargo, en cuanto se incorporan más equipos, los acuerdos informales ya no son suficientes. Hay que asignar los recursos, revisar los permisos administrativos y clasificar los servicios comunes. Por eso, el inventario analiza las cuentas existentes junto con los proyectos y las personas que hay detrás de ellas. Así se hace visible qué estructuras se eligieron de forma deliberada, cuáles eran solo provisionales y qué cambios son realmente necesarios antes de una ampliación mayor.

La visión objetivo describe cómo se incorporan los nuevos equipos y qué reglas deben aplicarse a las cuentas existentes. Se tienen en cuenta las responsabilidades, los centros de coste y la separación entre los distintos entornos. La implantación se realiza en pasos acordados, para que las aplicaciones en curso y las dependencias existentes queden incluidas. Un primer caso de uso concreto sirve para probar los nuevos procedimientos. A continuación, su equipo puede evaluar si el aprovisionamiento, las aprobaciones y la documentación también funcionan de forma comprensible fuera del equipo piloto original.

El entorno objetivo de una aplicación suele estar formado por varios componentes con requisitos distintos. La capacidad de cómputo, el almacenamiento de datos, las interfaces y los accesos administrativos deben analizarse conjuntamente. Buscamos juntos una configuración adecuada y tenemos en cuenta el esfuerzo operativo futuro. En este proceso, las competencias disponibles siguen siendo relevantes: una solución debe poder ser entendida, monitorizada y modificada por los equipos previstos. Por eso, el alcance de una modernización se separa deliberadamente de las tareas que son necesarias, en primer lugar, para una transición segura.

Para la implementación se documentan las dependencias y las verificaciones. Los equipos de aplicaciones confirman la función de negocio, mientras que las pruebas técnicas cubren los accesos, las conexiones y la configuración operativa acordada. Si se siguen necesitando sistemas locales, sus vías de comunicación forman parte de la aceptación. El traspaso describe además cómo se incorporan los cambios después del proyecto y qué documentación está disponible para ello. De este modo, se puede incorporar una carga de trabajo adicional al entorno de AWS sin que la responsabilidad quede sin definir al final del traslado.

Una factura creciente puede tener causas muy diversas: aplicaciones nuevas, un uso distinto, recursos sobredimensionados o entornos que funcionan más tiempo del necesario. Un simple resumen de costes todavía no muestra qué cambio técnico sería razonable. Por eso, los gastos se relacionan con el uso y la responsabilidad. En conversación con los equipos de aplicaciones se aclara qué reservas están previstas de forma deliberada y dónde se detecta realmente un consumo evitable. Así, las medidas surgen del contexto de la aplicación.

Antes de un cambio se acuerdan las posibles consecuencias y la verificación necesaria. Tras la implementación, analizamos el uso observado y su efecto en la operación. No toda reducción técnicamente posible es adecuada para cada carga de trabajo. Por eso, la documentación registra las hipótesis y las decisiones, de modo que otras optimizaciones puedan basarse en ellas. Para el soporte continuo se definen además las vías de notificación, el mantenimiento y las responsabilidades; así, las decisiones de coste permanecen vinculadas a la responsabilidad real sobre los sistemas.