5 Acciones que Puede Implementar con las Revisiones “Well-Architected” de AWS

Como una de las 34 empresas elegidas globalmente para el AWS’ Well Architected Partner Program, Rackspace ofrece una amplia experiencia en revisión e implementación.

AWS desarrolló su Marco de Buena Arquitectura para ayudar a los arquitectos de la nube a crear infraestructuras seguras, de alto rendimiento, flexibles y eficientes para las aplicaciones. El marco también ofrece a los clientes una forma consistente de evaluar esas arquitecturas.

Rackspace fue recientemente seleccionado por AWS como una de las 34 empresas en todo el mundo para formar parte de su Well-Architected Partner Program. Como socio consultor premier desde hace mucho tiempo, Rackspace ha entregado numerosas revisiones Well-architected de AWS, para nuestros clientes en conjunto. Este post comparte algunos de los hallazgos más comunes revelados durante nuestras revisiones, con sugerencias de cómo enfrentar estos desafíos.

Por ejemplo, creemos que es fundamental que los líderes empresariales participen en estas revisiones junto con los expertos técnicos por dos razones principales; en primer lugar, su arquitectura y diseño deben ser impulsados por los objetivos de negocio, y en segundo lugar, da a los líderes empresariales una comprensión más a detalle de los costos y la complejidad de las compensaciones a veces necesarias.

Alta disponibilidad frente a costos y complejidad

En ninguna parte son esos inconvenientes más evidentes que con el nivel de disponibilidad, o el porcentaje de tiempo que una aplicación está disponible. Si se ha diseñado de acuerdo con los principios de alta disponibilidad, una infraestructura puede sufrir múltiples fallos, al mismo tiempo que puede seguir atendiendo la solicitud entrante.

Aunque a la mayoría de los clientes les encantaría tener un 100% de disponibilidad, es muy difícil y costoso de lograr. Dependiendo de cuán grande sea la infraestructura, incluso la diferencia entre el 99.99% y el 99.9% de disponibilidad puede ser considerable. Preguntamos a nuestros clientes:

  • ¿Cuánto tiempo de inactividad del sistema puede soportar el negocio?
  • ¿Cuánto tiempo debe tomar el sistema para recuperarse de un incidente?
  • ¿Cuánta información se espera que se pierda y no sea recuperable en el peor de los casos?

Estas preguntas pueden ser difíciles de contestar. Pero es vital entender las realidades de los sistemas de TI, planificar en consecuencia y diseñar para los fallos.

Basar las necesidades de infraestructura en métricas precisas

Nos encontramos con demasiadas organizaciones que toman decisiones de infraestructura basadas en “adivinar” en lugar de métricas precisas.

Mientras que el diseño inicial para su infraestructura le servirá bien al principio, a medida que las situaciones cambian y las empresas crecen, los recursos eventualmente pueden ser mal provisionados, lo que significa que la experiencia del usuario sufre o se aprovisiona de forma excesiva, lo que significa que el usuario puede haber perdido la oportunidad de reinvertir el dinero para lograr un SLA más alto.

Pero los cambios en la configuración de la infraestructura deben basarse en métricas. Aquí hay varias métricas que cada organización debe recopilar y revisar con frecuencia:

  • Tiempo de actividad de los recursos.
  • Tiempo de recuperación.
  • Objetivos del punto de recuperación.
  • Objetivos de la utilización de recursos.
  • Costos y proyecciones de la infraestructura.
  • Resultados de pruebas de carga.
  • Resultados de la comprobación de rendimiento de aplicaciones (APM) (por ejemplo, tiempo de solicitud, tiempo de finalización de la transición, tiempo de consulta de base de datos, etc.).

Extender DevOps con DevSecOps

Muchas empresas aún no han integrado la seguridad en su proceso de DevOps.

Con una mayor adopción de DevOps, los ingenieros ahora automatizan muchas tareas operativas diarias y la seguridad de TI debe ser una de ellas. Las respuestas a los incidentes pueden implicar herramientas o acceso previamente implementados, cambio de control de permisos de red o actualizaciones de políticas de parches. DevSecOps tiene como objetivo integrar las tareas de operaciones de seguridad en flujos de DevOps preexistentes. Eso puede incluir:

  • Auditoría automatizada de registros de acceso y llamadas a la API con alertas.
  • Gestión automatizada y optimizada de parches.
  • Infraestructura automatizada como pruebas de vulnerabilidad de código en las canalizaciones de implementación.
  • Inyección de fallas automatizada para validar la flexibilidad de la plataforma (como parte de un plan de recuperación ante desastres más amplio).

Creación de un esquema de clasificación de datos

A menudo nos encontramos con usuarios que tratan con la misma importancia todos los datos que almacenan en AWS.

Al hacerlo, ha hecho que la infraestructura sea excesivamente compleja y costosa, o se arriesga a no cumplir con los cumplimientos legales. Las siguientes preguntas pueden ayudar a los clientes a obtener el diseño de infraestructura y el modelo de operación correcto. Al igual que al determinar el SLA de una aplicación, es de vital importancia que el dueño de la aplicación participe en la respuesta a estas preguntas.

  • ¿Qué tipo de datos se almacenan en mi ambiente de AWS?
  • ¿Cuáles son los requisitos legales para estos datos?
  • ¿Es suficiente la protección, el control de acceso y el cifrado de los datos?
  • ¿Cuántos datos se almacenan y cuántos se almacenarán en el futuro?
  • ¿Durante cuánto tiempo debo conservar los datos?

Implementar un gobierno de costos efectivo

El gobierno de costos es fundamental, especialmente cuando el entorno de AWS de una organización se vuelve más complejo. Como socio de AWS, Rackspace ofrece herramientas integrales para el gobierno de costos. Sugerimos los siguientes fundamentos para la optimización de costos:

  • Acceso principal con privilegios mínimos: Al conceder únicamente los permisos que un usuario necesita para realizar su trabajo y no más, puede impedir que el personal cree accidentalmente recursos que no está autorizado.
  • Estrategia de etiquetado: Es casi imposible rastrear todos los recursos manualmente. Las etiquetas son también la base para la gestión automatizada de recursos.
  • Recolección y limpieza de basura: Limpiar los recursos no utilizados debe hacerse de manera automatizada y de forma regular aprovechando las etiquetas. Si no tiene herramientas automatizadas en su lugar, empiece a hacerlo manualmente hoy mismo y construya las herramientas con el tiempo.
  • Modelos de precios apropiados: Aproveche las instancias reservadas o considere la utilización del mercado de instancias spot. Esto es especialmente importante para las cargas de trabajo de producción.

Un gobierno de costos más avanzado siempre depende de la automatización. La gestión automatizada de costos es un pilar importante para cualquier organización habilitada para DevOps, especialmente aquellas que operan en la nube con estructuras de precios flexibles.

Esperamos que estos hallazgos le ayuden a comprender mejor los desafíos de las operaciones eficientes en la nube. Con revisiones Well-architected de AWS su equipo obtiene una comprensión más a detalle de cómo crear el ambiente de AWS óptimo para sus necesidades empresariales únicas. Y no sólo Rackspace puede hacer la revisión, nuestros expertos también pueden ayudar a implementar estos hallazgos. Obtenga más información sobre cómo nuestros expertos pueden administrar AWS por usted.

 

 

 

 

LEAVE A REPLY

Please enter your comment!
Please enter your name here