Si una arquitectura de microservicio necesita una base de datos separada por microservicio, entonces es demasiado costosa e inmanejable. ¿Por qué lo necesitamos?

Leí sobre microservicios y me parece ilógico crear una base de datos separada por servicio solo para lograr el aislamiento. Puedo lograr lo mismo usando solo servicios web y una sola base de datos. ¿Por qué lo necesitamos? Lo que separa la base de datos está fuera de discusión. ¿O estoy completamente equivocado? ¿Me puede guiar en esto?

¿Por qué lo necesitamos?

Usted no

Crear una base de datos separada para cada servicio ayuda a reforzar los límites del dominio, pero es solo un enfoque. No hay nada que le impida que todos sus servicios compartan la misma base de datos.

Mientras sus servicios se comporten y no hagan cosas inesperadas con los datos que son propiedad de otros servicios, estará bien.

No sé lo que lees, pero debes tener en cuenta que hay muchas opiniones diferentes sobre la arquitectura de microservicios. Aquí hay una buena publicación de blog sobre el tema.

He visto a personas referirse a esta idea en parte, trivialmente, como "cada microservicio debe poseer y controlar su propia base de datos y no hay dos servicios que compartan una base de datos". La idea es sólida: no comparta una sola base de datos entre los servicios porque entonces se topa con conflictos como patrones de lectura / escritura competitivos, conflictos de modelos de datos, desafíos de coordinación, etc.

Pero una sola base de datos nos brinda muchas seguridades y conveniencias: transacciones ACID, un solo lugar para buscar, bien entendido (¿un poco?), Un lugar para administrar, etc.

El viaje a los microservicios es solo eso: un viaje . Será diferente para cada empresa. No hay reglas duras y rápidas, solo compensaciones.

La parte más difícil de los microservicios: sus datos

Como Dan Wilson responde, realmente no lo necesitas. Los microservicios son lo más novedoso y, como todas las cosas novedosas, la gente los usa en muchos lugares, incluso cuando no aportan mucho valor.

Los microservicios le permiten implementar y escalar de forma independiente las cosas a un nivel "micro". Esa granularidad proporciona una gran cantidad de beneficios técnicos e incluso más beneficios no técnicos, ya que le permite separar mejor los equipos de desarrollo, lanzar según sea necesario en lugar de una gran versión, probar nuevas tecnologías o procesos de forma aislada, etc. Tener una base de datos compartida mata mucho de eso debido a la dependencia de la base de datos. Si no puede implementar su servicio sin preocuparse por los datos de otro servicio, ha perdido.

Lo que separa la base de datos está fuera de discusión. ¿O estoy completamente equivocado?

Dicho esto, también estás completamente equivocado.

Cuando trabajas en la nube, las bases de datos son baratas. Gratis por lo general! Claro, el servidor cuesta dinero, pero no estamos hablando de un servidor individual por microservicio (al menos, no al principio). Un solo servidor con un montón de bases de datos (lógicas) está bien siempre que sea diligente para evitar consultas entre bases de datos (que introducen dependencias que dañan "desplegable y escalable de forma independiente"). Demonios, las consultas cruzadas de DB son imposibles en algunos servicios de bases de datos en la nube como Azure SQL. Ni siquiera necesitas ser diligente allí ...

E incluso he visto microservicios donde comparten una base de datos, pero cada servicio tiene su propio esquema. Nuevamente, debe ser diligente para evitar consultas que crucen los límites de datos.

Muchos lugares no son tan diligentes. Tienen desarrolladores de nivel de entrada, o personas que no valoran el enfoque de microservicio, o tienen líderes de equipo pobres, o tienen una presión en la línea de tiempo que hace que las personas tomen atajos.

Tener una base de datos separada es la forma más limpia de imponer ese desacoplamiento que permite la independencia del servicio, pero no es la única forma. Y no es que caro - especialmente cuando se compara con la hora / salario dedicado a tratar de hacer cumplir los límites de datos en una base de datos compartida.

¿Por qué lo necesitamos?

El enorme beneficio de los microservicios, y más ampliamente, SOA, es el alto nivel de abstracción de los componentes internos, no solo la implementación, sino también las tecnologías que se utilizan. Por ejemplo, si un sistema se desarrolla en forma de cinco microservicios por cinco equipos, un equipo puede decidir pasar a una pila tecnológica completamente diferente (por ejemplo, de la pila de Microsoft a LAMP) sin siquiera pedir su opinión a otros equipos.

Mira Amazon AWS o Twilio. ¿Sabes si sus servicios se implementan en Java o Ruby? ¿Utilizan Oracle o PostgreSQL o Cassandra o MongoDB? ¿Cuántas máquinas usan? ¿Te importa eso? en otras palabras, ¿esas elecciones tecnológicas afectan la forma en que usa esos servicios? ... Y lo más importante, si se mueven a una base de datos diferente, ¿tendría que cambiar la aplicación de su cliente en consecuencia?

Ahora, ¿qué sucede si dos servicios usan la misma base de datos? Aquí hay una pequeña parte de los problemas que pueden surgir:

• El equipo que desarrolla el servicio 1 quiere pasar de SQL Server 2012 a SQL Server 2016. Sin embargo, el equipo 2 se basa en una característica obsoleta que se eliminó en SQL Server 2016.

• El servicio 1 es un gran éxito. Alojar la base de datos en dos máquinas (maestra y failover) ya no es una opción. Pero escalar el clúster a varias máquinas requiere estrategias como el fragmentación. Mientras tanto, el equipo 2 está contento con la escala actual y no ve ninguna razón para pasar a otra cosa.

• El servicio 1 debería pasar a UTF-8 como su codificación predeterminada. El Servicio 2, sin embargo, está contento con la página de códigos 1252 Windows Latin 1.

• El servicio 1 decide agregar un usuario con un nombre específico. Sin embargo, este usuario ya existe, creado hace unos meses por el segundo equipo.

• El servicio 1 necesita muchas características diferentes. El servicio 2 es un componente muy crítico y necesita mantener las características de la base de datos al mínimo para reducir el riesgo de ataques.

• El servicio 1 requiere 15 TB de espacio en disco; la velocidad no es importante, por lo que los discos duros normales están perfectamente bien. El servicio 2 requiere 50 GB como máximo, pero necesita acceder a él lo más rápido posible, lo que significa que los datos deben almacenarse en un SSD.

• ...

Cada pequeña elección afecta a todos. Cada decisión debe ser tomada en colaboración, por personas de cada equipo. Hay que hacer compromisos. Compare eso con una total libertad para hacer lo que quiera en un contexto de SOA.

es demasiado [...] inmanejable.

Entonces lo estás haciendo mal. Supongo que estás implementando manualmente .

No es así como deberían hacerse las cosas. Debe automatizar la implementación de máquinas virtuales (o contenedores Docker) que ejecutan la base de datos. Una vez que los automatizó, la implementación de dos servidores o veinte servidores o dos mil servidores no es muy diferente.

Lo mágico de las bases de datos aisladas es que es extremadamente manejable . ¿Has intentado administrar una gran base de datos utilizada por docenas de equipos? Es una pesadilla. Cada equipo tiene solicitudes específicas, y tan pronto como tocas algo, afecta a alguien. Con una base de datos emparejada con una aplicación, el alcance se vuelve muy limitado, lo que significa que hay muchas menos cosas en las que pensar.

Si una gran base de datos requiere administradores de sistemas especializados, las bases de datos que son utilizadas por un solo equipo esencialmente pueden ser administradas por este equipo (DevOps también se trata de eso), liberando el tiempo de los administradores del sistema.

es muy costoso

Definir costo.

Los costos de licencia dependen de la base de datos. En la era de la computación en la nube, estoy bastante seguro de que todos los principales jugadores rediseñaron sus licencias para acomodar el contexto en el que, en lugar de una gran base de datos, hay muchas pequeñas. De lo contrario, puede considerar mudarse a una base de datos diferente. Por cierto, hay muchos de código abierto.

Si habla de potencia de procesamiento, tanto las máquinas virtuales como los contenedores son compatibles con la CPU, y no sería muy afirmativo de que una gran base de datos consumirá menos CPU que muchas pequeñas que hacen el mismo trabajo.

Si su problema es la memoria, las máquinas virtuales no son una buena opción para usted. Los contenedores son. Podrá abarcar tantos como desee, sabiendo que no consumirán más RAM de la necesaria. Si bien el consumo total de memoria será mayor para muchas bases de datos pequeñas en comparación con una grande, supongo que la diferencia no será demasiado importante. YMMV.

Depende de lo que usted considera "caro".

Una base de datos no necesariamente tiene que ser un servidor de base de datos comercial costoso (piense en Oracle) no necesariamente tiene que ser necesariamente un asunto que necesita recursos. Dependiendo de cuáles sean sus requisitos, puede usar la base de datos SQLite o incluso el sistema de archivos como un almacenamiento de datos persistente.

Todos esos servicios también podrían compartir una única instancia / servidor de base de datos y solo tienen esquemas aislados por servicio.

El argumento clave aquí es que el servicio necesita poseer y controlar sus datos. Cómo lo logra, es una cuestión de elección y detalles técnicos.

La mejor forma en que un servicio puede poseer y controlar sus datos es tener su propia base de datos "personal". Esto permite una total libertad de elección de la tecnología y la evolución del esquema de datos. La única forma en que cualquier otro servicio puede acceder a los datos de un servicio es solicitando los datos de un servicio. De esta forma, si es necesario cambiar la representación interna de datos, se puede cambiar fácilmente y no se interrumpirán otros servicios.

Entonces, para recapitular. No es necesariamente costoso tener una base de datos por servicio ni es necesario. Es simplemente una decisión que debe tomar en algún momento al desarrollar microservicios. Cada una de las opciones tiene sus implicaciones y limitaciones. Estudie esos y haga su propia elección.