Refinar la plataforma de aplicaciones para simplificar el desarrollo y la administración de infraestructura

Una gran parte de la mejora de las prácticas de ingeniería de plataforma de su organización es evaluar la plataforma de aplicaciones. Una plataforma de aplicaciones incluye todas las herramientas y servicios que se usan para admitir el desarrollo, la implementación y la administración de aplicaciones en su organización.

Simplificación y estandarización

La infraestructura como código (IaC) y las herramientas de automatización se pueden combinar con plantillas para estandarizar la infraestructura y la implementación de aplicaciones. Para reducir la carga de los detalles de la plataforma en el usuario final, puede abstraer los detalles de la plataforma dividiendo las opciones en convenciones de nomenclatura relacionadas, por ejemplo:

• Categorías de tipo de recurso (proceso alto, memoria alta)
• Categorías de tamaño de recursos (por ejemplo, tamaño de camiseta en tamaño pequeño, mediano y grande)

Las plantillas deben representar requisitos generales que se han probado con configuraciones preestablecidas, por lo que los equipos de desarrollo pueden empezar a proporcionar parámetros mínimos y sin necesidad de revisar las opciones. Sin embargo, hay ocasiones en las que los equipos necesitan cambiar más opciones en las plantillas publicadas de las que están disponibles o deseables. Por ejemplo, un diseño aprobado podría necesitar una configuración específica fuera de los valores predeterminados de plantilla admitidos. En este caso, los equipos de ingeniería de operaciones o plataformas pueden crear una configuración única y, a continuación, decidir si la plantilla debe incorporar esos cambios como valor predeterminado.

Puede realizar un seguimiento de los cambios mediante herramientas de IaC con características de detección de desfase que pueden corregir automáticamente el desfase (GitOps). Algunos ejemplos de estas herramientas son Las herramientas de IaC nativas de la nube y Terraform (por ejemplo, Cluster API, Crossplane, Azure Service Operator v2). Fuera de la detección de desfase de herramientas de IaC, hay herramientas de configuración en la nube que pueden consultar configuraciones de recursos, como Azure Resource Graph. Estos pueden servir como dos ventajas; para supervisar los cambios fuera del código de infraestructura y revisar las configuraciones preestablecidas modificadas. Para evitar ser demasiado rígido, puede implementar tolerancias en implementaciones también con límites predefinidos. Por ejemplo, puede usar Azure Policy para limitar el número de nodos de Kubernetes que puede tener una implementación.

¿Autoadministrado o administrado?

En las nubes públicas, tiene la opción de consumir software como servicio (Saas), plataforma como servicio (PaaS) o infraestructura como servicio (IaaS). Para más información sobre SaaS, PaaS e IaaS, consulte el módulo de entrenamiento Describir los tipos de servicio en la nube. Los servicios paaS ofrecen experiencias de desarrollo simplificadas, pero son más prescriptivas con sus modelos de aplicación. En última instancia, hay un equilibrio entre la facilidad de uso y el control que necesita evaluar.

Durante el diseño de la plataforma, evalúe y priorice las necesidades de servicio de su organización. Por ejemplo, tanto si desarrolla aplicaciones directamente en Azure Kubernetes Service (AKS) como a través de Azure Container Apps depende de sus requisitos para el servicio y de la capacidad interna y el conjunto de aptitudes. Lo mismo sucede con los servicios de estilo de función, como Azure Functions o Azure App Service. Container Apps, Functions y App Service reducen la complejidad, mientras que AKS proporciona más flexibilidad y control. Más modelos de aplicaciones experimentales, como el proyecto de incubación de Radius OSS , intentan proporcionar un equilibrio entre los dos, pero generalmente se encuentran en fases anteriores de madurez que los servicios en la nube con soporte completo y una presencia en formatos iaC establecidos.

Los problemas identificados durante la planeación deben ayudarle a evaluar qué final de esta escala es adecuado para usted. Asegúrese de considerar su propio conjunto de aptitudes internas existentes cuando tome una decisión.

Recursos compartidos frente a recursos dedicados

Dentro de su organización, hay recursos que pueden compartir varias aplicaciones para aumentar el uso y la rentabilidad. Cada recurso compartido tiene su propio conjunto de consideraciones. Por ejemplo, estas son consideraciones para compartir clústeres de Kubernetes, pero algunas se aplican a otros tipos de recursos:

• Organización: Compartir recursos, como los clústeres, dentro de los límites de la organización, en lugar de hacerlo a través de ellos, puede mejorar la alineación con la dirección, los requisitos y las prioridades organizacionales.
• Tenencia de aplicación: Las aplicaciones pueden tener diferentes requisitos de aislamiento de tenencia, y es necesario revisar la seguridad y el cumplimiento normativo de cada aplicación individual para determinar si puede coexistir con otras aplicaciones. Por ejemplo, en Kubernetes, las aplicaciones pueden usar el aislamiento del espacio de nombres. Pero también debe tener en cuenta la tenencia de aplicaciones para diferentes tipos de entornos. Por ejemplo, a menudo es mejor evitar mezclar aplicaciones de prueba con aplicaciones de producción en los mismos clústeres para evitar impactos inesperados debido a errores de configuración o problemas de seguridad. O bien, puede optar por probar y optimizar primero los clústeres de Kubernetes dedicados para realizar un seguimiento de estos problemas antes de la implementación en un clúster compartido en su lugar. Independientemente de la coherencia en su enfoque es la clave para evitar confusiones y errores.
• Consumo de recursos: Comprenda el uso de recursos y la capacidad de reserva de cada aplicación y realice una proyección para calcular si el uso compartido es viable. También debe tener en cuenta los límites de los recursos consumidos (capacidad del centro de datos o límites de suscripción). El objetivo es evitar mover la aplicación y las dependencias debido a restricciones de recursos en un entorno compartido o a tener incidentes de sitio activo cuando se agota la capacidad. Use límites de recursos, pruebas representativas, alertas de supervisión e informes para identificar el consumo de recursos y protegerse frente a las aplicaciones que consumen demasiados recursos.
• Optimización de configuraciones compartidas: Los recursos compartidos, como los clústeres compartidos, requieren consideraciones adicionales y configuración. Estas consideraciones incluyen la carga cruzada, la asignación de recursos, la administración de permisos, la propiedad de la carga de trabajo, el uso compartido de datos, la coordinación de actualizaciones, la colocación de cargas de trabajo, el establecimiento, la administración e iteración de una configuración de línea base, la administración de la capacidad y la selección de ubicación de la carga de trabajo. Los recursos compartidos tienen ventajas, pero si las configuraciones estándar son demasiado restrictivas y no evolucionan, se vuelven obsoletas.

Implementación de estrategias de gobernanza

La gobernanza es una parte clave de la habilitación del autoservicio con límites de protección, pero la aplicación de reglas de cumplimiento de una manera que no afecta al tiempo al valor empresarial para las aplicaciones es un desafío común. Hay dos partes de la gobernanza:

• Cumplimiento inicial de la implementación (inicio derecho): Esto se puede lograr con plantillas iaC estandarizadas que están disponibles a través de catálogos, con administración de permisos y directivas para asegurarse de que solo se pueden implementar recursos y configuraciones permitidos.
• Mantener el cumplimiento (permanecer en el marco normativo): Las herramientas basadas en directivas pueden prevenir o avisarle cuando haya cambios en los recursos. Además de la infraestructura principal, tenga en cuenta que las herramientas también admiten el cumplimiento dentro de los recursos, como Kubernetes, junto con el sistema operativo que se usa en los contenedores o máquinas virtuales. Por ejemplo, es posible que quiera aplicar una configuración del sistema operativo bloqueada o instalar herramientas de software de seguridad como la directiva de grupo de Windows, SELinux, AppArmor, Azure Policy o Kyverno. Si los desarrolladores solo tienen acceso a repositorios de IaC, puede agregar flujos de trabajo de aprobación para revisar los cambios propuestos y evitar el acceso directo a los planos de control de recursos, como Azure.

Mantener el cumplimiento requiere herramientas para acceder, notificar y actuar sobre problemas. Por ejemplo, Azure Policy se puede usar con muchos servicios de Azure para auditar, notificar y corregir. También tiene diferentes modos, como Audit, Deny e DeployIfNotExists en función de sus necesidades.

Aunque las directivas pueden aplicar el cumplimiento, también pueden interrumpir las aplicaciones de forma inesperada. Por lo tanto, considere evolucionar hacia una práctica de política como código (PaC) al operar a escala. Como parte clave de su enfoque de inicio correcto y permanencia adecuada, PaC proporciona:

• Estándares administrados de forma centralizada
• Control de versiones para las directivas
• Pruebas y validación automatizadas
• Tiempo reducido para la implementación
• Despliegue continuo

PaC puede ayudar a minimizar el radio de explosión de una directiva potencialmente incorrecta con funcionalidades como:

• Definiciones de directiva almacenadas como código en un repositorio que se revisa y aprueba
• Automatización para proporcionar pruebas y validación
• El despliegue gradual basado en anillos de políticas y la remediación de los recursos existentes ayuda a minimizar el radio de impacto de una política potencialmente incorrecta.
• La tarea de corrección tiene integrada la seguridad, con controles como detener la tarea de corrección si se produce un error en más del 90 por ciento de las implementaciones.

Implementación de la observabilidad y el registro específicos para cada rol

Para soportar sus aplicaciones e infraestructura, necesita observabilidad y registro de eventos en toda la pila.

Los requisitos difieren por rol. Por ejemplo, los equipos de ingeniería y operaciones de plataforma requieren paneles para revisar el estado y la capacidad de la infraestructura con alertas adecuadas. Los desarrolladores requieren métricas, registros y seguimientos de aplicaciones para solucionar problemas y paneles personalizados que muestran el estado de la aplicación y la infraestructura. Un problema que puede surgir en cualquiera de estos roles es la sobrecarga cognitiva de demasiada información o lagunas de conocimiento debido a una falta de información útil.

Para resolver estos desafíos, tenga en cuenta lo siguiente:

• Normas: Aplique normas de registro para facilitar la creación y reutilización de paneles estandarizados y simplificar el procesamiento de datos de entrada mediante algo como el marco de observabilidad de OpenTelemetry.
• Permisos: Proporcionar paneles de nivel de equipo o de aplicación con algo parecido a Grafana para proporcionar datos consolidados a cualquier persona interesada, junto con una funcionalidad para que los miembros de confianza de los equipos de aplicación obtengan acceso seguro a los registros cuando sea necesario.
• Retención: La retención de registros y métricas puede ser costosa y puede crear riesgos no deseados o infracciones de cumplimiento. Establezca los valores predeterminados de retención y publíquelos como parte de la guía de inicio correcta.
• Supervisión de límites de recursos: Los equipos de operaciones deben poder identificar y realizar un seguimiento de las limitaciones de un tipo determinado de recurso. Estas limitaciones deben tenerse en cuenta en plantillas o directivas de IaC mediante herramientas como Azure Policy. Después, las operaciones deben supervisar de forma proactiva el uso de paneles en algo como Grafana y expandir los recursos compartidos en los que el escalado automatizado no es posible o habilitado. Por ejemplo, supervise el número de nodos de clúster de Kubernetes para obtener capacidad a medida que las aplicaciones se incorporan y modifican a lo largo del tiempo. Se necesitan alertas y estas definiciones deben almacenarse como código para que se puedan agregar mediante programación a los recursos.
• Identificar la capacidad clave y las métricas de capacidad y estado: Supervise y alerte el sistema operativo y los recursos compartidos (por ejemplo, CPU, memoria y almacenamiento) para evitar el agotamiento, con la recopilación de métricas usando algo como Prometheus o Kubernetes en Azure Monitor. Puede supervisar sockets o puertos en uso, el consumo de ancho de banda de red de las aplicaciones chatty y el número de aplicaciones con estado hospedadas en el clúster.

Incorpore la seguridad con el principio del menor privilegio, la gestión unificada de seguridad y la detección de amenazas.

La seguridad es necesaria en cada capa, desde el código, el contenedor, el clúster y la nube o la infraestructura. Estos son los pasos de seguridad mínimos recomendados:

• Siga el principio de privilegios mínimos.
• Unifique la gestión de seguridad de DevOps en varios pipelines.
• Asegúrese de que las conclusiones contextuales para identificar y corregir el riesgo más crítico son visibles.
• Habilite la detección y la respuesta a amenazas modernas en las cargas de trabajo en la nube en tiempo de ejecución.

Para ayudar a resolver problemas en esta área, necesita herramientas para evaluar las herramientas que funcionan en los sistemas de ingeniería y aplicaciones, recursos y servicios en nubes e híbridos (por ejemplo, Microsoft Defender for Cloud). Más allá de la seguridad de la aplicación, evalúe:

• Administración de superficie de ataque externo utilizando algo como Microsoft Defender External Attack Surface Management (Defender EASM).
• Servicios de seguridad de red: proteja las aplicaciones y las cargas de trabajo en la nube de los ciberataques basados en red mediante algo parecido a Azure Network Security.
• Análisis de seguridad inteligente mediante una solución de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel.
• Formas de controlar, proteger, visualizar y administrar el patrimonio de datos de forma segura como Microsoft Purview.
• Formas de examinar el código para detectar posibles vulnerabilidades de seguridad, detectar secretos, revisar dependencias como Seguridad avanzada de GitHub y Seguridad avanzada de GitHub para Azure DevOps.
• Administración de la cadena de suministro de software, especialmente para contenedores. Por ejemplo, aplique el marco de cadena de suministro seguro de contenedores.

Los requisitos de permisos pueden diferir según el entorno. Por ejemplo, en algunas organizaciones, los equipos individuales no pueden acceder a los recursos de producción y las nuevas aplicaciones no se pueden implementar automáticamente hasta que se completen las revisiones. Sin embargo, la implementación automatizada de recursos y aplicaciones y el acceso a clústeres para la solución de problemas podrían permitirse en entornos de desarrollo y pruebas.

La administración del acceso de identidad a servicios, aplicaciones, infraestructura a escala puede ser difícil. Los proveedores de identidades crean, mantienen y administran la información de identidad. El plan debe incluir servicios de autenticación para aplicaciones y servicios, y esos servicios deben integrarse con sistemas de autorización de control de acceso basado en rol (RBAC) a escala. Por ejemplo, puede usar microsoft Entra ID para proporcionar autenticación y autorización a escala para servicios de Azure como Azure Kubernetes Service sin necesidad de configurar permisos directamente en cada clúster individual.

Es posible que las aplicaciones necesiten acceso a una identidad para acceder a recursos en la nube, como el almacenamiento. Debe revisar los requisitos y evaluar cómo el proveedor de identidades puede admitir esto de la manera más segura posible. Por ejemplo, dentro de Azure Kubernetes Service, las aplicaciones nativas en la nube pueden usar una identidad de carga de trabajo que se federa con el identificador de Entra de Microsoft para permitir que las cargas de trabajo en contenedores se autentiquen. Este enfoque permite que las aplicaciones accedan a recursos en la nube sin intercambios secretos dentro del código de la aplicación.

Reducir los costos mediante la identificación de propietarios de cargas de trabajo y el seguimiento de recursos

La administración del costo es otra parte de la ingeniería de plataformas. Para administrar correctamente la plataforma de aplicaciones, necesita una manera de identificar a los propietarios de cargas de trabajo. Quiere obtener un inventario de recursos que asigna a los propietarios de un conjunto específico de metadatos. Por ejemplo, en Azure, puede usar etiquetas de AKS, etiquetas de Azure Resource Manager, junto con conceptos como proyectos en entornos de implementación de Azure para agrupar los recursos en distintos niveles. Para que esto funcione, los metadatos elegidos deben incluir propiedades obligatorias (con algo parecido a Azure Policy) al implementar cargas de trabajo y recursos. Esto ayuda con la asignación de costos, la asignación de recursos de solución y los propietarios. Considere ejecutar informes regulares para hacer un seguimiento de los recursos huérfanos.

Más allá del seguimiento, es posible que tenga que asignar costos a equipos de aplicaciones individuales para su uso de recursos mediante estos mismos metadatos con sistemas de administración de costos como Microsoft Cost Management. Aunque este método realiza un seguimiento de los recursos aprovisionados por los equipos de aplicaciones, no cubre el costo de los recursos compartidos, como el proveedor de identidades, el registro y el almacenamiento de métricas, y el consumo de ancho de banda de red. En el caso de los recursos compartidos, puede dividir igualmente los costos operativos por parte de los equipos individuales o proporcionar sistemas dedicados (por ejemplo, almacenamiento de registro) donde haya un consumo no uniforme. Algunos tipos de recursos compartidos pueden proporcionar información sobre el consumo de recursos. Por ejemplo, Kubernetes tiene herramientas como OpenCost o Kubecost y pueden ayudar.

También debe buscar herramientas de análisis de costos en las que puede revisar los gastos actuales. Por ejemplo, en Azure Portal, hay alertas de costos y alertas de presupuestos que pueden realizar un seguimiento del consumo de recursos de un grupo y enviar notificaciones cuando se alcanzan los umbrales preestablecidos.

Decidir cuándo y dónde invertir

Si tiene más de una plataforma de aplicaciones, puede ser difícil decidir cuándo y dónde invertir en mejoras que resuelvan problemas como costos altos o observabilidad deficiente. Si va a empezar desde cero, el Centro de arquitectura de Azure tiene varios patrones potenciales para evaluarlos. Pero más allá de eso, estas son algunas preguntas que debe tener en cuenta a medida que empiece a planear lo que desea hacer:

Adaptar las inversiones existentes en la plataforma de aplicaciones puede ser una buena manera de empezar. Al realizar actualizaciones, considere la posibilidad de empezar con nuevas aplicaciones para simplificar las ideas piloto antes de cualquier tipo de implementación. Tenga en cuenta este cambio a través de IaC y plantillas de aplicaciones. Invierta en soluciones personalizadas para sus necesidades únicas en áreas de alto impacto y alto valor. De lo contrario, intente usar una solución comercial. Al igual que con los sistemas de ingeniería, céntrese en automatizar el aprovisionamiento, el seguimiento y la implementación en lugar de asumir una ruta rígida para ayudarle a administrar los cambios a lo largo del tiempo.

Contenido relacionado

• Diseño de una base de autoservicio para desarrolladores