{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservicios: qu\u00e9 son, para qu\u00e9 sirven y cu\u00e1ndo implementarlos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quer\u00eda escribir un art\u00edculo sobre la arquitectura de microservicios desde hace tiempo, sin embargo, dos cosas siempre me detuvieron: cuanto m\u00e1s profundizaba en el tema, m\u00e1s me parec\u00eda que lo que sab\u00eda era obvio, y lo que no sab\u00eda, a\u00fan ten\u00eda que investigar m\u00e1s. Por otro lado, creo que ya hay suficiente material para discutir y compartir con una audiencia m\u00e1s amplia. As\u00ed que se agradecen las opiniones alternativas.
\n<\/a><\/noindex><\/p>\n

La Ley de Conway y la relaci\u00f3n entre el negocio, la organizaci\u00f3n y el sistema de informaci\u00f3n<\/h2>\n

\nPerm\u00edtanme citar una vez m\u00e1s:<\/p>\n

\u00abCualquier organizaci\u00f3n que dise\u00f1e alg\u00fan sistema (en un sentido amplio) obtendr\u00e1 un dise\u00f1o cuya estructura copia la estructura de los equipos dentro de esa organizaci\u00f3n\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

En mi opini\u00f3n, esta ley se relaciona m\u00e1s con la viabilidad de la organizaci\u00f3n empresarial que directamente con el sistema de informaci\u00f3n. Perm\u00edtanme explicarlo con un ejemplo. Supongamos que tenemos una oportunidad de negocio establecida con un ciclo de vida lo suficientemente largo como para justificar la organizaci\u00f3n de una empresa (no es un error tipogr\u00e1fico, pero me gusta mucho este t\u00e9rmino que he tomado prestado). Es evidente que el sistema que respalda este negocio se alinear\u00e1 organizativamente y en t\u00e9rminos de procesos con la naturaleza de este negocio.<\/p>\n

Orientaci\u00f3n empresarial de los sistemas de informaci\u00f3n<\/h2>\n

\n\"Microservicios:
\n
\nPerm\u00edtanme explicarlo con un ejemplo. Supongamos que hay una oportunidad de negocio para organizar un negocio de venta de pizzas. En la versi\u00f3n V1 (llam\u00e9mosla pre-informativa), la empresa consist\u00eda en una pizzer\u00eda, un punto de venta y un servicio de entrega. Esta versi\u00f3n fue muy duradera en un entorno de baja volatilidad. Luego lleg\u00f3 la versi\u00f3n 2, que era m\u00e1s avanzada y capaz de utilizar un sistema de informaci\u00f3n como base para un negocio con arquitectura monol\u00edtica. Y aqu\u00ed, en mi opini\u00f3n, surge una injusticia terrible con respecto a los monolitos \u2014 supuestamente la arquitectura monol\u00edtica no corresponde al modelo de dominio del negocio.<\/b>Si as\u00ed fuera, el sistema no podr\u00eda funcionar en absoluto, lo que contradice la misma ley de Conway y el sentido com\u00fan. No, la arquitectura monol\u00edtica se ajusta completamente al modelo de negocio en esta etapa del desarrollo empresarial; me refiero, por supuesto, a la etapa en la que el sistema ya ha sido creado y puesto en funcionamiento. Es un hecho completamente notable que, independientemente del enfoque arquitect\u00f3nico, tanto la arquitectura orientada a servicios de la versi\u00f3n 3 como la arquitectura de microservicios de la versi\u00f3n N funcionar\u00e1n igualmente bien. \u00bfD\u00f3nde est\u00e1 la trampa?<\/p>\n

Todo fluye, todo cambia, \u00bfo los microservicios son una herramienta para combatir la complejidad?<\/h2>\n

\n Antes de continuar, consideremos algunas confusiones respecto a la arquitectura de microservicios.<\/p>\n

Los defensores del uso del enfoque de microservicios a menudo dicen que dividir un monolito en microservicios simplifica el desarrollo al reducir la base de c\u00f3digo de los servicios individuales. Desde mi punto de vista, esta afirmaci\u00f3n es completamente absurda. En serio, \u00bfla interacci\u00f3n obvia dentro de un monolito y el c\u00f3digo homog\u00e9neo parece complicada? Si realmente fuera as\u00ed, todos los proyectos se construir\u00edan desde el principio como microservicios, mientras que la pr\u00e1ctica demuestra que la migraci\u00f3n de un monolito a microservicios es mucho m\u00e1s com\u00fan. La complejidad no desaparece, simplemente se traslada de m\u00f3dulos individuales a interfaces (ya sean buses de datos, RPC, API y otros protocolos) y sistemas orquestadores. \u00a1Y esto es complicado! <\/p>\n

La ventaja de usar un stack heterog\u00e9neo tambi\u00e9n es dudosa. No voy a discutir que eso tambi\u00e9n es posible, pero en realidad rara vez ocurre (Y, adelantando un poco, deber\u00eda ser as\u00ed, pero m\u00e1s como consecuencia que como ventaja).<\/p>\n

El ciclo de vida del producto y el ciclo de vida del servicio<\/h2>\n

\nMira de nuevo el diagrama anterior. No resalt\u00e9 por casualidad la disminuci\u00f3n del ciclo de vida de cada versi\u00f3n del negocio; en las condiciones modernas, acelerar la transici\u00f3n del negocio entre versiones es determinante para su \u00e9xito. El \u00e9xito de un producto se determina por la velocidad de verificaci\u00f3n de las hip\u00f3tesis comerciales en \u00e9l<\/b>. Y aqu\u00ed es donde, en mi opini\u00f3n, se encuentra la clave de la ventaja de la arquitectura de microservicios. Pero vayamos por partes. <\/p>\n

Pasemos a la siguiente etapa de la evoluci\u00f3n de los sistemas de informaci\u00f3n: la arquitectura orientada a servicios (SOA). As\u00ed que, en alg\u00fan momento determinado, destacamos en nuestro producto servicios de larga duraci\u00f3n<\/b> \u2014 servicios duraderos en el sentido de que al pasar entre versiones del producto, hay probabilidades de que el ciclo de vida del servicio sea m\u00e1s largo que el ciclo de vida de la pr\u00f3xima versi\u00f3n del producto. Ser\u00eda l\u00f3gico no cambiarlos en absoluto, ya que lo que realmente nos importa es la velocidad de transici\u00f3n a la siguiente versi\u00f3n<\/b>. Pero, lamentablemente, nos vemos obligados a realizar cambios constantes en los servicios, y aqu\u00ed todo nos sirve: las pr\u00e1cticas de DevOps, la contenedorizaci\u00f3n y todo lo que se nos ocurra. \u00a1Pero eso a\u00fan no son microservicios! <\/p>\n

Microservicios como medio para luchar contra la complejidad\u2026 gesti\u00f3n de configuraciones<\/h2>\n

\n Y aqu\u00ed es donde finalmente podemos pasar al papel definitorio de los microservicios: es un enfoque que simplifica la gesti\u00f3n de la configuraci\u00f3n del producto. M\u00e1s concretamente, la funci\u00f3n de cada microservicio describe exactamente una funci\u00f3n de negocio dentro del producto seg\u00fan el modelo de dominio, y estas son cosas que no viven en una versi\u00f3n de corta duraci\u00f3n, sino en una oportunidad comercial de larga duraci\u00f3n. Y la transici\u00f3n a la siguiente versi\u00f3n del producto ocurre de forma casi imperceptible: cambias o agregas un microservicio, o quiz\u00e1s simplemente el esquema de su interacci\u00f3n, y de repente ya te encuentras en el futuro, dejando atr\u00e1s a los competidores llorando que siguen saltando entre las versiones de sus monolitos. Ahora imagina que hay un volumen considerable de microservicios con interfaces y oportunidades de negocio ya definidas. Y t\u00fa llegas y construyes la estructura de tu producto a partir de microservicios listos, simplemente dibujando un diagrama, por ejemplo. Felicitaciones, has creado una plataforma, y ahora puedes hacer que tu negocio despegue. Sue\u00f1os, sue\u00f1os. <\/p>\n

Conclusiones<\/h2>\n

<\/p>\n