Pilares del Marco de arquitectura de Azure

Spread the love
  •  
  •  
  •  
  •  
  • 2
  •  
  •  
  •  
  •  
  •  
    2
    Compartidos

Impactos: 5

Pilares del Marco de arquitectura de Azure

  • 10 minutos

La nube ha cambiado la manera en que las organizaciones solucionan sus retos empresariales y en que se dise帽an los sistemas y las aplicaciones. El papel de un arquitecto de soluciones no es solo ofrecer valor empresarial por medio de los requisitos funcionales de la aplicaci贸n. Tambi茅n consiste en garantizar que la soluci贸n se dise帽e de maneras escalables, resistentes, eficientes y seguras.

La arquitectura de la soluci贸n tiene que ver con el planeamiento, el dise帽o, la implementaci贸n y la mejora continua de un sistema tecnol贸gico. La arquitectura de un sistema debe equilibrar y alinear los requisitos empresariales con las capacidades t茅cnicas necesarias para ejecutar esos requisitos. La arquitectura final es un equilibrio de riesgo, costo y capacidad en todo el sistema y sus componentes.

Marco de arquitectura de Azure

El Marco de arquitectura de Azure es un conjunto de principios que orientan a la hora de compilar soluciones de alta calidad en Azure. No existe un enfoque que sirva a todos a la hora de dise帽ar una arquitectura, pero hay algunos conceptos universales que se aplican independientemente de la arquitectura, la tecnolog铆a o el proveedor de nube.

Estos conceptos no son integrales. Pero centrarse en ellos ayuda a compilar una base confiable, segura y flexible para la aplicaci贸n.

El Marco de arquitectura de Azure consta de cinco pilares:

  • Optimizaci贸n de costos
  • Excelencia operativa
  • Eficacia del rendimiento
  • Confiabilidad
  • Seguridad
Ilustraci贸n en la que se muestran los pilares del Marco de arquitectura de Azure

Optimizaci贸n de costos

Se recomienda dise帽ar el entorno en la nube de forma que sea rentable para las operaciones y el desarrollo. Identifique la ineficacia y el desperdicio en el gasto en la nube para garantizar que el dinero se invierta en aquello a lo que se puede sacar m谩s partido.

Ilustraci贸n en la que se muestran una calidad, velocidad y eficacia cada vez mayores al tiempo que los costos se mantienen bajos.

Excelencia operativa

Si se aprovechan los procedimientos de desarrollo modernos, como DevOps, se pueden habilitar ciclos de desarrollo e implementaci贸n m谩s r谩pidos. Debe disponer de una buena arquitectura de supervisi贸n para poder detectar errores y problemas antes de que se produzcan o, como m铆nimo, antes de que los clientes los detecten. La automatizaci贸n es un aspecto clave de este pilar para eliminar la varianza y el error a la vez que se aumenta la agilidad operativa.

Eficacia del rendimiento

Para que una arquitectura funcione bien y sea escalable, debe ajustar adecuadamente la capacidad de los recursos a la demanda. Tradicionalmente, las arquitecturas en la nube logran este equilibrio mediante el escalado din谩mico de aplicaciones en funci贸n de la actividad de la aplicaci贸n. La demanda de servicios cambia, por lo que es importante que la arquitectura pueda ajustarse a ella. Si dise帽a la arquitectura teniendo en cuenta el rendimiento y la escalabilidad, proporciona una excelente experiencia a los clientes y a la vez obtiene rentabilidad.

Ilustraci贸n en la que se muestra c贸mo los recursos de la nube se escalan de forma din谩mica en funci贸n de la demanda, lo que resulta en un uso muy eficiente. Cuando los recursos se implementan en un nivel fijo, el resultado es un uso ineficaz cuando hay poca demanda y escasez durante los per铆odos de alta demanda.

Confiabilidad

El mayor temor de un arquitecto es que la arquitectura quede fuera de servicio y no haya forma de recuperarla. Un entorno en la nube satisfactorio est谩 dise帽ado de manera que se anticipa a los errores en todos los niveles. Parte de la anticipaci贸n a los errores consiste en dise帽ar un sistema que se pueda recuperar tras un error en el plazo de tiempo requerido por las partes interesadas y los clientes.

Ilustraci贸n en la que se muestran dos m谩quinas virtuales en una red virtual. Una de las m谩quinas aparece como err贸nea, mientras que la otra trabaja para atender las solicitudes de los clientes.

Seguridad

Los datos son el elemento m谩s valioso de la superficie t茅cnica de la organizaci贸n. En este pilar, la prioridad es proteger el acceso a la arquitectura mediante la autenticaci贸n y proteger la aplicaci贸n y los datos frente a vulnerabilidades de la red. La integridad de los datos tambi茅n debe protegerse con herramientas como el cifrado.

Debe pensar en la seguridad a lo largo de todo el ciclo de vida de la aplicaci贸n, desde el dise帽o y la implementaci贸n al lanzamiento y las operaciones. La nube proporciona medidas de protecci贸n frente a diversas amenazas, como la intrusi贸n de red y los ataques DDoS. Pero sigue siendo necesario integrar la seguridad en la aplicaci贸n, los procesos y la cultura de la organizaci贸n.

Ilustraci贸n en la que se muestran los tipos de amenazas y ataques de seguridad que podr铆an afectar a los datos en la nube.

Principios generales de dise帽o

Adem谩s de cada uno de estos pilares, hay algunos principios de dise帽o sistem谩ticos que se deben tener en cuenta en la arquitectura.

  • Permitir la evoluci贸n de la arquitectura: ninguna arquitectura es est谩tica. Permita la evoluci贸n de la arquitectura mediante el aprovechamiento de los nuevos servicios, herramientas y tecnolog铆as a medida que est茅n disponibles.
  • Usar los datos para tomar decisiones: recopile datos, anal铆celos y 煤selos para tomar decisiones sobre la arquitectura. Desde los datos de costos hasta el rendimiento o la carga de usuarios, el uso de los datos le orienta para tomar las decisiones adecuadas en el entorno.
  • Formar y habilitar: la tecnolog铆a en la nube evoluciona r谩pidamente. Forme a los equipos de desarrollo, operaciones y negocios para ayudarlos a tomar las decisiones adecuadas y compile soluciones para solucionar problemas empresariales. Documente y comparta la configuraci贸n, las decisiones y los procedimientos recomendados dentro de la organizaci贸n.
  • Automatizar: la automatizaci贸n de actividades manuales reduce los costos operativos, minimiza los errores cometidos en los pasos manuales y proporciona coherencia entre entornos.

Responsabilidad compartida

El paso a la nube presenta un modelo de responsabilidad compartida. En este modelo, el proveedor de nube administra determinados aspectos de la aplicaci贸n y deja al usuario la responsabilidad restante.

En un entorno local, el usuario es responsable de todo. A medida que pasa a una infraestructura como servicio (IaaS), luego a plataforma como servicio (PaaS) y a software como servicio (SaaS), el proveedor de nube asume m谩s parte de esta responsabilidad.

Esta responsabilidad compartida juega un papel en la decisiones de arquitectura, ya que estas pueden tener implicaciones en los costos, la seguridad y las capacidades t茅cnicas y operativas de la aplicaci贸n. Al trasladar estas responsabilidades al proveedor, puede centrarse en aportar valor a la empresa y desentenderse de las actividades que no sean una funci贸n empresarial esencial.

Ilustraci贸n en la que se muestra el nivel de responsabilidades compartidas en cada tipo de modelo de servicio en la nube

Opciones de dise帽o

En una arquitectura ideal, se compilar铆a el entorno de m谩s seguridad, rendimiento, disponibilidad y eficacia posible. Pero al igual que con todo, hay ventajas e inconvenientes.

Crear un entorno con el nivel m谩s alto en todos estos aspectos tiene un costo. Ese costo puede ser en forma de dinero, tiempo necesario para entregar o agilidad operativa. Cada organizaci贸n tiene diferentes prioridades que repercuten en las opciones de dise帽o que se adoptan en cada pilar. Al dise帽ar la arquitectura, es necesario determinar qu茅 ventajas y desventajas son aceptables y cu谩les no.

Al compilar una arquitectura de Azure, hay que tener en cuenta muchas consideraciones. Se recomienda que la arquitectura sea segura, escalable, disponible y recuperable. Para hacerlo posible, tiene que tomar decisiones basadas en el costo, las prioridades de la organizaci贸n y el riesgo.

  •  
    2
    Compartidos
  •  
  •  
  •  
  •  
  • 2
  •  
  •  
  •  
  •