Compartir a través de

Evaluación y preparación de microservicios

Una arquitectura de microservicios puede proporcionar muchas ventajas para las aplicaciones, incluida la agilidad, la escalabilidad y la 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 mejora.

Esta guía le ayudará a comprender 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.

Descripción de las prioridades empresariales

Para empezar a evaluar una arquitectura de microservicios, primero debe comprender las prioridades principales 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 una buena opción para sus prioridades principales. Tenga en cuenta que las prioridades empresariales pueden cambiar con el tiempo. Por ejemplo, la innovación es una prioridad máxima para las startups, pero después de unos años, las prioridades principales podrían ser confiabilidad y eficiencia.

Estas son algunas prioridades que se deben tener en cuenta:

  • Innovación
  • Fiabilidad
  • Eficacia

Documente los Acuerdos de Nivel de Servicio que están alineados con varias partes de la aplicación para garantizar un compromiso organizativo que pueda servir como guía para su evaluación.

Registrar decisiones arquitectónicas

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:

  • ¿La gobernanza compartida está en vigor?
  • ¿Realiza un seguimiento de las decisiones y sus acuerdos en un diario de arquitectura?
  • ¿Su equipo puede acceder fácilmente a su diario de arquitectura?
  • ¿Tiene un proceso para evaluar herramientas, tecnologías y marcos?

Evaluación de 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 funcionales 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 de diseño controlado por dominio (DDD)?
  • ¿Los equipos funcionan de forma cruzada, con capacidad suficiente para crear y operar microservicios relacionados de forma independiente?
  • ¿Cuánto tiempo se dedica a las actividades y tareas ad hoc que no están relacionadas con 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 aprenden las lecciones y se comunica la experiencia entre equipos?

Uso de la metodología Twelve-Factor

El objetivo fundamental de elegir una arquitectura de microservicios es ofrecer un valor más rápido y ser adaptable para cambiar siguiendo las prácticas ágiles. La metodología de aplicaciónTwelve-Factor proporciona directrices para crear aplicaciones fáciles de mantener y escalables. Estas directrices promueven atributos como la inmutabilidad, la efímero, la configuración declarativa y la automatización. Al incorporar estas directrices y evitar los problemas comunes, puede crear microservicios débilmente acoplados y autocontenidos.

Entender el enfoque de descomposición

La transformación de una aplicación monolítica en una arquitectura de microservicios tarda 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 con 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 notificaciones. Decide transformar el módulo de generación de facturas a continuación. 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 interfaces monolíticas y de microservicios, la propiedad de los datos, la descomposición del esquema, las uniones, el volumen de datos y la integridad de los datos podrían dificultar la descomposición y migración de 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 basados en la funcionalidad empresarial o el dominio, y aislar las bases de datos de los servicios. La solución recomendada consiste en descomponer cada base de datos con cada servicio. En muchas circunstancias, eso no es práctico. En esos casos, puede usar patrones como Database View y Database Wrapping Service.

Evaluación de 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 una de las prácticas clave que debe implementar para lograr esta competencia.

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

  • ¿Las personas de su organización conocen las prácticas y principios fundamentales de DevOps?
  • ¿Los equipos comprenden las herramientas de control de código fuente y su integración con canalizaciones de CI/CD?
  • ¿Implementa los procedimientos de DevOps correctamente?
    • ¿Sigue prácticas ágiles?
    • ¿Se implementa la integración continua?
    • ¿Se implementa la entrega continua?
    • ¿Se implementa la implementación continua?
    • ¿Se implementa la supervisión continua?
    • ¿Está en vigor la infraestructura como código (IaC)?
  • ¿Usas las herramientas adecuadas para soportar CI/CD?
  • ¿Cómo se administra la configuración de entornos de ensayo y 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 canales y documentación adecuados?

Identificación de á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 piensan que los compañeros cambiarán con frecuencia. La creación de microservicios permite a los equipos responder rápidamente a los cambios que los clientes solicitan y minimizan los esfuerzos de 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 en la publicación de 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 construido el servicio utilizando el patrón de chasis de microservicios compatible?

Evaluación de la preparación de la infraestructura

Al cambiar a una arquitectura de microservicios, la preparación de la infraestructura es un punto fundamental que se debe 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?
  • ¿La infraestructura admite el aprovisionamiento a través de scripts que se pueden automatizar a través de CI/CD?
  • ¿Ofrece la infraestructura de implementación un Acuerdo de Nivel de Servicio para disponibilidad?
  • ¿Tiene un plan de recuperación ante desastres (DR) y programaciones de simulacros rutinarios?
  • ¿Se replican los datos en diferentes regiones para la recuperación ante desastres?
  • ¿Tiene un plan de copia de seguridad de datos?
  • ¿Se documentan 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 los ciclos de versión

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

  • ¿Con qué frecuencia se compilan y liberan aplicaciones?
  • ¿Con qué frecuencia fallan tus lanzamientos después de la implementación?
  • ¿Cuánto tiempo se tarda en recuperarse o corregir problemas después de una interrupción?
  • ¿Usa el control de versiones semánticos 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 se cambia una versión de API?
  • ¿Cuál es tu enfoque para gestionar el versionado 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?

Evaluación de 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 confiable y confiable, debe seleccionar un protocolo de comunicación adecuado.

Tenga en cuenta 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ónico?
  • ¿Ha considerado la comunicación asincrónica en cualquier parte del sistema?
  • ¿Ha evaluado la tecnología del agente de mensajes y sus capacidades?
  • ¿Comprende el rendimiento de los mensajes que los servicios reciben y procesan?
  • ¿Usa la comunicación directa de cliente a servicio?
  • ¿Necesita conservar los mensajes en el nivel de agente de mensajes?
  • ¿Está utilizando el patrón de vista materializada para abordar el comportamiento verboso de los microservicios?
  • ¿Ha implementado Retry, Circuit Breaker, Exponential Backoff y Jitter para una comunicación confiable? Una manera común de controlar 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 confiable. Una puerta de enlace de API actúa como servidor proxy, interceptando el tráfico y enrutandolo a los servicios back-end. Si necesita filtrar el tráfico por dirección IP, autorización, respuestas ficticias, etc., puede hacerlo en el nivel de puerta de enlace de API sin realizar ningún cambio en los servicios.

Tenga en cuenta estos factores:

  • ¿Los clientes consumen directamente los servicios?
  • ¿Hay una puerta de enlace de API que actúe como fachada para todos los servicios?
  • ¿La puerta de enlace de API puede configurar directivas como límites de cuota, simular respuestas y filtrar 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 asociados?
  • ¿Proporciona la puerta de enlace de API un portal donde los clientes pueden detectar y suscribirse a servicios, como un portal para desarrolladores en Azure API Management?
  • ¿La solución proporciona funcionalidades de equilibrio de carga L7 o firewall de aplicaciones web (WAF) junto con la puerta de enlace de API?

Evaluación del control 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 sola 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 luego puede desencadenar otro evento, etc. hasta que todas las transacciones se completen o revierten, dependiendo de si la transacción se realiza correctamente.

Tenga en cuenta las siguientes consideraciones:

  • ¿Cuántas transacciones distribuidas hay en el sistema?
  • ¿Cuál es su enfoque para controlar las transacciones distribuidas? Evalúe 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 coherencia y la integridad de los datos?
  • ¿Usa operaciones de encadenamiento largo para transacciones que abarcan varios servicios?

Evaluación del 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 desarrollo de nuevos servicios?
  • ¿Sigue la metodología de la aplicación Twelve-Factor 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?
  • ¿Conteneriza sus servicios en contenedores?
  • ¿Conoce los requisitos de coherencia de datos?

Evaluación del 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ápidas 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 sus servicios?
  • ¿Qué tipo de colaboración se necesita entre los equipos al implementar servicios?
  • ¿Aprovisiona la infraestructura mediante infraestructura como código (IaC)?
  • ¿Usa las funcionalidades de DevOps para automatizar las implementaciones?
  • ¿Propaga las mismas compilaciones a varios entornos, como sugiere la metodología de aplicación de Twelve-Factor?

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 lugar a tiempo de inactividad, riesgo de implementación y mantenimiento. Es posible que la aplicación monolítica esté bien diseñada, con componentes que abordan dominios empresariales individuales. Pero debido a la falta de límites del proceso, la posibilidad de infringir los principios de responsabilidad única se vuelve 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 al proporcionar 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 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 tarda en escalar la plataforma de hospedaje?
  • ¿Comprende los Acuerdos de Nivel de Servicio que proporcionan varias plataformas de hospedaje?
  • ¿La plataforma de hospedaje admite la recuperación ante desastres?

Evaluación de 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 de errores puede ser intimidante. Si usa la semántica adecuada para supervisar los servicios, los equipos pueden supervisar, investigar y responder fácilmente a errores.

Tenga en cuenta estos factores:

  • ¿Supervisa los servicios implementados?
  • ¿Tiene un sistema de registro? ¿Qué herramientas usa?
  • ¿Tiene una infraestructura de seguimiento distribuida en su lugar?
  • ¿Registra excepciones?
  • ¿Mantiene códigos de error empresariales para identificar rápidamente los problemas?
  • ¿Usa sondas de salud para servicios?
  • ¿Usa el registro semántico? ¿Ha implementado métricas, umbrales e indicadores clave?
  • ¿Enmascara los datos confidenciales durante el registro?

Evaluación de 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, interactuando entre sí para atender varios casos de uso empresarial. 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. Se recomienda usar tokens de correlación, ya que pueden ayudarle a solucionar errores. 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 mediante la identificación de qué servicios contienen el token de correlación y cuáles no. Los servicios que no disponen del token de correlación para esa solicitud fallaron. 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 fácilmente los problemas si alguno de los servicios produce un error durante una transacción. Cada servicio normalmente tiene su propia base de datos. El token de correlación se mantiene en el registro de la base de datos. En el caso de una reproducción de transacciones, los servicios que tienen ese token de correlación concreto en sus bases de datos omiten la solicitud. Solo los servicios que no tienen el token atienden la solicitud.

Tenga en cuenta estos factores:

  • ¿En qué fase se asigna el token de correlación?
  • ¿Qué componente asigna el token de correlación?
  • ¿Guarda los 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?

Evaluar la necesidad de un marco de chasis de microservicios

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

Por ejemplo, supongamos que va a crear un servicio de gestión de carritos de compras. Quiere validar el token entrante, escribir registros en la base de datos de registro y comunicarse con otro servicio invocando el punto de conexión del servicio. Si usa un marco de chasis de microservicios, puede reducir los esfuerzos de desarrollo. Dapr es un sistema que proporciona varios bloques fundamentales para implementar temas transversales.

Tenga en cuenta estos factores:

  • ¿Usa un marco de microservicios de chasis?
  • ¿Usa Dapr para interactuar con preocupaciones transversales?
  • ¿La estructura del chasis es independiente del lenguaje?
  • ¿Es genérico el marco de chasis, por lo que admite todo tipo de aplicaciones? Un marco de chasis no debe contener lógica específica de la aplicación.
  • ¿Proporciona el marco de chasis un mecanismo para usar los componentes o servicios seleccionados según sea necesario?

Evaluación del enfoque para las pruebas de aplicaciones

Tradicionalmente, las pruebas se realizan una vez completado el desarrollo y la aplicación está lista para implementarse en entornos de producción y pruebas de aceptación de usuario (UAT). Actualmente hay un cambio en este enfoque, adelantando las pruebas al inicio del ciclo de vida de 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, al compilar una aplicación, empiece por diseñar una arquitectura. Cuando se usa el enfoque de desplazamiento a la izquierda, se prueba el diseño de vulnerabilidades mediante herramientas como Microsoft Threat Modeling. Al iniciar el desarrollo, puede examinar el código fuente mediante la ejecución de herramientas como pruebas estáticas de seguridad de aplicaciones (SAST) y el uso de otros analizadores para descubrir problemas. Después de implementar la aplicación, puede usar herramientas como pruebas dinámicas de seguridad de 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 producen más adelante.

Tenga en cuenta estos factores:

  • ¿Escribe planes de prueba que cubren todo el ciclo de vida de desarrollo?
  • ¿Incluye evaluadores en reuniones de requisitos y en todo el ciclo de vida de desarrollo de aplicaciones?
  • ¿Usa el diseño controlado por pruebas o el diseño controlado por comportamientos?
  • ¿Prueba historias de usuario? ¿Incluye criterios de aceptación en sus historias de usuario?
  • ¿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 prácticas seguras de DevOps ?
  • ¿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?

Evaluación de la seguridad de los microservicios

La protección del servicio, el acceso seguro y la comunicación segura se encuentran entre las consideraciones más importantes para una arquitectura de microservicios. Por ejemplo, un sistema basado en microservicios que abarca varios servicios y usa 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 al potencial de introducir el desfase de implementación entre los servicios.

Normalmente, las preocupaciones de seguridad se controlan mediante la puerta de enlace de API y el firewall de aplicaciones. El gateway y el firewall procesan solicitudes entrantes, validan tokens y aplican varios filtros y políticas, como la implementación de los principios del OWASP Top 10, para interceptar el tráfico. Por último, envían la solicitud a los microservicios 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 requiere 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 de servicio?
  • ¿Tiene directivas de seguridad de red para permitir la comunicación necesaria entre los servicios?
  • ¿Usa firewalls (L4, L7) si procede para proporcionar seguridad para las comunicaciones internas y externas?
  • ¿Usa directivas de seguridad en API Gateway para controlar el tráfico?

Colaboradores

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

Autores principales:

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

Pasos siguientes