Backends y UX consistentes: ¿Cuáles son las barreras para la adopción?

Serie de artículos

1. ¿Por qué debería importarte?
2. ¿Qué puede ser malo?
3. ¿Cuáles son las barreras para la adopción?
4. ¿Cómo ayudan los nuevos algoritmos?

1. “El teorema CAP dice que es imposible”
2. “Construir una base de datos distribuida fuertemente consistente es demasiado difícil/imposible”
3. “La optimización prematura es la fuente de todos los males”
4. “Es difícil programar en una base de datos distribuida”
5. Trabajar con una base de datos eventualmente consistente es como…
6. Conclusión

Hay muy pocos escenarios en los que una base de datos eventualmente consistente sea preferible a una base de datos fuertemente consistente. Además, en un escenario de aplicación multirregional donde es necesario escalar, elija una base de datos no distribuida o una base de datos eventualmente consistente es aún más cuestionable. Entonces, ¿qué motiva a los ingenieros a ignorar las bases de datos distribuidas fuertemente consistentes? Hemos visto muchas razones, pero la mayoría de ellas están impulsadas por suposiciones erróneas.

“El teorema CAP dice que es imposible”

Como explicamos en la Parte 1 de esta serie, el teorema CAP es ampliamente aceptado pero a menudo se malinterpreta. Cuando muchas personas malinterpretan un teorema conocido, éste deja una huella. En este caso, muchos ingenieros todavía creen que la coherencia final es un mal necesario.

“Construir una base de datos distribuida fuertemente consistente es demasiado difícil/imposible”

Poco a poco se está comprendiendo que no se debe sacrificar la coherencia, pero muchas bases de datos todavía ponen la coherencia en segundo lugar. ¿Por qué es eso? Algunas bases de datos populares ofrecen opciones que ofrecen una mayor coherencia, pero sólo a costa de latencias potencialmente muy altas. Sus mensajes de ventas podrían incluso afirmar que brindar coherencia con latencias bajas en una base de datos distribuida en varias regiones es increíblemente difícil o incluso imposible, y la audiencia de desarrolladores tiene recuerdos destacados de haber experimentado latencias muy pobres en bases de datos que no fueron creadas para lograr coherencia. Combinados, refuerzan la idea errónea de que es imposible una consistencia fuerte en una base de datos distribuida con latencias relativamente bajas.

“La optimización prematura es la fuente de todos los males”

Muchos ingenieros construyen según el principio “La optimización prematura es la raíz de todos los males” (Donald Knuth), pero esa afirmación sólo debe aplicarse a pequeñas ineficiencias. Construir su startup sobre una base de datos escalable distribuida fuertemente consistente puede parecer una optimización prematura, porque inicialmente, su aplicación no requiere escala y puede que no requiera distribución. Sin embargo, aquí no estamos hablando de pequeñas ineficiencias. El requisito de escalar o distribuir puede surgir de la noche a la mañana, cuando su aplicación se vuelva popular. En ese punto, sus usuarios tienen una experiencia terrible y usted se enfrenta a un desafío sustancial para cambiar su infraestructura y código.

“Es difícil programar en una base de datos distribuida”

Esto solía tener algo de verdad, ya que las bases de datos distribuidas eran nuevas y muchas tenían graves limitaciones. No permitían uniones, solo permitían el almacenamiento de valores clave o requerían que usted consultara sus datos de acuerdo con claves de fragmentación predefinidas, que ya no podía cambiar. Hoy en día, contamos con bases de datos distribuidas que tienen modelos flexibles y brindan la flexibilidad a la que está acostumbrado con las bases de datos tradicionales. Este punto está muy relacionado con el punto anterior, que ignora que hoy en día, comenzar a programar contra una base de datos distribuida fuertemente consistente es igual de fácil y probablemente más fácil a largo plazo en comparación con una base de datos tradicional. Si es igual de fácil, ¿por qué no optimizar desde el principio?

Trabajar con una base de datos eventualmente consistente es como…

Las bases de datos distribuidas suelen ser creadas por personas que han experimentado problemas con la coherencia final. Por ejemplo, FaunaDB fue creado por antiguos ingenieros de Twitter después de haber experimentado lo difícil que es construir un sistema escalable sobre las bases de datos eventualmente consistentes que eran populares en esa época, como Cassandra. Estos problemas suelen manifestarse cuando una nueva empresa comienza a crecer, por lo que muchos ingenieros más jóvenes nunca los han experimentado de primera mano.

A veces, las cosas dolorosas pueden enseñarnos lecciones que no creíamos que necesitáramos saber.

—Amy Poehler

Discutir los peligros de una eventual coherencia generalmente lleva al argumento de “funciona para mí” por parte de ingenieros que simplemente no han experimentado ningún problema todavía. Dado que esto suele llevar meses (o años, si tiene suerte), veamos una analogía.

…andar en bicicleta con las ruedas flojas.

Hace un tiempo, mi mejor amigo estuvo a punto de faltar a una cita, así que le presté mi bicicleta. Yo estaba feliz de haber ayudado, él estaba feliz y todo salió bien. Esa felicidad rápidamente se convirtió en dolor cuando intenté saltar la bicicleta a una acera. Verás… había retocado la bicicleta ese mismo día y me había olvidado de apretar la rueda delantera. Regresó con un enorme hematoma morado. Juegos, Tecnologia e Internet

El ejemplo de la bicicleta es muy similar a trabajar con una base de datos que no es muy consistente. Todo irá bien hasta que intentes levantar la rueda de la bicicleta (o en otras palabras, hasta que tu empresa despegue y comience a crecer).

En el momento en que su aplicación necesita escalar, normalmente lo hace mediante la replicación de servicios. Una vez que la base de datos se convierte en el cuello de botella, puede replicar su base de datos tradicional o pasar a una base de datos distribuida. Desafortunadamente, en este momento, las funciones de su aplicación pueden fallar cuando comienza a replicar su base de datos. Hasta ahora, no habías notado estos problemas ya que la base de datos se ejecutaba en un solo nodo. En ese momento, podrían suceder dos cosas:

• Situación 1, construir a su alrededor/arreglarlo: los desarrolladores pronto se dan cuenta de que la base de datos que están “utilizando” no es confiable para las características que han creado o están intentando construir. Sus opciones se reducen a cancelar las funciones, simplificarlas o cambiar la base de datos.
• Situación 2, falla épica: los desarrolladores no fueron bien informados por el proveedor (yo era un pésimo vendedor de bicicletas para mi amigo) sobre los riesgos, y ahora carecen de la información para comprender las implicaciones muy sutiles de lo que está sucediendo. Esto no se debe necesariamente a una falta de capacidad del ingeniero. Los estándares mal definidos y el marketing optimista hacen un gran trabajo al ofrecer las garantías de coherencia de las diferentes bases de datos.

Los desarrolladores que terminan en la primera situación a menudo ya tienen experiencia en el manejo de sistemas eventualmente consistentes. Ahora aceptarán que no pueden ofrecer algunas funciones o crearán una capa compleja y difícil de mantener encima de la base de datos para obtener lo que necesitan. En esencia, intenta desarrollar una base de datos fuertemente consistente además de otra eventualmente consistente. Es una pena, ya que otras personas han diseñado bases de datos distribuidas desde cero que no sólo serán más eficientes, sino que no requerirán mantenimiento por parte de su equipo de desarrollo.

…andar en bicicleta invisible con ruedas sueltas.

Los desarrolladores que se encuentran en la segunda situación van en una bicicleta parcialmente invisible. No se dan cuenta de que la rueda está suelta, no ven que la rueda se ha desprendido y, una vez que miran hacia arriba después de caer, todavía ven una bicicleta completamente intacta.

En el momento en que las cosas van mal, la complejidad para resolver estos errores es alta por varias razones:

• Determine si se trata de un eventual error de coherencia . El problema puede ser un error de la aplicación o un error causado por una mala comprensión de las garantías de la base de datos subyacente. Para estar seguros, debemos investigar la lógica de la aplicación y, en caso de que la lógica de la aplicación sea sólida en un entorno no distribuido, el ingeniero debe tener el instinto para evaluar si esta situación podría surgir debido a una eventual coherencia.
• La causa ha desaparecido. En segundo lugar, dado que la base de datos eventualmente se vuelve consistente, la causa del problema probablemente haya desaparecido (la rueda se vuelve a colocar mágicamente en la bicicleta y todo lo que ves es una bicicleta impecable).
• ¡Arreglalo! Una vez que se determina el problema, puede encontrar una manera de solucionarlo, intentar crear una capa encima de la base de datos (hola latencia y otros errores potenciales), eliminar las funciones o cambiar la base de datos. La última opción a veces se percibe como fácil. Sin embargo, incluso las diferencias más sutiles entre las bases de datos hacen que esta sea una tarea muy desafiante. En el momento en que su solicitud despega, ya tiene las manos ocupadas. ¡Este no es el momento en el que quieres intercambiar bases de datos!

…andar en una bicicleta invisible con las ruedas sueltas y un grupo de personas paradas sobre tus hombros.

El ejemplo de la bicicleta invisible sigue siendo demasiado indulgente. En realidad, es probable que otros dependan de su aplicación. Básicamente, estás montando una bicicleta invisible mientras otros (tus clientes) están parados sobre tus hombros.

No sólo te caerás, sino que ellos caerán contigo y aterrizarán encima de ti, de forma pesada y dolorosa. Es posible que ni siquiera sobrevivas a la caída en ese momento; en otras palabras, es posible que su empresa no sobreviva a la tormenta de comentarios negativos de sus clientes.

¿La moraleja de la historia? Si hubiera elegido una base de datos fuertemente (en lugar de eventualmente) consistente desde el principio, no tendría que considerar pasar por un proyecto complejo y que requiere muchos recursos, como migrar su base de datos en un punto en el que sus clientes ya están frustrados.

Conclusión

La elección de una base de datos eventualmente consistente para escalar se justificó hace unos años cuando simplemente no había otra opción. Sin embargo, ahora contamos con bases de datos modernas que pueden escalar de manera eficiente sin sacrificar la coherencia o el rendimiento de los datos. . Además, estas bases de datos modernas también incluyen otras características increíbles que van más allá de la coherencia, como facilidad de uso, modelos de precios sin servidor, autenticación integrada, temporalidad, GraphQL nativo y más. ¡Con una base de datos moderna, puedes escalar sin abrir la caja de Pandora!

Y, si después de leer esta serie de artículos, aún decide no utilizar una base de datos distribuida fuertemente consistente, al menos asegúrese de apretar las ruedas (en otras palabras, lea y comprenda las garantías de coherencia de las diferentes bases de datos).

Serie de artículos

1. ¿Por qué debería importarte?
2. ¿Qué puede ser malo?
3. ¿Cuáles son las barreras para la adopción?
4. ¿Cómo ayudan los nuevos algoritmos?

Tal vez te puede interesar:

1. La innovación no puede mantener la Web rápida
2. Rendimiento web ultrarrápido
3. Tabla de contenidos fijos con estados activos de desplazamiento
4. “cambiar tamaño: ninguno;” en áreas de texto es una mala experiencia de usuario

Backends y UX consistentes: ¿Cuáles son las barreras para la adopción?

“El teorema CAP dice que es imposible”“Construir una base de datos distribuida fuertemente consistente es demasiado difícil/imposible”“La optimizaci

programar

es

https://aprendeprogramando.es/static/images/programar-backends-y-ux-consistentes-cuales-son-las-barreras-para-la-adopcionja-1331-0.jpg

2024-09-26

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente