{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dicotom\u00eda de datos: repensando la relaci\u00f3n con los datos y los servicios","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola a todos! Tenemos excelentes noticias, en junio OTUS lanza nuevamente un curso \u00abArquitecto de Software\u00bb<\/a><\/noindex>, por lo que tradicionalmente compartimos con ustedes material \u00fatil.<\/b><\/i><\/p>\n

\"Dicotom\u00eda
\n
\n Si te has encontrado con toda esta historia sobre microservicios sin ning\u00fan contexto, es comprensible que la encuentres un poco extra\u00f1a. Dividir una aplicaci\u00f3n en fragmentos interconectados a trav\u00e9s de la red necesariamente implica a\u00f1adir modos complejos de tolerancia a fallos en el sistema distribuido resultante. <\/p>\n

A pesar de que este enfoque implica dividirse en numerosos servicios independientes, el objetivo final es mucho m\u00e1s grande que simplemente hacer que estos servicios funcionen en diferentes m\u00e1quinas. Se trata de interactuar con el mundo circundante, que en su esencia tambi\u00e9n es distribuido. No en un sentido t\u00e9cnico, sino m\u00e1s bien en el de un ecosistema que consiste en muchas personas, equipos y programas, y cada una de estas partes de una u otra forma debe cumplir su funci\u00f3n.<\/a><\/noindex><\/p>\n

Las empresas, por ejemplo, se componen de un conjunto de sistemas distribuidos que en conjunto contribuyen a alcanzar un objetivo. Ignoramos este hecho durante d\u00e9cadas, tratando de lograr la integraci\u00f3n, transfiriendo archivos por FTP o utilizando herramientas de integraci\u00f3n empresarial, mientras nos enfoc\u00e1bamos en nuestros propios objetivos individuales. Pero con la llegada de los servicios, todo cambi\u00f3. Los servicios nos ayudaron a ver m\u00e1s all\u00e1 del horizonte y a observar un mundo de programas interdependientes que trabajan juntos. Sin embargo, para operar con \u00e9xito, es necesario entender y dise\u00f1ar dos mundos fundamentalmente diferentes: el mundo exterior, donde existimos en un ecosistema de muchos otros servicios, y nuestro propio mundo interno, donde gobernamos en soledad.<\/p>\n

\"Dicotom\u00eda
\n
\n Este mundo distribuido es diferente del que hemos crecido y al que estamos acostumbrados. Los principios de construcci\u00f3n de una arquitectura monol\u00edtica tradicional no soportan ning\u00fan tipo de cr\u00edtica. Por lo tanto, entender correctamente tales sistemas es algo m\u00e1s que crear un esquema atractivo en una pizarra blanca o una impresionante prueba de concepto. Se trata de hacer que dicho sistema funcione correctamente durante un largo periodo. Afortunadamente, los servicios han existido durante bastante tiempo, aunque se presentan de diferentes maneras. Lecciones de SOA<\/a><\/noindex> siguen siendo relevantes, incluso condimentados con Docker, Kubernetes y ligeramente desgastados por barbas hipster. <\/p>\n

As\u00ed que hoy veremos c\u00f3mo han cambiado las reglas, por qu\u00e9 necesitamos repensar nuestro enfoque hacia los servicios y los datos que se transmiten entre ellos, y por qu\u00e9 necesitaremos herramientas completamente diferentes para ello.<\/p>\n

La encapsulaci\u00f3n no siempre ser\u00e1 tu amiga<\/h3>\n

\n Los microservicios pueden operar de manera independiente entre s\u00ed. Esta propiedad les confiere su mayor valor. Esta misma caracter\u00edstica permite que los servicios se escalen y crezcan. No tanto en el sentido de escalar a cuatrillones de usuarios o petabytes de datos (aunque aqu\u00ed tambi\u00e9n pueden ayudar), sino en t\u00e9rminos de escalar desde la perspectiva de las personas, a medida que los equipos y las organizaciones crecen continuamente.<\/p>\n

\"Dicotom\u00eda
\n
\nSin embargo, la independencia es un arma de doble filo. Es decir, un servicio por s\u00ed solo puede funcionar f\u00e1cilmente y sin complicaciones. Pero si dentro de un servicio se implementa una funci\u00f3n que requiere la interacci\u00f3n con otro servicio, al final tenemos que hacer cambios en ambos servicios casi simult\u00e1neamente. En un monolito, esto es f\u00e1cil, simplemente haces el cambio y lo env\u00edas a producci\u00f3n, pero en el caso de la sincronizaci\u00f3n de servicios independientes, habr\u00e1 m\u00e1s problemas. La coordinaci\u00f3n entre equipos y ciclos de lanzamiento desaf\u00eda la flexibilidad.<\/p>\n

\"Dicotom\u00eda
\n
\nEn el enfoque est\u00e1ndar, se intenta simplemente evitar dolorosos cambios transversales, separando claramente la funcionalidad entre los servicios. Un servicio de entrada \u00fanica al sistema puede ser un buen ejemplo aqu\u00ed. Tiene un rol claramente definido que lo diferencia de otros servicios. Este claro desglose significa que, en un mundo de requisitos cambiantes para los servicios que lo rodean, es poco probable que el servicio de entrada \u00fanica al sistema cambie. Existe dentro de un contexto estrictamente limitado.<\/p>\n

\"Dicotom\u00eda
\n
\n El problema radica en que en el mundo real, los servicios de negocios no pueden mantener una separaci\u00f3n de roles perfectamente limpia de manera constante. Por ejemplo, esos mismos servicios de negocios operan en gran medida con datos que provienen de otros servicios similares. Si te dedicas al comercio minorista en l\u00ednea, el procesamiento de pedidos, el cat\u00e1logo de productos o la informaci\u00f3n de los usuarios se convertir\u00e1 en un requisito para muchos de tus servicios. Cada uno de estos servicios necesitar\u00e1 acceso a esos datos para funcionar. <\/p>\n

\"Dicotom\u00eda
\nLa mayor\u00eda de los servicios de negocios utilizan el mismo flujo de datos, por lo que su funcionamiento est\u00e1 invariablemente entrelazado.<\/i><\/p>\n

As\u00ed llegamos a un punto importante sobre el cual vale la pena hablar. Mientras que los servicios funcionan bien para los componentes de infraestructura que operan en gran medida de manera aislada, la mayor\u00eda de los servicios de negocios tienden a estar entrelazados de una manera mucho m\u00e1s cercana.<\/p>\n

Dicotom\u00eda de datos<\/h3>\n

\n Los enfoques centrados en servicios pueden que ya existan, pero a\u00fan hay poca informaci\u00f3n sobre c\u00f3mo intercambiar grandes vol\u00famenes de datos entre servicios.<\/p>\n

El problema principal es que los datos y los servicios son inseparables. Por un lado, la encapsulaci\u00f3n nos insta a ocultar los datos para que los servicios puedan separarse unos de otros, facilitando su crecimiento y cambios futuros. Por el otro lado, necesitamos tener la capacidad de compartir y controlar libremente los datos comunes, al igual que con cualquier otro. Se trata de poder comenzar a trabajar de inmediato, tan libremente como en cualquier otro sistema de informaci\u00f3n.<\/p>\n

Sin embargo, los sistemas de informaci\u00f3n tienen poco que ver con la encapsulaci\u00f3n. De hecho, es todo lo contrario. Las bases de datos hacen todo lo posible para proporcionar acceso a los datos almacenados en ellas. Vienen equipadas con una poderosa interfaz declarativa que permite modificar los datos como necesites. Esta funcionalidad es importante en la fase de investigaci\u00f3n preliminar, pero no para gestionar la creciente complejidad de un servicio en constante evoluci\u00f3n.<\/p>\n

\"Dicotom\u00eda
\n
\n Y aqu\u00ed surge la dilema. Una contradicci\u00f3n. Una dicotom\u00eda. Los sistemas de informaci\u00f3n se tratan de proporcionar datos, mientras que los servicios se centran en ocultar.<\/p>\n

Estas dos fuerzas son fundamentales. Se encuentran en la base de gran parte de nuestro trabajo, luchando constantemente por la supremac\u00eda en los sistemas que creamos.<\/p>\n

A medida que los sistemas de servicios crecen y evolucionan, vemos diversas manifestaciones de las consecuencias de la dicotom\u00eda de los datos. O bien la interfaz del servicio crecer\u00e1, ofreciendo un conjunto cada vez m\u00e1s amplio de funciones y comenzar\u00e1 a parecerse a una extra\u00f1a base de datos casera, o nos enfrentaremos a la frustraci\u00f3n y implementaremos alg\u00fan m\u00e9todo para extraer o mover grandes conjuntos de datos de un servicio a otro.<\/p>\n

\"Dicotom\u00eda
\n
\n A su vez, crear algo que se asemeje a una extra\u00f1a base de datos casera llevar\u00e1 a una serie de problemas. No entraremos en detalles sobre lo que es peligroso el shared database<\/i>, solo diremos que representa considerables dificultades de ingenier\u00eda y operacionales costosas para la empresa que intenta utilizarlo.<\/a><\/noindex> Peor a\u00fan, los vol\u00famenes de datos multiplican los problemas con los l\u00edmites de los servicios. Cuantos m\u00e1s datos compartidos haya dentro del servicio, m\u00e1s complicada se volver\u00e1 la interfaz y m\u00e1s dif\u00edcil ser\u00e1 combinar conjuntos de datos provenientes de diferentes servicios.<\/p>\n

Un enfoque alternativo de extracci\u00f3n y movimiento de grandes conjuntos de datos tambi\u00e9n tiene sus problemas. El enfoque com\u00fan a este respecto parece ser simplemente extraer y almacenar un conjunto de datos completo, y luego mantenerlo localmente en cada servicio consumidor.<\/p>\n

El problema es que diferentes servicios interpretan los datos que consumen de manera diferente. Estos datos est\u00e1n siempre a mano. Se modifican y procesan localmente. Con bastante rapidez dejan de tener algo en com\u00fan con los datos en la fuente.<\/p>\n

\"Dicotom\u00eda
\n
\n Cuanto m\u00e1s mutables sean las copias, m\u00e1s diferir\u00e1n los datos con el tiempo.<\/p>\n

\"Dicotom\u00eda
\n Para colmo, esos datos son dif\u00edciles de corregir en retrospectiva (<\/i><\/p>\n

y aqu\u00ed es donde realmente puede ayudar). De hecho, algunos de los problemas tecnol\u00f3gicos intratables que enfrenta el negocio surgen de datos heterog\u00e9neos, que se multiplican de una aplicaci\u00f3n a otra.MDM<\/a><\/noindex> Para encontrar una soluci\u00f3n a este problema de los datos compartidos, debemos pensar de manera diferente. Deben convertirse en objetos de primera clase en las arquitecturas que construimos.<\/p>\n

Pat Helland P\u00e9t Helland<\/a><\/noindex> denomina estos datos como \u00abexternos\u00bb, y esta es una caracter\u00edstica muy importante. Necesitamos encapsulaci\u00f3n para no revelar el funcionamiento interno del servicio, pero debemos facilitar el acceso de los servicios a los datos compartidos para que puedan realizar su trabajo correctamente.<\/p>\n

\"Dicotom\u00eda
\n
\n El problema es que ninguno de los enfoques actuales es relevante, ya que ni las interfaces de servicio, ni la mensajer\u00eda, ni las bases de datos compartidas ofrecen una buena soluci\u00f3n para trabajar con datos externos. Las interfaces de servicio son poco adecuadas para el intercambio de datos a cualquier escala. La mensajer\u00eda mueve los datos, pero no conserva su historial, por lo tanto, los datos se deterioran con el tiempo. Las bases de datos compartidas se concentran demasiado en un solo punto, lo que limita el progreso. Inequ\u00edvocamente nos quedamos atrapados en un ciclo de insolvencia de datos:<\/p>\n

\"Dicotom\u00eda
\n Ciclo de insolvencia de datos<\/i><\/p>\n

Flujos: un enfoque descentralizado para datos y servicios<\/h3>\n

\n En ideal, necesitamos cambiar el enfoque sobre c\u00f3mo los servicios trabajan con datos comunes. En este momento, cualquier enfoque enfrenta la dicotom\u00eda mencionada anteriormente, ya que no hay ninguna varita m\u00e1gica que se pueda esparcir generosamente para hacer desaparecer el problema. Sin embargo, podemos repensar el problema y llegar a un compromiso.<\/p>\n

Este compromiso implica cierto grado de centralizaci\u00f3n. Podemos aprovechar el mecanismo de registros distribuidos, ya que proporciona flujos escalables y fiables. Ahora necesitamos que los servicios puedan unirse y trabajar con estos flujos comunes, sin embargo, queremos evitar servicios centralizados complejos que realicen dicho procesamiento. Por lo tanto, la mejor opci\u00f3n es integrar el procesamiento de flujos en cada servicio consumidor. As\u00ed, los servicios podr\u00e1n combinar conjuntos de datos de diferentes fuentes y trabajar con ellos seg\u00fan lo necesiten.<\/p>\n

Una de las formas de lograr este enfoque es utilizando una plataforma de streaming. Hay muchas opciones, pero hoy nos enfocaremos en Kafka, ya que su procesamiento de flujos con estado permite abordar eficazmente el problema planteado.<\/p>\n

\"Dicotom\u00eda
\n
\n La utilizaci\u00f3n de un mecanismo de registro distribuido nos permite seguir un camino establecido y usar mensajer\u00eda para trabajar con arquitectura orientada a eventos<\/a><\/noindex>. Se considera que este enfoque proporciona una mejor escalabilidad y separaci\u00f3n que el mecanismo de \"solicitud-respuesta\", ya que otorga el control del flujo al receptor y no al remitente. Sin embargo, todo tiene un precio en esta vida, y aqu\u00ed necesitar\u00e1s un broker. Pero para sistemas grandes, esta compensaci\u00f3n vale la pena (a diferencia de tus aplicaciones web promedio).<\/p>\n

Si el registro distribuido es gestionado por un broker en lugar de un sistema de mensajer\u00eda tradicional, se pueden aprovechar caracter\u00edsticas adicionales. El transporte puede escalar linealmente casi tan bien como un sistema de archivos distribuido. Los datos pueden almacenarse en logs durante un per\u00edodo significativo, por lo que no solo obtenemos mensajer\u00eda, sino tambi\u00e9n un almacenamiento de informaci\u00f3n. Almacenamiento escalable sin miedo a obtener un estado compartido mutable.<\/p>\n

Luego, se puede utilizar un mecanismo de procesamiento de flujo con estado (stateful stream processing) para agregar herramientas de base de datos declarativas a los servicios consumidores. Esta es una idea muy importante. Mientras los datos se almacenan en flujos compartidos, a los cuales todos los servicios pueden acceder, la combinaci\u00f3n y procesamiento que realiza el servicio son privados. Est\u00e1n aislados dentro de un contexto estrictamente limitado.<\/p>\n

\"Dicotom\u00eda
\n Elimina la dicotom\u00eda de datos separando el flujo de estados inmutables. Luego, agrega esta funci\u00f3n a cada servicio a trav\u00e9s del procesamiento de flujo con estado.<\/i><\/p>\n

De este modo, si tu servicio necesita trabajar con pedidos, cat\u00e1logo de productos, almac\u00e9n, tendr\u00e1 acceso completo: solo t\u00fa decidir\u00e1s qu\u00e9 datos combinar, d\u00f3nde procesarlos y c\u00f3mo deben cambiar con el tiempo. A pesar de que los datos son compartidos, la operaci\u00f3n sobre ellos es completamente descentralizada. Se realiza dentro de cada servicio, en un mundo donde todo sigue tus reglas.<\/p>\n

\"Dicotom\u00eda
\nComparte datos de manera que no se comprometa su integridad. Encapsula la funci\u00f3n, no la fuente, en cada servicio que la necesite.<\/i><\/p>\n

A veces es necesario mover datos masivamente. En ocasiones, el servicio requiere un conjunto hist\u00f3rico local de datos en el motor de base de datos seleccionado. La clave es que se puede garantizar que, si es necesario, una copia puede ser restaurada desde la fuente mediante la utilizaci\u00f3n del mecanismo de registro distribuido. Los conectores en Kafka manejan esta tarea de manera excelente.<\/p>\n

As\u00ed que el enfoque que hemos revisado hoy tiene varias ventajas:<\/p>\n