¿Por qué las bases de datos se exponen como API?

Una aplicación no vale mucho hasta que se pone en producción. Para los desarrolladores, llegar a este punto rápidamente significa un fácil acceso a los datos que necesitan construir sin tener que preocuparse por los detalles de creación, administración y mantenimiento de las bases de datos.

Las API se han convertido en el estándar de facto para conectar aplicaciones a bases de datos, pero no siempre fue así. Aquí discutiremos lo que ha cambiado en el mundo del software para elevar la importancia de exponer las bases de datos como API. También hablaremos de Stargate, el proyecto de código abierto que simplifica la forma en que los desarrolladores pueden trabajar con estas API (recientemente se lanzó la última versión de Stargate, que incluye mejoras en escalabilidad y flexibilidad).

Cómo creamos software que utiliza bases de datos

Los administradores de bases de datos (DBA) solían ser los que estaban a cargo de las consultas, ya que se requería un experto en bases de datos para diseñar la forma en que los desarrolladores interactuaban con los datos. Pero hasta hace poco, se esperaba que los desarrolladores supieran mucho sobre la interacción con las bases de datos, incluso si no eran expertos en SQL, consultas o modelos de datos.

Era un desarrollador competente en la década de 1990, pero las bases de datos me intimidaban. Me tomó años sentirme cómodo trabajando con SQL. El simple hecho de ofrecer un "parecido a SQL" tampoco es suficiente. Tome CQL (Lenguaje de consulta de Cassandra), que se desarrolló para ofrecer un lenguaje de consulta similar a SQL para comunicarse con Apache Cassandra. La idea era proporcionar una abstracción para comunicarse con Cassandra, facilitando la tarea para aquellos que se sienten cómodos con las bases de datos relacionales.

Pero en el mundo de las redes, tenemos nuevos conceptos de identidad, permisos y seguridad que están completamente separados del lenguaje de consulta. La noción de un controlador que simplemente se comunica en un protocolo binario no funciona bien en la nube. HTTP es el protocolo de capa de aplicación fundamental para la nube, pero la mayoría de las API basadas en HTTP son lentas. Una opción de baja latencia, como gRPC, es fundamental para las comunicaciones en tiempo real en sistemas distribuidos.

Cómo el software habla con el software

La forma estándar que los clientes o servidores de aplicaciones solían comunicarse con las bases de datos involucraba controladores que se ejecutaban dentro del centro de datos. Ahora todo se ejecuta en la nube, pero los desarrolladores escriben en una amplia gama de idiomas. Se puede usar JavaScript , Python o cualquiera de una gran cantidad de marcos diferentes, por lo que los medios por los cuales el software accede a los datos deben abstraerse de maneras diferentes a los controladores de bases de datos clásicos, utilizando API (JSON, gRPC, GraphQL o Document) que los desarrolladores se sienten cómodos.

La forma moderna en que el software se comunica con el software es una API; es la capa de abstracción que oculta las complejidades de la base de datos.

La naturaleza de los datos

Los datos solían ser mucho más uniformes; encaja perfectamente en las filas y columnas de las tablas de la base de datos. Pero la dinámica de los datos ha cambiado. Los datos se mueven desde las representaciones en memoria de vuelta a la base de datos sin problemas y sin mucho software que intervenga. Y estamos tratando con nuevos tipos de formatos de datos que son mucho más robustos que los primitivos de datos con los que la gente solía lidiar, o la media docena de tipos de datos que SQL podría manejar.

API de base de datos

Las API son la forma en que los desarrolladores de hoy trabajan con las bases de datos. Aquí hay un resumen de por qué:

• HTTP es el protocolo de red de la nube. Muchos desarrolladores ya están familiarizados con las API web y el uso de HTTP facilita mucho la implementación de aplicaciones en la nube.
• No hay necesidad de instalar y ejecutar bases de datos localmente. Instalar una base de datos localmente requiere esfuerzo y crea otro entorno en el que se deben depurar los problemas.

Una puerta de entrada a la simplicidad, la escalabilidad y la extensibilidad

Una puerta de enlace de API de datos es una pieza de infraestructura de software que brinda acceso a datos a través de API de varios estilos, incluidos REST, gRPC y otros. La puerta de enlace abstrae los detalles del almacenamiento y la recuperación de datos utilizando uno o más almacenes persistentes. Esto permite a los desarrolladores de aplicaciones centrarse en escribir servicios comerciales que accedan a los datos a través de API fáciles de usar en lugar de tener que aprender las complejidades del lenguaje de consulta de una base de datos.

Stargate es una puerta de enlace API de datos de código abierto que se encuentra entre una aplicación y las bases de datos que necesita consultar. Se presentó por primera vez en septiembre de 2020 y Apache Cassandra fue elegida como la primera base de datos en parte porque resuelve los desafíos de disponibilidad y escalabilidad más difíciles del mundo.

Una puerta de enlace API de datos es una forma poderosa de permitir que sus desarrolladores trabajen en marcos y estructuras con los que están familiarizados, proporcionando una gama de compensaciones entre productividad y rendimiento. Stargate ofrece el poder de Cassandra al presentar REST, Document y GraphQL como API simples. También ofrece un conjunto de bibliotecas gRPC para hacer CQL sobre gRPC como una alternativa más fácil, liviana y más compatible con la nube a los controladores nativos para CQL sin sacrificar el rendimiento.

Este año, el equipo de ingeniería de Stargate en DataStax ha estado trabajando en una actualización arquitectónica de Stargate. Stargate v2, como lo llamamos, se lanzó en octubre de 2022 . En base a los comentarios de la comunidad de desarrolladores de Stargate , en Stargate v2 hemos realizado algunas actualizaciones importantes que facilitan el uso de los desarrolladores y la contribución de la comunidad al proyecto. Lo que es más importante, la API gRPC de alto rendimiento de Stargate v2 puede ofrecer una velocidad equivalente a los controladores de base de datos nativos. Esto permite a los desarrolladores utilizar protocolos de red aptos para la nube, como HTTP, para conectar aplicaciones y bases de datos, sin pérdida de rendimiento en la red.

Extensibles y Adaptables

Ninguna estrategia de arriba hacia abajo o sabor de API del mes sobrevivió al contacto con un gran grupo de desarrolladores. Un objetivo clave de Stargate v2 es permitir que la comunidad agregue nuevos servicios de API de forma rápida y sencilla al hacer que la implementación en sí sea más fácil de entender, depurar, mejorar y ampliar.

Agregar un nuevo servicio API ahora es mucho más simple, y el código fuente para los servicios REST, GraphQL y Document API brindan a los desarrolladores un código de ejemplo instructivo que muestra cómo debería verse un servicio API terminado.

El nivel de API debe ser multimodelo; los desarrolladores quieren encontrar su API preferida fácilmente disponible, en lugar de verse obligados a adaptar su trabajo de desarrollo a una API diferente. Y si la API no está disponible, el nivel de API debería poder adaptarse.

Nativo de la nube

Lanzar código frente a una base de datos se ha hecho durante años. Pero en realidad construir una plataforma que pueda escalar con su base de datos, y que sea adaptable y confiable, es algo nuevo. Si está usando Cassandra, probablemente ya sea una aplicación de alto crecimiento, o aspire a convertirse en una. Entonces, todo lo que se encuentra frente a él debe facilitar un entorno de alto crecimiento. Stargate comenzó su vida como una bifurcación del código coordinador de Cassandra, por lo que hereda gran parte de la confiabilidad y disponibilidad por las que Cassandra es bien conocida.

El nivel de API tiene que ser totalmente capaz de operar a escala, por lo que otro objetivo de Stargate v2 era hacerlo más compatible con la nube. Varios cambios para facilitar la escalabilidad de Stargate incluyen:

• Stargate ahora está completamente en contenedores y se ejecuta dentro de los pods de Kubernetes, lo que brinda a los operadores más control sobre cómo se pueden escalar las cargas de trabajo.

• Los servicios de API se han movido del nodo monolítico de Stargate a microservicios separados, lo que permitirá que cada API se escale de forma independiente.

• Los nodos de almacenamiento y los nodos coordinadores se pueden implementar y escalar de forma independiente, lo que también brinda a los operadores más control sobre cómo se pueden escalar las cargas de trabajo.

  
  

Si una carga de trabajo requiere un uso intensivo de consultas o almacenamiento, se puede ajustar sin tener que escalar todo el clúster como un todo.

Desarrollando con algo familiar

Los servicios de datos en la nube se han convertido en el tema dominante en el mundo de la tecnología, por lo que no sorprende que los desarrolladores tiendan a pensar en términos de abstracciones de datos como JSON en lugar de modismos exclusivos de bases de datos particulares. Stargate es la culminación de mucho trabajo duro para encontrar a los desarrolladores donde están, permitiéndoles trabajar en marcos y estructuras con los que están familiarizados.

Obtenga más información sobre Stargate aquí .

Por Ed Anuff.