APIS with Apigee revision de solicityes de APIS

esta guoa es patra r3gfisoa el camino ide paids a azure

1. ANÁLISIS DE APIS EN APIGEE PARA POSIBLE MIGRACIÓN A AZURE API MANAGEMENT

2. Contexto: La empresa se encuentra en un proceso de migración de su infraestructura de TI de AWS a la nube de Azure, buscando optimizar y modernizar sus operaciones. Como parte de esta estrategia de optimización, se ha identificado la necesidad de consolidar el uso de una única plataforma en la nube. Actualmente, se utiliza APIGEE para la gestión de APIs, pero esta solución no se alinea con la estrategia de consolidación en la nube principal. En este contexto, se plantea la migración de APIGEE a un servicio de gestión de APIs nativo de la nube principal seleccionada, como Azure API Management. El objetivo de esta migración es lograr una mayor integración, eficiencia y coherencia en la infraestructura de APIs, aprovechando las capacidades y beneficios de una plataforma unificada en la nube. Esto incluye la reducción de costos operativos, la mejora de la escalabilidad y la simplificación de la gestión. NOTA: RESUMEN

3. Objetivo: Analizar el número total de APIs existentes: Verificar la documentación y claridad de cada API (OPEN API). Determinar la complejidad técnica de las APIs. Identificar la presencia de lógica de programación en las APIs (JavaScript)

4. Número de APIS Se evaluaron 119 apis

5. Documentación OPEN API En la revisión de un total de 119 APIs Proxy y su documentación, se observó que el 71.4% (85 APIs) cuenta con documentación en formato OPEN API. Por lo que, el 28.6% (34 APIs) carece de la documentación.

6. Documentación OPEN API De las APIs que cuentan con documentación, se destaca que 27 poseen una documentación incompleta. Dicha documentación podría contener un número de endpoints que no coincide con el número real de endpoints existentes en la API (ya sea inferior o superior)

7. Complejidad técnica de las APIs Las APIs se clasifican según la cantidad de políticas que utilizan, aplicando el método de cuartiles para segmentar los datos según su distribución real. El primer cuartil (3) y el tercer cuartil (14.5) definieron los rangos: ‘baja’ (≤ 3 politicas, ‘media’ (4 a 14) y ‘alta’ (>14).

8. Presencia de lógica de programación en las APIs. Hemos identificado que una parte de nuestras APIs incorpora lógica programada desarrollada en JavaScript. Tras un recuento, se determinó que actualmente 25 APIs utilizan este tipo de implementación.

9. Complejidad técnica de las APIs / Presencia de lógica APIs que contienen lógica NOTA: EJEMPLOS Calificación con forme a Políticas Count media con lógica 11 media 47 alta 16 alta con lógica 14 baja 31

10. Ambientes en los que se encuentran habilitadas Durante el análisis, se ha hecho evidente que no todas las APIs se encuentran desplegadas en la totalidad de los entornos disponibles. Específicamente, se ha identificado que 38 APIs residen únicamente en los entornos de Desarrollo (DEV) y Producción (PRO), mientras que las 81 APIs restantes están presentes en los entornos de Desarrollo (DEV), Control de Calidad (QA) y Producción (PRO).

11. ¿Misma revisión en todos los ambientes disponibles? En la plataforma Apigee, contamos con diversos entornos de despliegue para las APIs. Si bien el número de revisión de una API debería, por norma general, ser consistente en todos los ambientes, hemos observado que esta coincidencia no siempre se mantiene en nuestro caso. MR = Misma Revisión NMR = No Misma Revisión

12. ¿Misma revisión en todos los ambientes disponibles? 1.- quien es el dueño (gerencia) 2.- quien es el líder que va a llevar ese control, revisión, complemento del open api 3.- en que momento estará haciendo pruebas de esa migración 4.- en que momento hará la integración al satelital que se llama en apigee y ahora hacia apim 5.- momento de liberación nota importante: Septiembre 4% y Diciembre 4%