Evaluación y preparación de microservicios

  • Artículo

Una arquitectura de microservicios puede proporcionar muchas ventajas para las aplicaciones, como agilidad, escalabilidad y alta disponibilidad. Junto con estas ventajas, esta arquitectura presenta desafíos. Al compilar aplicaciones basadas en microservicios o transformar aplicaciones existentes en una arquitectura de microservicios, debe analizar y evaluar la situación actual para identificar áreas que necesitan mejoras.

Esta guía le ayudará a reconocer algunas consideraciones que debe tener en cuenta al pasar a una arquitectura de microservicios. Puede usar esta guía para evaluar la madurez de la aplicación, la infraestructura, DevOps, el modelo de desarrollo, etc.

Reconocer las prioridades empresariales

Para empezar a evaluar una arquitectura de microservicios, primero debe reconocer las prioridades básicas de su negocio. Las prioridades principales pueden estar relacionadas con la agilidad, la adopción de cambios o el desarrollo rápido, por ejemplo. Debe analizar si la arquitectura es adecuada para sus prioridades principales. Tenga en cuenta que las prioridades empresariales pueden cambiar con el tiempo. Por ejemplo, la innovación es una prioridad principal para las startups, pero después de unos años, las prioridades principales podrían ser la confiabilidad y la eficacia.

Estas son algunas prioridades que se deben tener en cuenta:

  • Innovación
  • Confiabilidad
  • Eficacia

Documente los SLA (contrato de nivel de servicio) que están alineados con varios elementos de la aplicación para garantizar un compromiso organizativo que pueda servir como guía para su valoración.

Registrar decisiones de arquitectura

Una arquitectura de microservicios ayuda a los equipos a ser autónomos. Los equipos pueden tomar sus propias decisiones sobre tecnologías, metodologías y componentes de infraestructura, por ejemplo. Sin embargo, estas opciones deben respetar los principios acordados formalmente conocidos como gobernanza compartida, que expresan el acuerdo entre los equipos sobre cómo abordar la estrategia más amplia para los microservicios.

Tenga en cuenta estos factores:

  • ¿Se ha puesto en marcha la gobernanza compartida?
  • ¿Realiza un seguimiento de las decisiones y sus acuerdos en un diario de arquitectura?
  • ¿Puede el equipo acceder fácilmente al diario de arquitectura?
  • ¿Tiene un proceso para evaluar herramientas, tecnologías y marcos?

Evaluar la composición del equipo

Debe tener la estructura de equipo adecuada para evitar la comunicación innecesaria entre los equipos. Una arquitectura de microservicios fomenta la formación de equipos pequeños, centrados y transversales, y requiere un cambio de mentalidad, que debe ir precedido de la reestructuración del equipo.

Tenga en cuenta estos factores:

  • ¿Los equipos se dividen en función de los subdominios, siguiendo los principios del diseño guiado por el dominio (DDD)?
  • ¿Los equipos son transversales, con capacidad suficiente para compilar y operar microservicios relacionados de forma independiente?
  • ¿Cuánto tiempo se dedica a actividades y tareas ad hoc que no están relacionadas con los proyectos?
  • ¿Cuánto tiempo se dedica a la colaboración entre equipos?
  • ¿Tiene un proceso para identificar y minimizar la deuda técnica?
  • ¿Cómo se comunican las lecciones aprendidas y la experiencia entre los equipos?

Usar la metodología Twelve-Factor

El objetivo fundamental de elegir una arquitectura de microservicios es ofrecer valor más rápido y ser adaptable a los cambios mediante procedimientos ágiles. La metodología de la aplicación Twelve-Factor proporciona directrices para crear aplicaciones escalables y fáciles de mantener. Estas directrices promueven atributos como la inmutabilidad, la fugacidad, la configuración declarativa y la automatización. Al incorporar estas directrices y evitar problemas comunes, puede crear microservicios autocontenidos de acoplamiento flexible.

Reconocer el enfoque de descomposición

Transformar una aplicación monolítica en una arquitectura de microservicios lleva tiempo. Comience con los servicios perimetrales. Los servicios perimetrales tienen menos dependencias en otros servicios y se pueden descomponer fácilmente desde el sistema como servicios independientes. Se recomiendan encarecidamente patrones como Strangler Fig y Anti-corruption Layer para mantener la aplicación monolítica en estado de funcionamiento hasta que todos los servicios se descompongan en microservicios independientes. Durante la segregación, los principios de DDD pueden ayudar a los equipos a elegir componentes o servicios de la aplicación monolítica basada en subdominios.

Por ejemplo, en un sistema de comercio electrónico, puede tener estos módulos: carro, administración de productos, administración de pedidos, precios, generación de facturas y notificación. Decide iniciar la transformación de la aplicación por el módulo de notificación porque no tiene dependencias en otros módulos. Sin embargo, otros módulos pueden depender de este módulo para enviar notificaciones. El módulo de notificación se puede descomponer fácilmente en un microservicio independiente, pero deberá realizar algunos cambios en la aplicación monolítica para llamar al nuevo servicio de notificación. A continuación, decide transformar el módulo de generación de facturas. Se llama a este módulo después de generar un pedido. Puede usar patrones como Strangler y Anti-corruption para admitir esta transformación.

La sincronización de datos, las escrituras múltiples en las interfaces monolítica y de microservicio, la propiedad de los datos, la descomposición del esquema, las combinaciones, el volumen de datos y la integridad de los datos podrían dificultar la migración y el desglose de los datos. Hay varias técnicas que puede usar, como mantener una base de datos compartida entre microservicios, desacoplar bases de datos de un grupo de servicios en función de la capacidad empresarial o el dominio, y aislar las bases de datos de los servicios. La solución recomendada es descomponer cada base de datos con cada servicio. En muchas circunstancias, esto no es práctico. En esos casos, puede usar patrones como Database View y Database Wrapping Service.

Evaluar la preparación de DevOps

Al pasar a una arquitectura de microservicios, es importante evaluar la competencia de DevOps. Una arquitectura de microservicios está pensada para facilitar el desarrollo ágil en las aplicaciones para aumentar la agilidad de la organización. DevOps es uno de los procedimientos clave que debería implementar para lograr esta competencia.

Al evaluar la capacidad DevOps de una arquitectura de microservicios, tenga en cuenta estos puntos:

  • ¿Los miembros de su organización conocen los procedimientos y principios fundamentales de DevOps?
  • ¿Los equipos reconocen las herramientas de control de código fuente y su integración con flujos de CI/CD (integración continua y entrega continua)?
  • ¿Implementa correctamente las prácticas DevOps?
    • ¿Sigue las prácticas Agile?
    • ¿Se implementa la integración continua?
    • ¿Se implementa la entrega continua?
    • ¿Se implementa el despliegue continuo?
    • ¿Se implementa la supervisión continua?
    • ¿La infraestructura como código (IaC) está en marcha?
  • ¿Usa las herramientas adecuadas para admitir CI/CD?
  • ¿Cómo se administra la configuración de entornos de prueba y de producción para la aplicación?
  • ¿La cadena de herramientas tiene soporte técnico de la comunidad y un modelo de soporte técnico y proporciona los canales y la documentación adecuados?

Identificar las áreas de negocio que cambian con frecuencia

Una arquitectura de microservicios es flexible y adaptable. Durante la evaluación, impulse una discusión en la organización para determinar las áreas que sus compañeros creen que cambiarán con frecuencia. La creación de microservicios permite a los equipos responder rápidamente a los cambios que los clientes solicitan y minimizar los esfuerzos de las pruebas de regresión. En una aplicación monolítica, un cambio en un módulo requiere numerosos niveles de pruebas de regresión y reduce la agilidad a la hora de publicar nuevas versiones.

Tenga en cuenta estos factores:

  • ¿El servicio se puede implementar de forma independiente?
  • ¿El servicio sigue los principios de DDD?
  • ¿El servicio sigue los principios SOLID?
  • ¿La base de datos es privada para el servicio?
  • ¿Ha creado el servicio mediante el patrón de chasis de microservicios compatible?

Evaluar la preparación de la infraestructura

Cuando se cambia a una arquitectura de microservicios, la preparación de la infraestructura es un punto crítico a tener en cuenta. El rendimiento, la disponibilidad y la escalabilidad de la aplicación se verán afectados si la infraestructura no está configurada correctamente o si no se usan los servicios o componentes adecuados. A veces se crea una aplicación con todas las metodologías y procedimientos sugeridos, pero la infraestructura no es adecuada. Esto da como resultado un rendimiento y mantenimiento deficientes.

Tenga en cuenta estos factores al evaluar la preparación de la infraestructura:

  • ¿La infraestructura garantiza la escalabilidad de los servicios implementados?
  • ¿Admite la infraestructura el aprovisionamiento a través de scripts que se pueden automatizar a través de CI/CD?
  • ¿Ofrece la infraestructura de implementación un SLA para la disponibilidad?
  • ¿Tiene un plan de recuperación ante desastres (DR) y programaciones rutinarias de exploración en profundidad?
  • ¿Se replican los datos en diferentes regiones para la recuperación ante desastres?
  • ¿Tiene un plan de copia de seguridad de datos?
  • ¿Están documentadas las opciones de implementación?
  • ¿Se supervisa la infraestructura de implementación?
  • ¿La infraestructura de implementación admite la recuperación automática de los servicios?

Evaluación de ciclos de versión

Los microservicios son adaptables para cambiar y aprovechar el desarrollo ágil para acortar los ciclos de lanzamiento de versión y aportar más valor a los clientes. Tenga en cuenta estos factores al evaluar los ciclos de versión:

  • ¿Con qué frecuencia se compilan y lanzan aplicaciones?
  • ¿Con qué frecuencia se producirá un error en las versiones después del despliegue?
  • ¿Cuánto tiempo se necesita para recuperar o corregir problemas después de una interrupción?
  • ¿Usa el control de versiones semántico para las aplicaciones?
  • ¿Mantiene entornos diferentes y propaga la misma versión en una secuencia (por ejemplo, primero a pruebas y luego a producción)?
  • ¿Usa el control de versiones para las API?
  • ¿Sigue las directrices de control de versiones adecuadas para las API?
  • ¿Cuándo cambia una versión de API?
  • ¿Cuál es su enfoque para manejar el control de versiones de API?
    • Control de versiones de ruta de acceso URI
    • Control de versiones de parámetros de consulta
    • Control de versiones de tipo de contenido
    • Control de versiones de encabezado personalizado
  • ¿Tiene en marcha una práctica para el control de versiones de eventos?

Evaluar la comunicación entre servicios

Los microservicios son servicios independientes que se comunican entre sí a través de los límites del proceso para abordar escenarios empresariales. Para obtener una comunicación de confianza debe seleccionar un protocolo de comunicación adecuado.

Considere estos factores:

  • ¿Está siguiendo un enfoque de primera API, en el que las API se tratan como ciudadanos de primera clase?
  • ¿Tiene operaciones de cadena larga, donde varios servicios se comunican en secuencia a través de un protocolo de comunicación sincrónica?
  • ¿Ha considerado la comunicación asincrónica en cualquier parte del sistema?
  • ¿Ha evaluado la tecnología del agente de mensajes y sus funcionalidades?
  • ¿Reconoce el rendimiento de los mensajes que los servicios reciben y procesan?
  • ¿Usa una comunicación directa de cliente a servicio?
  • ¿Necesita insistir en los mensajes en el nivel de agente de mensajes?
  • ¿Usa el patrón Materialized View para abordar el comportamiento hablador de los microservicios?
  • ¿Ha implementado Retry, Circuit Breaker, Exponential Backoff y Jitter para una comunicación de confianza? Una manera común de manejar esto es usar el patrón Ambassador.
  • ¿Ha definido eventos de dominio para facilitar la comunicación entre microservicios?

Evaluar cómo se exponen los servicios a los clientes

Una puerta de enlace de API es uno de los componentes principales de una arquitectura de microservicios. Exponer directamente los servicios a los clientes crea problemas en términos de manejabilidad, control y comunicación de confianza. Una puerta de enlace de API actúa como servidor proxy, interceptando el tráfico y enrutando a servicios back-end. Si necesita filtrar el tráfico por dirección IP, autorización, respuestas simuladas, entre otros, puede hacerlo en el nivel de puerta de enlace de API sin realizar ningún cambio en los servicios.

Considere estos factores:

  • ¿Los clientes consumen directamente los servicios?
  • ¿Hay una puerta de enlace de API que actúe como fachada para todos los servicios?
  • ¿Puede la puerta de enlace de API configurar directivas como límites de cuota, simulación de respuestas y filtrado de direcciones IP?
  • ¿Usa varias puertas de enlace de API para satisfacer las necesidades de varios tipos de clientes, como aplicaciones móviles, aplicaciones web y partners?
  • ¿La puerta de enlace de API proporciona un portal donde los clientes pueden descubrir y suscribirse a servicios, como un portal para desarrolladores en Azure API Management?
  • ¿La solución proporciona funcionalidades de equilibrio de carga o Web Application Firewall (WAF) L7 junto con la puerta de enlace de API?

Evaluar el manejo de transacciones

Las transacciones distribuidas facilitan la ejecución de varias operaciones como una sola unidad de trabajo. En una arquitectura de microservicios, el sistema se descompone en numerosos servicios. Varios microservicios abordan un único caso de uso empresarial como parte de una única transacción distribuida. En una transacción distribuida, un comando es una operación que se inicia cuando se produce un evento. El evento desencadena una operación en el sistema. Si la operación se realiza correctamente, podría desencadenar otro comando, que puede desencadenar otro evento, y así sucesivamente hasta que todas las transacciones se completen o reviertan, dependiendo de si la transacción se realiza correctamente.

Tome en cuenta las siguientes consideraciones:

  • ¿Cuántas transacciones distribuidas hay en el sistema?
  • ¿Cuál es su enfoque para manejar las transacciones distribuidas? Valore el uso del patrón Saga con orquestación o coreografía.
  • ¿Cuántas transacciones abarcan varios servicios?
  • ¿Sigue un modelo de transacción ACID o BASE para lograr la integridad y la coherencia de los datos?
  • ¿Usa operaciones de encadenamiento largo para transacciones que abarcan varios servicios?

Evaluar el modelo de desarrollo de servicios

Una de las mayores ventajas de las arquitecturas de microservicios es la diversidad tecnológica. Los sistemas basados en microservicios permiten a los equipos desarrollar servicios mediante las tecnologías que elijan. En el desarrollo de aplicaciones tradicional, puede reutilizar el código existente al compilar nuevos componentes o crear un marco de desarrollo interno para reducir el esfuerzo de desarrollo. El uso de varias tecnologías puede impedir la reutilización del código.

Tenga en cuenta estos factores:

  • ¿Usa una plantilla de servicio para iniciar el nuevo desarrollo de un servicio?
  • ¿Sigue la metodología Twelve-Factor App y usa una base de código única para microservicios, aislando las dependencias y externalizando la configuración?
  • ¿Mantiene una configuración confidencial en los almacenes de claves?
  • ¿Contenedoriza los servicios?
  • ¿Conoce los requisitos de coherencia de los datos?

Evaluar el enfoque de implementación

El enfoque de implementación es el método para publicar versiones de la aplicación en varios entornos de implementación. Los sistemas basados en microservicios proporcionan la agilidad para lanzar versiones más rápido que con las aplicaciones tradicionales.

Al evaluar el plan de implementación, tenga en cuenta estos factores:

  • ¿Tiene una estrategia para implementar los servicios?
  • ¿Usa herramientas y tecnologías modernas para implementar los servicios?
  • ¿Qué tipo de colaboración es necesaria entre los equipos al implementar servicios?
  • ¿Aprovisiona la infraestructura mediante infraestructura como código (IaC)?
  • ¿Usa funcionalidades DevOps para automatizar las implementaciones?
  • ¿Propaga las mismas compilaciones a varios entornos, como sugiere la metodología Twelve-Factor App?

Evaluación de la plataforma de hospedaje

La escalabilidad es una de las principales ventajas de las arquitecturas de microservicios. Esto se debe a que los microservicios se asignan a dominios empresariales, por lo que cada servicio se puede escalar de forma independiente. Una aplicación monolítica se implementa como una sola unidad en una plataforma de hospedaje y debe escalarse holísticamente. Esto da como resultado tiempo de inactividad, riesgo de implementación y mantenimiento. La aplicación monolítica podría estar bien diseñada, con componentes que direcciona dominios empresariales individuales. Sin embargo, debido a la falta de límites del proceso, la posibilidad de infringir los principios de responsabilidad única es más difícil. Esto finalmente da como resultado código espagueti. Dado que la aplicación se compone e implementa como un único proceso de hospedaje, la escalabilidad es difícil.

Los microservicios permiten a los equipos elegir la plataforma de hospedaje adecuada para satisfacer sus necesidades de escalabilidad. Hay varias plataformas de hospedaje disponibles para abordar estos desafíos, proporcionando funcionalidades como el escalado automático, el aprovisionamiento elástico, una mayor disponibilidad, una implementación más rápida y una supervisión sencilla.

Tenga en cuenta estos factores:

  • ¿Qué plataforma de hospedaje se usa para implementar los servicios (máquinas virtuales, contenedores, sin servidor)?
  • ¿Es escalable la plataforma de hospedaje? ¿Admite el escalado automático?
  • ¿Cuánto tiempo se necesita para escalar la plataforma de hospedaje?
  • ¿Reconoce los SLA que proporcionan las distintas plataformas de hospedaje?
  • ¿La plataforma de hospedaje admite la recuperación ante desastres?

Evaluar la supervisión de servicios

La supervisión es un elemento importante de una aplicación basada en microservicios. Dado que la aplicación se divide en una serie de servicios que se ejecutan de forma independiente, la solución de problemas por errores puede ser desalentador. Si usa la semántica adecuada para supervisar los servicios, los equipos pueden supervisar, investigar y responder fácilmente a los errores.

Tenga en cuenta estos factores:

  • ¿Supervisa los servicios implementados?
  • ¿Tiene un mecanismo de registro? ¿Qué herramientas usa?
  • ¿Tiene una infraestructura de seguimiento distribuido en marcha?
  • ¿Registra excepciones?
  • ¿Mantiene códigos de error de negocio para la identificación rápida de problemas?
  • ¿Usa sondeos de estado para los servicios?
  • ¿Usa el registro semántico? ¿Ha implementado métricas clave, umbrales e indicadores?
  • ¿Enmascara datos confidenciales durante el registro?

Evaluar la asignación de tokens de correlación

En una arquitectura de microservicios, una aplicación se compone de varios microservicios que se hospedan de forma independiente e interactúan entre sí para atender varios casos de uso empresariales. Cuando una aplicación interactúa con los servicios back-end para realizar una operación, puede asignar un número único, conocido como token de correlación, a la solicitud. Recomendamos que considere el uso de tokens de correlación, ya que pueden ayudarle a solucionar errores. Le ayudan a determinar la causa principal de un problema, evaluar el impacto y determinar un enfoque para corregir el problema.

Puede usar tokens de correlación para recuperar el registro de solicitudes identificando qué servicios contienen el token de correlación y cuáles no. Los servicios que no tienen el token de correlación para esa solicitud dan errores. Si se produce un error, puede volver a intentar la transacción más adelante. Para aplicar la idempotencia, solo los servicios que no tengan el token de correlación atenderán la solicitud.

Por ejemplo, si tiene una larga cadena de operaciones que implica muchos servicios, pasar un token de correlación a los servicios puede ayudarle a investigar las incidencias fácilmente si se produce un error en cualquiera de los servicios durante una transacción. Cada servicio normalmente tiene su propia base de datos. El token de correlación se mantiene en el registro de base de datos. En el caso de una repetición de transacciones, los servicios que tienen ese token de correlación determinado en sus bases de datos ignoran la solicitud. Solo los servicios que no tienen el token atienden la solicitud.

Tenga en cuenta estos factores:

  • ¿En qué fase asigna el token de correlación?
  • ¿Qué componente asigna el token de correlación?
  • ¿Guarda tokens de correlación en la base de datos del servicio?
  • ¿Cuál es el formato de los tokens de correlación?
  • ¿Registra tokens de correlación y otra información de solicitud?

Valorar la necesidad de un marco de chasis de microservicios

Un marco de chasis de microservicios es un marco base que proporciona funcionalidades para cuestiones transversales como el registro, el manejo de excepciones, el seguimiento distribuido, la seguridad y la comunicación. Cuando usa un marco de chasis se centra más en implementar el límite del servicio que en interactuar con la funcionalidad de la infraestructura.

Por ejemplo, digamos que está creando un servicio de administración de carros. Quiere validar el token entrante, escribir registros en la base de datos de registro y comunicarse con otro servicio invocando ese punto de conexión de servicio. Si usa un marco de chasis de microservicios puede reducir los esfuerzos de desarrollo. Dapr es un sistema que proporciona varios bloques de creación para implementar cuestiones transversales.

Tenga en cuenta estos factores:

  • ¿Usa un marco de microservicios de chasis?
  • ¿Usa Dapr para interactuar con cuestiones transversales?
  • ¿El lenguaje del marco de trabajo del chasis es independiente?
  • ¿Su marco de trabajo de chasis es genérico, por lo que admite todo tipo de aplicaciones? Un marco de chasis no debería contener lógica específica de la aplicación.
  • ¿El marco del chasis proporciona un mecanismo para usar los componentes o servicios seleccionados según sea necesario?

Evaluar el enfoque de las pruebas de aplicaciones

Tradicionalmente, las pruebas se realizan una vez completado el desarrollo y la aplicación está lista para su implementación en entornos de producción y pruebas de aceptación de usuarios (UAT). Actualmente hay un cambio en este enfoque, que mueve las pruebas a un momento anterior (a la izquierda) en el ciclo de vida del desarrollo de aplicaciones. Las pruebas con desplazamiento a la izquierda aumentan la calidad de las aplicaciones, porque las pruebas se realizan durante cada fase del ciclo de vida del desarrollo de la aplicación, incluidas las fases de diseño, desarrollo y desarrollo posterior.

Por ejemplo, cuando se compila una aplicación, se empieza por diseñar una arquitectura. Cuando se usa el enfoque de desplazamiento a la izquierda, se prueba el diseño en busca de vulnerabilidades mediante herramientas como Microsoft Threat Modeling. Al iniciar el desarrollo se puede examinar el código fuente ejecutando herramientas como las pruebas estáticas de seguridad de las aplicaciones (SAST) y usando otros analizadores para descubrir problemas. Después de implementar la aplicación puede usar herramientas como pruebas dinámicas de seguridad de las aplicaciones (DAST) para probarla mientras está hospedada. Las pruebas funcionales, las pruebas de caos, las pruebas de penetración y otros tipos de pruebas se realizarán más adelante.

Tenga en cuenta estos factores:

  • ¿Escribe planes de prueba que cubren todo el ciclo de vida de desarrollo?
  • ¿Incluye evaluadores en las reuniones de requisitos y en todo el ciclo de vida de desarrollo de una aplicación?
  • ¿Usa el diseño controlado por pruebas o el diseño basado en el comportamiento?
  • ¿Prueba casos de usuario? ¿Incluye criterios de aceptación en los casos de usuario?
  • ¿Se prueba el diseño mediante herramientas como Microsoft Threat Modeling?
  • ¿Escribe pruebas unitarias?
  • ¿Usa analizadores de código estáticos u otras herramientas para medir la calidad del código?
  • ¿Usa herramientas automatizadas para probar aplicaciones?
  • ¿Implementa procedimientos de DevOps seguros?
  • ¿Realiza pruebas de integración, pruebas de aplicaciones de un extremo a otro, pruebas de carga y rendimiento, pruebas de penetración y pruebas de caos?

Evaluar la seguridad de los microservicios

La protección del servicio, el acceso seguro y la comunicación segura son algunas de las consideraciones más importantes para una arquitectura de microservicios. Por ejemplo, un sistema basado en microservicios que abarque varios servicios y use la validación de tokens para cada servicio no es una solución viable. Este sistema afectaría a la agilidad del sistema general y a la posibilidad de introducir la implementación de desfase entre servicios.

Normalmente, los problemas de seguridad se manejan mediante la puerta de enlace de API y el firewall de aplicaciones. La puerta de enlace y el firewall toman solicitudes entrantes, validan tokens y aplican varios filtros y directivas, como la implementación de los principios OWASP Top 10 para interceptar el tráfico. Por último, envían la solicitud a los microservicios de back-end. Esta configuración ayuda a los desarrolladores a centrarse en las necesidades empresariales en lugar de en la preocupación transversal de la seguridad.

Tenga en cuenta estos factores:

  • ¿Se requieren autenticación y autorización para el servicio?
  • ¿Usa una puerta de enlace de API para validar tokens y solicitudes entrantes?
  • ¿Usa SSL o mTLS para proporcionar seguridad para la comunicación del servicio?
  • ¿Tiene directivas de seguridad de red en marcha para permitir la comunicación necesaria entre los servicios?
  • ¿Usa firewalls (L4, L7) cuando corresponda para proporcionar seguridad a las comunicaciones internas y externas?
  • ¿Usa directivas de seguridad en la puerta de enlace de API para controlar el tráfico?

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes