Compartir a través de

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

  • Artículo

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, divida los detalles de la plataforma desglosando 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 (tamaño de camiseta, 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, habrá 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 puede necesitar una configuración específica que esté fuera de los valores predeterminados de plantilla admitidos. En esta instancia, las operaciones o los equipos de ingeniería de plataforma 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 Terraform y en la nube (ejemplos, Cluster API, Crossplane, Azure Service Operator v2). Fuera del 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; supervisa los cambios fuera del código de infraestructura y para 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 SaaS, PaaS o IaaS. Para más información sobre SaaS, PaaS e IaaS, consulte el módulo de entrenamiento Descripción de los conceptos de 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, si crea aplicaciones directamente en Azure Kubernetes Service (AKS) o a través de Azure Container Apps (ACA) depende de los requisitos del servicio y del conjunto de aptitudes y capacidad interna. Lo mismo sucede con los servicios de estilo de función, como Azure Functions o App de Azure Service. ACA, Azure 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 radius de 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 que identificó cuando planeó deben ayudarle a evaluar qué final de esta escala es adecuado para usted. Asegúrese de factorizar su propio conjunto de aptitudes interno existente a medida que 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 uno de los recursos compartidos tiene su propio conjunto de consideraciones. Por ejemplo, estas son consideraciones para compartir clústeres K8s, pero algunas se aplicarán a otros tipos de recursos:

  • Organización: compartir recursos como los clústeres dentro de, en lugar de a través, los límites de la organización pueden mejorar cómo se alinean con la dirección, los requisitos y la prioridad de la organización.
  • Inquilino de aplicaciones: las aplicaciones pueden tener diferentes requisitos de aislamiento de inquilino; debe revisar la seguridad de las aplicaciones individuales y el cumplimiento normativo 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 el inquilino de aplicaciones para distintos tipos de entorno. 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 cada uso de recursos de aplicación, capacidad de reserva 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 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 las configuraciones compartidas: los recursos compartidos, como los clústeres compartidos, requieren consideraciones y configuraciones adicionales. 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 de valor empresarial para las aplicaciones es un desafío común. Hay dos partes de la gobernanza:

  • Cumplimiento de implementación inicial (derecho de inicio): 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 los recursos y configuraciones permitidos.
  • Mantener el cumplimiento (mantener el derecho): las herramientas basadas en directivas pueden evitar 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 K8s, junto con los sistemas operativos usados 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 (por ejemplo, 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 la posibilidad de evolucionar a una directiva como práctica de código (PaC) al operar a escala. Como parte clave de su enfoque de inicio correcto y correcto , 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
  • Implementación continua

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.
  • La implementación gradual basada en anillos de directivas y corrección en los recursos existentes ayuda a minimizar el radio de explosión 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 del rol

Para admitir las aplicaciones y la infraestructura, necesita observabilidad y registro en toda la pila.

Ilustración de un panel de Grafana que muestra la observabilidad y el registro.

Los requisitos difieren por rol. Por ejemplo, el equipo de ingeniería y operaciones de plataforma requiere 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 brechas de conocimiento debido a la falta de información útil.

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

  • Estándares: aplique estándares de registro para facilitar la creación y reutilización de paneles estandarizados y simplificar el procesamiento de ingesta a través de algo parecido al marco de observabilidad de OpenTelemetry.
  • Permisos: proporcione paneles de nivel de equipo o de aplicación con algo parecido a Grafana para proporcionar datos inscritos para cualquier persona interesada, junto con una instalación para que los miembros de confianza de los equipos de aplicaciones obtengan acceso de forma segura 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.
  • Supervisar los 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 K8s para la capacidad a medida que las aplicaciones se incorporan y modifican con el tiempo. Se necesitan alertas y estas definiciones deben almacenarse como código para que se puedan agregar mediante programación a los recursos.
  • Identificar las métricas clave de capacidad y estado: supervise y alerte el sistema operativo y los recursos compartidos (ejemplos: CPU, memoria, almacenamiento) para el colapso con la recopilación de métricas mediante algo como Prometheus o Azure Container Insights. 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.

Cree la seguridad con el principio de privilegios mínimos, administración unificada de seguridad y 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:

  • Para ello, aplique el principio de acceso con privilegios mínimos.
  • Unifique la administración de seguridad de DevOps en varias canalizaciones.
  • 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:

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, es posible permitir la implementación automatizada de recursos y aplicaciones y el acceso a clústeres para solucionar problemas en entornos de desarrollo y pruebas.

La administración del acceso de identidad a servicios, aplicaciones, infraestructura a escala puede ser difícil. Proveedores de identidades para crear, mantener y administrar información de identidad. El plan debe incluir servicios de autenticación para aplicaciones y servicios y que se pueden integrar con sistemas 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 AKS, 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 se asigna a los propietarios de un conjunto determinado 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 la posibilidad de ejecutar informes regulares para realizar 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 al alcanzar umbrales preestablecidos.

Decidir cuándo y dónde invertir

Si tiene más de una plataforma de aplicaciones, puede resultar complicado decidir cuándo y dónde invertir en mejoras que resuelvan problemas como costos elevados o observabilidad deficiente. Si va a empezar a trabajar de nuevo, el Centro de arquitectura de Azure tiene varios patrones potenciales para evaluarlo. 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:

Pregunta Sugerencias
¿Desea adaptar la plataforma de aplicaciones existente, empezar de nuevo o usar una combinación de estos enfoques? Incluso si estás satisfecho con lo que tienes ahora o estás empezando nuevo, quieres pensar en cómo adaptarte a los cambios a lo largo del tiempo. Los cambios inmediatos rara vez funcionan. Las plataformas de aplicaciones son un destino móvil. El sistema ideal cambia a medida que pasa el tiempo. Quiere factorizar este pensamiento y los planes de migración relacionados en el diseño de avance.
Si desea cambiar lo que está haciendo hoy, ¿con qué productos, servicios o inversiones está satisfecho? Como dice el dicho, "si no está roto, no lo corrijas". No cambies las cosas sin una razón para hacerlo. Sin embargo, si tiene alguna solución de cultivo doméstico, considere si es el momento de avanzar hacia un producto existente para ahorrar en el mantenimiento a largo plazo. Por ejemplo, si está operando su propia solución de supervisión, ¿desea quitar esa carga del equipo de operaciones y migrar a un nuevo producto administrado?
¿Dónde ve el cambio más importante a lo largo del tiempo? ¿Son cualquiera de estas áreas que son comunes a todos (o la mayoría) de los tipos de aplicaciones de su organización? Las áreas con las que usted o sus clientes internos no están satisfechos y no es probable que cambien con frecuencia son excelentes lugares para empezar. Estos tienen el mayor retorno de la inversión a largo plazo. Esto también puede ayudarle a resolver cómo facilitar la migración a una nueva solución. Por ejemplo, los modelos de aplicaciones tienden a ser fluidos, pero las herramientas de análisis de registros tienden a tener una vida útil más larga. También puede centrarse en los nuevos proyectos o aplicaciones para iniciarse mientras confirma que el cambio de dirección tiene los resultados deseados.
¿Está invirtiendo en soluciones personalizadas en áreas con el mayor valor añadido? ¿Cree firmemente que una funcionalidad única de la plataforma de infraestructura de aplicaciones forma parte de su ventaja competitiva? Si ha identificado brechas, antes de hacer algo personalizado, tenga en cuenta qué áreas es más probable que los proveedores inviertan y centren su pensamiento personalizado en otro lugar. Empiece pensando en usted mismo como integrador en lugar de como un proveedor de modelos de aplicaciones o infraestructura de aplicaciones personalizada. Todo lo que cree tendrá que mantenerse que enanos los costos iniciales a largo plazo. Si cree que la necesidad urgente de crear una solución personalizada en un área sospechosa estará cubierta por proveedores a largo plazo, plan de puesta de sol o soporte técnico a largo plazo. Los clientes internos suelen ser tan felices (si no más) con un producto fuera del estante como personalizado.

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 fuera de la estantería. 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