Cuando diseñamos nuestra arquitectura de software, inicialmente nos enfocamos en los requerimientos funcionales. Es decir, que es lo que nuestro sistema debe resolver. Uno de ellos es ¿Qué pasaría si se cayera el servicio? ¿En cuánto tiempo se repondría? y ¿Cómo funciona helppeople junto a AWS?
Pues bien, nosotros a pesar de que trabajamos en la nube, nuestro principal respaldo es AWS, cuya infraestructura está distribuida geográficamente en regiones. Estas regiones se encuentran aisladas unas de otras, tanto de forma geográfica como en software.
Es decir, que si llegase a existir algún desastre natural las regiones están lo suficientemente alejadas y aisladas para no verse afectadas al mismo tiempo y los servicios son desplegados de forma independiente en cada una de estas regiones.
Disponibilidad y recuperación junto a AWS
Un SLA de 99.99% de disponibilidad indica que el sistema que estamos diseñando no deberá superar más de 52.56 minutos fuera de línea en 365 días. O por ejemplo un SLA de 99.99% de durabilidad nos indica que por un giga-byte (GB) de información no deberíamos superar la perdida de información por más de 100 bytes.
En términos de recuperación de desastres tenemos dos métricas principales: Recovery Point Objective u Objetivo de Punto de Recuperación, el cual nos indica cuánto tiempo puede existir en términos de perdida de información.
Por ejemplo, un RPO de una hora indica que si el sistema falló a las 12:00 pm, debemos poder contar con todos los cambios de información generados hasta las 11:00 am.
Es decir, debemos contar con los mecanismos necesarios para capturar ese cambio de información y resguardarlo en una localidad secundaria. El Objetivo de Tiempo de Recuperación o Recovery Time Objective indica cuánto tiempo el sistema puede estar fuera de línea, por ejemplo, si el RTO es 1hr y el sistema falla a las 12:00 pm, el sistema debe contar con su funcionalidad al 100% a la 1:00 pm.
Te puede interesar: Ventajas y usos que le puede brindar una API
Nuestro SLA
A continuación diseñaremos una arquitectura similar utilizando dos o más regiones pero con servicios Serverless:
- AWS Route 53 – Utilizándolo, obtendremos un SLA de 100% para resolución de nombres (DNS).
- Amazon CloudFront – Este nos permite tener un cache cercano a nuestros clientes, cuenta con un SLA de 99.9%, utilizando Origin Fail Over podemos registrar dos orígenes distintos para combinar los SLAs y tener una mejor disponibilidad.
- Amazon Simple Storage Service (S3) – Con ello, podemos hospedar un sitio web estático, este servicio tiene un SLA de 99.9%. Habilitando replicación o otra región podemos incrementar este SLA.
- Amazon API Gateway – Con este servicio podemos hospedar APIs REST y conectarlas a otros servicios, API Gateway nos provee con un SLA de 99.95%.
- AWS Lambda – En este servicio podemos hospedar nuestros microservicios obteniendo un SLA de 99.95 %.
- Amazon RDS – Este servicio nos provee un SLA de 99.99%.
Calculando el SLA combinado de los servicios 99.9% * 99.9% * 99.95% * 99.95% * 99.99% = 99.69% obtenemos un SLA 0.24% por debajo del SLA de la arquitectura tradicional. Es decir, alcanzamos un SLA de 99.999%.
En helppeople nos centramos en ofrecer un servicio de calidad, nuestro respaldo principal es AWS y junto a ellos trabajamos fuertemente para que nunca se caiga el servicio.
Sí te gustaría conocer más datos puntuales sobre nosotros, te invitamos a ver más artículos aquí este blog.