HPE entre los líderes de almacenamiento de Gartner
Conocidas como Computación elástica, las bases de datos sin servidor (Serverless) ofrecen almacenamiento y recuperación de datos escalable.
Por Martín Heller | Original de IDGN
Basados en la nube. Y sin necesidad de aprovisionar CPU o almacenamiento con anticipación… Los servicios de computación en la nube sin servidor comenzaron con AWS Lambda, la cual permite ejecutar código sin aprovisionar ni administrar servidores.
AWS Lambda es un ejemplo de funciones como servicio o FaaS, y otras implementaciones de FaaS siguieron rápidamente en Microsoft Azure y Google Cloud.
Más tarde, los proveedores de la nube comenzaron a ofrecer otros servicios sin servidor.
Serverless era una nueva forma de pensar sobre los servicios en la nube y, en la práctica, las arquitecturas sin servidor a menudo cuestan una fracción del aprovisionamiento de instancias de servidores permanentes para ejecutar las mismas cargas.
Explicando el Serverless
A pesar de lo que su nombre implica, serverless no significa que no se utilicen servidores.
En cambio, significa que no tiene que aprovisionar, administrar o pagar los servidores subyacentes per se.
Cuando llega una solicitud de un servicio sin servidor, el proveedor de la nube asigna una instancia (máquina virtual) o un pod (un conjunto lógico de contenedores, generalmente, administrado por Kubernetes) para manejar la solicitud desde su grupo.
Cuando el código serverless sale, los recursos asignados se devuelven al grupo.
En general, paga por los recursos que usa en función de su capacidad de CPU, asignación de RAM y tiempo activo.
Las funciones y los servicios sin servidor pueden:
- Invocarse entre sí
- Invocar otros servicios
- Y pueden escribir en bases de datos y sistemas de archivos compartidos
Una de las mayores ventajas técnicas de las funciones serverless es su escalabilidad extrema:
- A diferencia de los servidores aprovisionados, que pueden verse abrumados fácilmente por los picos de tráfico
- Se disparan nuevas instancias de funciones sin servidor para cada evento que las necesita
- Y todas las instancias regresan, automáticamente, al grupo cuando ya no son necesarios.
¿Qué sucede cuando una instancia (o pod) del tamaño adecuado no está disponible en el grupo cuando llega una solicitud?
El proveedor de la nube debe crear uno nuevo.
Eso provoca cierta latencia en el manejo de la solicitud.
Si la latencia es un problema para su caso de uso, entonces puede pagar para mantener algunas funciones inicializadas e hiper-listas para responder.
AWS llama a esto Simultaneidad aprovisionar. Otros proveedores de la nube usan nombres diferentes, pero todos confían en mantener algunas instancias precalentadas para reducir la latencia.
Las funciones y servicios sin servidor suelen tener una alta disponibilidad.
Si está utilizando un solo servidor, máquina virtual o contenedor para ejecutar un servicio, la probabilidad de una eventual interrupción debido a una falla en la máquina o el centro de datos es alta.
Los proveedores de la nube generalmente mantienen una capacidad de cómputo redundante para funciones serverless en múltiples zonas de disponibilidad (centros de datos en ubicaciones físicas diferentes pero cercanas) en cada región geográfica de servicio.
Además de las funciones y los servicios sin servidor de los proveedores de la nube, existen muchos marcos y SDK independientes del cloud para crear aplicaciones serverless.
Estos incluyen:
- Kubeless, Pulumi
- OpenFaaS
- OpenWhisk
- Y Serverless Framework
Para entender las Bases de datos sin servidor
Según Jim Walker de Cockroach Labs, una base de datos sin servidor se adhiere a nueve principios básicos:
- Poca o ninguna gestión manual del servidor
- Báscula automática y elástica de aplicaciones / servicios
- Resiliencia incorporada y servicio inherentemente tolerante a fallas
- Siempre disponible y con acceso instantáneo
- Mecanismo de tarificación o facturación en función del consumo
- Sobrevive a cualquier dominio fallido, incluidas las regiones
- Escala geográfica
- Garantías transaccionales
- (Elegancia de SQL relacional)
Los principios del 1 al 5 podrían aplicarse a cualquier servicio sin servidor, pero los principios del 6 al 9 son específicos de las bases de datos SQL globales.
El número 9 parece estar sesgado a favor de las bases de datos SQL distribuidas como CockroachDB, razón por la cual he agregado paréntesis alrededor de ese elemento.
La forma tradicional de conectarse a la mayoría de las bases de datos es establecer una conexión TCP persistente desde el cliente al servidor.
Eso no es una buena opción para las bases de datos serverless, porque configurar una conexión TCP puede llevar mucho tiempo.
Idealmente, el cliente debería conectarse al punto final sin servidor casi al instante (menos de 100 ms) y obtener una respuesta en un segundo para consultas simples.
Algunas bases de datos sin servidor (Amazon Aurora Serverless, por ejemplo) admiten conexiones HTTP (preferiblemente HTTPS) y se encargan de la agrupación de conexiones necesaria tanto para admitir el escalado como para hacer que las conexiones sean casi instantáneas.
Cómo las bases de datos sin servidor pueden ahorrarle dinero
Las bases de datos tradicionales deben dimensionarse para la carga de consultas y la capacidad de almacenamiento máximas esperadas.
Si una base de datos puede escalar hacia arriba y hacia abajo sin la necesidad de una migración de datos, puede ahorrar dinero ajustando la CPU hacia arriba durante los períodos de mucho tráfico y hacia abajo durante los períodos de poco tráfico.
Las bases de datos serverless generalmente no necesitan dimensionarse en absoluto.
No se le cobra por la CPU a menos que envíe una consulta y, en ese momento, obtiene toda la capacidad que necesita su consulta.
Luego se le cobra por la capacidad utilizada multiplicada por el tiempo que la base de datos está activa.
Desafortunadamente, todavía se le cobra por el almacenamiento de datos.
Según Amazon, puede ahorrar hasta un 90 % del costo de su base de datos con Aurora Serverless, en comparación con el costo de aprovisionamiento de capacidad para la carga máxima.
