{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Elecci\u00f3n del estilo arquitect\u00f3nico (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hola, Habr. En este momento, OTUS est\u00e1 aceptando inscripciones para un nuevo grupo del curso \u00abArquitecto de Software\u00bb<\/a><\/noindex>. Antes del inicio del curso, quiero compartir con ustedes mi art\u00edculo autoral.<\/i><\/b><\/p>\n

<\/p>\n

Introducci\u00f3n<\/h2>\n

\nLa elecci\u00f3n del estilo arquitect\u00f3nico es una de las decisiones t\u00e9cnicas fundamentales al construir un sistema de informaci\u00f3n. En esta serie de art\u00edculos, propongo analizar los estilos arquitect\u00f3nicos m\u00e1s populares para la construcci\u00f3n de aplicaciones y responder a la pregunta de cu\u00e1ndo es preferible un estilo arquitect\u00f3nico en particular. A lo largo de la exposici\u00f3n, intentar\u00e9 establecer una cadena l\u00f3gica que explique el desarrollo de estilos arquitect\u00f3nicos desde monolitos hasta microservicios.
\n<\/a><\/noindex><\/p>\n

Un poco de historia<\/h2>\n

\nSi intentas preguntar a los desarrolladores: \u00ab\u00bfPara qu\u00e9 sirven los microservicios?\u00bb, recibir\u00e1s las respuestas m\u00e1s diversas. Escuchar\u00e1s que los microservicios mejoran la escalabilidad, simplifican la comprensi\u00f3n del c\u00f3digo, mejoran la tolerancia a fallos, y a veces, se menciona que permiten \u00ablimpiar el c\u00f3digo\u00bb. Vamos a remitirnos a la historia para entender qu\u00e9 objetivo persegu\u00eda la aparici\u00f3n de los microservicios.<\/p>\n

En resumen, los microservicios, en nuestra comprensi\u00f3n actual, surgieron de la siguiente manera: en 2011, James Lewis, al analizar el trabajo de diversas empresas, not\u00f3 la aparici\u00f3n de un nuevo patr\u00f3n \u00abmicro-app\u00bb que optimizaba SOA desde el punto de vista de la aceleraci\u00f3n de la implementaci\u00f3n de servicios. Un poco m\u00e1s tarde, en 2012, en la cumbre arquitect\u00f3nica, el patr\u00f3n fue renombrado como microservicio. Por lo tanto, el objetivo inicial de la implementaci\u00f3n de microservicios fue mejorar el famoso time to market<\/b>.<\/p>\n

En la \u00abola del 'hype'\u00bb, los microservicios estuvieron de moda en 2015. Seg\u00fan algunas investigaciones, ninguna conferencia se llevaba a cabo sin una presentaci\u00f3n sobre microservicios. Adem\u00e1s, algunas conferencias se dedicaron exclusivamente a microservicios. Hoy en d\u00eda, muchos proyectos comienzan utilizando este estilo arquitect\u00f3nico, y si un proyecto contiene toneladas de c\u00f3digo heredado, seguramente est\u00e1 en proceso de migraci\u00f3n a microservicios.<\/p>\n

A pesar de lo mencionado, todav\u00eda hay un n\u00famero relativamente peque\u00f1o de desarrolladores que pueden definir el concepto de \u00abmicroservicio\u00bb. Pero de esto hablaremos m\u00e1s adelante...<\/p>\n

Monolito<\/h2>\n

\nEl estilo arquitect\u00f3nico que se contrapone a los microservicios es el monolito (o \"todo en uno\"). Explicar qu\u00e9 es un monolito quiz\u00e1s no tenga sentido, as\u00ed que enumerar\u00e9 de inmediato las desventajas de este estilo arquitect\u00f3nico que han impulsado el desarrollo de otros estilos arquitect\u00f3nicos: tama\u00f1o, acoplamiento, despliegue, escalabilidad, fiabilidad y rigidez. A continuaci\u00f3n, propongo familiarizarse con cada una de estas desventajas por separado.<\/p>\n

Tama\u00f1o<\/h3>\n

\nEl monolito es muy grande y normalmente interact\u00faa con una base de datos muy extensa. La aplicaci\u00f3n se vuelve demasiado grande para que un solo desarrollador pueda comprenderla por completo. Solo aquellos que han pasado mucho tiempo con este c\u00f3digo pueden trabajar bien con el monolito, mientras que los nuevos gastar\u00e1n mucho tiempo tratando de entenderlo y no hay garant\u00eda de que lo logren. Normalmente, siempre hay alg\u00fan \"senior\" (condicional) que conoce el monolito m\u00e1s o menos bien y controla a los nuevos desarrolladores durante un a\u00f1o o a\u00f1o y medio. Naturalmente, este senior condicional es un \u00fanico punto de fallo, y su salida puede llevar a la ca\u00edda del monolito. <\/p>\n

Acoplamiento<\/h3>\n

\nEl monolito se asemeja a un \"gran bulto de barro\" (big ball of mud), donde los cambios pueden tener consecuencias impredecibles. Al realizar cambios en un lugar, se puede da\u00f1ar el monolito en otro (es como rascarse la oreja y que @* se caiga). Esto se debe a que los componentes del monolito tienen relaciones muy complejas y, lo m\u00e1s importante, poco evidentes.<\/p>\n

Despliegue<\/h3>\n

\nEl despliegue del monolito, debido a las complejas interrelaciones entre sus componentes, es un proceso largo con su propio ritual. Este ritual normalmente no est\u00e1 completamente estandarizado y se transmite \"de boca en boca\". <\/p>\n

Escalabilidad<\/h3>\n

\nLos m\u00f3dulos del monolito pueden tener necesidades conflictivas de recursos, lo que obliga a buscar un compromiso en t\u00e9rminos de hardware. Imag\u00ednese que su monolito consiste en los servicios A y B. El servicio A es exigente en cuanto al tama\u00f1o del disco duro, mientras que el servicio B lo es en cuanto a la memoria RAM. En este caso, la m\u00e1quina en la que se instala el monolito debe satisfacer los requisitos de ambos servicios, o bien ser\u00e1 necesario desconectar manualmente uno de los servicios.<\/p>\n

Otro ejemplo (m\u00e1s cl\u00e1sico): el servicio A es mucho m\u00e1s popular que el servicio B, por lo que deseas tener 100 instancias del servicio A y 10 del servicio B. Nuevamente, hay dos opciones: o desplegamos 100 monolitos completos, o en algunos de ellos tendremos que desactivar manualmente los servicios B. <\/p>\n

Fiabilidad<\/h3>\n

\nDado que todos los servicios est\u00e1n juntos, si el monolito falla, todos los servicios caen de inmediato. En realidad, esto puede no ser tan malo, al menos no habr\u00e1 fallos parciales en un sistema distribuido, pero por otro lado, debido a un error en una funcionalidad que utiliza el 0.001% de los usuarios, podr\u00edas perder a todos los usuarios de tu sistema. <\/p>\n

Rigidez<\/h3>\n

\nDebido al tama\u00f1o del monolito, es dif\u00edcil migrar a nuevas tecnolog\u00edas. Como consecuencia, surge la tarea de retener a ese senior en particular. El stack tecnol\u00f3gico elegido al inicio del proyecto puede convertirse en un obst\u00e1culo que impida el desarrollo del producto. <\/p>\n

Conclusi\u00f3n<\/h2>\n

\nLa pr\u00f3xima vez hablaremos sobre c\u00f3mo las personas intentaron resolver los problemas mencionados al pasar a componentes y SOA.<\/p>\n

\"Elecci\u00f3n<\/a><\/noindex><\/p>\n

\n

Leer m\u00e1s:<\/h4>\n

<\/p>\n