![\"\"](\"https:\/\/lh4.googleusercontent.com\/LJNBLc7RQmE82gtn20rlG5_f5-9x7L_OLHhH4tO4adLJka9RTjUPe0WzVFh7ksCVDJJwYkj1FAeuLw1LSmu6byQZevHtsP4GVQMZdmpI6YLp8W4g6rAvEVFqNYtSAOXmsSELETIIkoLLwE0KnQzzMQ\")
<\/figure>\n\nLa arquitectura monol\u00edtica es el modelo tradicional de dise\u00f1o de un programa de software construido como una unidad combinada cerrada e independiente de otras aplicaciones. Esta arquitectura se considera el enfoque tradicional para construir y crear aplicaciones como unidades \u00fanicas y unificadas. Normalmente, este enfoque consiste en una interfaz de usuario del lado del cliente, una aplicaci\u00f3n del lado del servidor y una base de datos. Una arquitectura monol\u00edtica es una extensa red inform\u00e1tica con una gran base de c\u00f3digo que integra todas las preocupaciones empresariales. <\/p>\n\n
Cuando quiera cambiar una aplicaci\u00f3n monol\u00edtica, tendr\u00e1 que actualizar toda la pila accediendo a la base de c\u00f3digo y construyendo e instalando una versi\u00f3n actualizada de la interfaz del lado del servicio.<\/p>\n\n
El software monol\u00edtico suele estar formado por tres componentes;<\/p>\n\n
- \n
- Interfaz de usuario del lado del cliente: consiste en p\u00e1ginas HTML o Javascript que se ejecutan en un navegador.<\/li>\n\n\n\n
- Aplicaci\u00f3n del lado del servidor: gestiona las peticiones HTTP, implementa la l\u00f3gica espec\u00edfica del dominio, recupera y actualiza los datos de la base de datos y rellena las vistas HTML que se enviar\u00e1n al navegador.<\/li>\n\n\n\n
- Base de datos: contiene muchas tablas habituales en un sistema de gesti\u00f3n de bases de datos relacionales.<\/li>\n<\/ul>\n\n
Este modelo puede agilizar la canalizaci\u00f3n ETL a medida que los datos se mueven hacia una \u00fanica base de datos a trav\u00e9s del monolito. Sin embargo, aunque aplique un modelo de microservicios, tambi\u00e9n puede simplificar su canalizaci\u00f3n ETL con una soluci\u00f3n sin c\u00f3digo como Xplenty. <\/p>\n\n
Ventajas de la arquitectura monol\u00edtica<\/strong><\/p>\n\n
Una organizaci\u00f3n puede beneficiarse de una arquitectura monol\u00edtica dependiendo de varios factores. Utilizar una arquitectura monol\u00edtica a la hora de construir su aplicaci\u00f3n tiene varias ventajas, y a continuaci\u00f3n le presentamos algunas de ellas. <\/p>\n\n
- \n
- Manejo sencillo de cuestiones que pueden afectar a todo el software. Por lo general, los desarrolladores llaman a los problemas preocupaciones transversales, que incluyen la supervisi\u00f3n del rendimiento, el almacenamiento en cach\u00e9, el registro y el manejo. Todo est\u00e1 colocado en una sola posici\u00f3n en una aplicaci\u00f3n monol\u00edtica y no disperso entre microservicios. La arquitectura monol\u00edtica minimizar\u00e1 en gran medida la dificultad de abordar estas preocupaciones. <\/li>\n\n\n\n
- Simplicidad. Cuando se construyen aplicaciones peque\u00f1as o medianas, la arquitectura monol\u00edtica es m\u00e1s sencilla de desarrollar, desplegar y escalar. La mayor\u00eda de los entornos de desarrollo integrados y de las unidades de desarrollo admiten la arquitectura monol\u00edtica como modelo tradicional de construcci\u00f3n de aplicaciones. Las pruebas de extremo a extremo son mucho m\u00e1s sencillas cuando se trata de una \u00fanica y extensa base de c\u00f3digo. <\/li>\n\n\n\n
- Rendimiento. Las aplicaciones monol\u00edticas suelen tener mejor rendimiento que los microservicios. Una API puede servir para el mismo objetivo en aplicaciones monol\u00edticas porque tiene c\u00f3digo y memoria consolidados. <\/li>\n<\/ul>\n\n
Desventajas de la arquitectura monol\u00edtica<\/strong><\/p>\n\n
Las aplicaciones monol\u00edticas son c\u00f3modas hasta que se ampl\u00edan y su escalado se convierte en un problema. Desplegar un ligero cambio en una funci\u00f3n requiere compilar y probar toda la plataforma, lo que va en contra del enfoque \u00e1gil moderno que utilizan la mayor\u00eda de los desarrolladores. La arquitectura monol\u00edtica tiene algunas desventajas, y a continuaci\u00f3n le presentamos algunas de ellas. <\/p>\n\n
- \n
- Potencial de escalabilidad. El potencial de escalabilidad de una aplicaci\u00f3n monol\u00edtica depende de su tama\u00f1o. Si desea dise\u00f1ar una aplicaci\u00f3n extensa y compleja, existen mejores arquitecturas de software que la arquitectura monol\u00edtica. En una aplicaci\u00f3n m\u00e1s compleja, la escalabilidad ser\u00e1 enorme. Se convertir\u00e1 en una preocupaci\u00f3n considerable, ya que gestionar y contener un proyecto de software agravado bajo una gran base de c\u00f3digo ser\u00e1 m\u00e1s agotador. <\/li>\n\n\n\n
- Flexibilidad. Las aplicaciones monol\u00edticas son r\u00edgidas en lo que respecta a la flexibilidad. Con una aplicaci\u00f3n monol\u00edtica, espere utilizarla durante bastante tiempo sin cambiar su pila tecnol\u00f3gica. Y modificar su pila es pr\u00e1cticamente imposible con una arquitectura monol\u00edtica. Tendr\u00e1 que reescribir su software para albergar la pila que desee implementar, lo que requiere muchos recursos y no merece la pena. <\/li>\n\n\n\n
- La arquitectura monol\u00edtica hace que su c\u00f3digo sea m\u00e1s complicado. Al existir una \u00fanica base de c\u00f3digo, \u00e9sta se vuelve exponencialmente compleja a medida que la aplicaci\u00f3n se desarrolla y cambia. Esos cambios o actualizaciones exigen una coordinaci\u00f3n en toda la aplicaci\u00f3n, pero los usuarios pueden extenderlos m\u00e1s all\u00e1 de una \u00fanica parte. <\/li>\n<\/ul>\n\n
Arquitectura de microservicios<\/strong><\/p>\n\n
<\/figure>\n\n
Mientras que una aplicaci\u00f3n monol\u00edtica es una \u00fanica unidad integrada, la arquitectura de microservicios la divide en varias unidades aut\u00f3nomas m\u00e1s peque\u00f1as. Estas unidades suelen ejecutar cada proceso de la aplicaci\u00f3n como un servicio independiente. Por lo tanto, todos los servicios tienen su base de datos y su l\u00f3gica y realizan funciones espec\u00edficas. <\/p>\n\n
La arquitectura de microservicios es un enfoque en el que una \u00fanica aplicaci\u00f3n se desarrolla como un conjunto de peque\u00f1os servicios, cada uno de los cuales funciona en su proceso y se comunica con mecanismos ligeros, normalmente una API de recursos HTTP. Sam Newman, consultor independiente, dice: \u00abLos microservicios son los peque\u00f1os servicios que funcionan juntos\u00bb. <\/p>\n\n
La arquitectura de microservicios est\u00e1 formada por una colecci\u00f3n de servicios min\u00fasculos y aut\u00f3nomos. Cada servicio es independiente e implementa una capacidad empresarial o t\u00e9cnica de la aplicaci\u00f3n que encapsulan dentro de un contexto delimitado. Un contexto delimitado se refiere a una secci\u00f3n natural dentro de la organizaci\u00f3n y proporciona un l\u00edmite claro dentro del cual existe el modelo de dominio. <\/p>\n\n
La arquitectura de microservicios afecta notablemente a la relaci\u00f3n entre la base de datos y la aplicaci\u00f3n. As\u00ed, en lugar de utilizar una \u00fanica base de datos con otros microservicios, cada microservicio tiene su base de datos. Una base de datos por microservicio es vital si desea beneficiarse de esta arquitectura para garantizar un acoplamiento suelto. <\/p>\n\n
Componentes de la arquitectura de microservicios<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-pixabay-326461-1024x678.jpg\")
<\/figure>\n\nLos microservicios son peque\u00f1os, autocontenidos y est\u00e1n d\u00e9bilmente acoplados. Un peque\u00f1o equipo de programadores puede escribir y dar soporte al servicio, ya que cada servicio es propietario de su base de datos. Los servicios son responsables de preservar sus datos o su estado externo. Esto contradice el enfoque tradicional, en el que una capa de datos separada se encarga de la preservaci\u00f3n de los datos. Estos son algunos de los componentes de una arquitectura de microservicios <\/p>\n\n
- \n
- Orquestaci\u00f3n. Este componente se ocupa de colocar los servicios en los nodos, reconocer los fallos, estabilizar los servicios entre los nodos, etc. Por lo general, este componente es una tecnolog\u00eda off-the-shell como Kubernetes en lugar de construida a medida. <\/li>\n\n\n\n
- Pasarela API. La pasarela API es el punto de entrada para los clientes. En lugar de llamar directamente a los servicios, los clientes llaman por tel\u00e9fono a la puerta API y reenv\u00edan la llamada a los servicios adecuados en el back-end. <\/li>\n<\/ul>\n\n
Ventajas de la arquitectura de microservicios<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-sebastian-voortman-411207-1024x683.jpg\")
<\/figure>\n\nLa arquitectura de microservicios ha avanzado gracias a la nube, la contenedorizaci\u00f3n y los sistemas hiperconectados. Adem\u00e1s, la arquitectura de microservicios tiene algunas ventajas para el usuario, que se enumeran a continuaci\u00f3n. <\/p>\n\n
- \n
- Agilidad mejorada. Con este tipo de arquitectura de software, los desarrolladores pueden trabajar en m\u00f3dulos independientes. Cada desarrollador puede crear y desplegar un m\u00f3dulo de forma independiente, lo que minimiza la fricci\u00f3n operativa del equipo. Adem\u00e1s, es f\u00e1cil controlar las correcciones de errores y los lanzamientos de actualizaciones. Puede actualizar un servicio sin volver a desplegar toda la aplicaci\u00f3n y cancelar la actualizaci\u00f3n si sale mal. Normalmente, cuando se descubre un fallo en una parte de las aplicaciones monol\u00edticas, puede bloquear todo el proceso de lanzamiento. <\/li>\n\n\n\n
- Mejor escalabilidad. La arquitectura de microservicios puede escalar cada servicio de forma independiente. Le permite escalar los subsistemas que necesitan m\u00e1s recursos sin necesidad de escalar toda la aplicaci\u00f3n. Escalar aplicaciones monol\u00edticas consume tiempo y costes incluso cuando no es necesario. Utilizando un orquestador como Service Fabric o Kubernetes se consigue una mayor densidad de servicios en un solo host, lo que permite una utilizaci\u00f3n eficaz de los recursos. <\/li>\n\n\n\n
- La arquitectura de microservicios fomenta la descentralizaci\u00f3n. Un gobierno central centrado es fundamental para el \u00e9xito de la gobernanza. Este tipo de estructura ser\u00eda f\u00e1cil de derribar, pol\u00edtica aparte. La centralizaci\u00f3n de las cosas en un solo lugar significa que cuando una va mal. todo el sistema se viene abajo. La arquitectura de microservicios adopta la descentralizaci\u00f3n, por la que los desarrolladores operan de forma m\u00e1s independiente y pueden trabajar en equipo independientemente de su ubicaci\u00f3n. Adem\u00e1s, hay flexibilidad. Puede implementar varias pilas tecnol\u00f3gicas en una sola aplicaci\u00f3n. Esto le ayuda a seleccionar la pila tecnol\u00f3gica m\u00e1s influyente para dise\u00f1ar un servicio. <\/li>\n<\/ul>\n\n
Desventajas de la arquitectura de microservicios<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-tim-gouw-52608-1024x685.jpg\")
<\/figure>\n\nLos beneficios de los microservicios son demasiado buenos para ser gratuitos. Los inconvenientes de una arquitectura de microservicios son un poco dif\u00edciles de soportar. Adem\u00e1s, debe estar seguro de elegir la arquitectura de software ejemplar para su empresa. <\/p>\n\n
- \n
- Complejidad. La arquitectura de microservicios tiene varias partes m\u00f3viles que la arquitectura monol\u00edtica. Cada servicio es sencillo, pero el sistema en su conjunto se vuelve complejo. La comunicaci\u00f3n entre servicios es complicada; las API suelen fomentar esta comunicaci\u00f3n y suelen implementarse para vincular plataformas de software. La complejidad en las aplicaciones de microservicios aumenta con el incremento de los microservicios. <\/li>\n\n\n\n
- Congesti\u00f3n de la red. Utilizar muchos servicios peque\u00f1os puede provocar una comunicaci\u00f3n interservicios. Y cuando la cadena de dependencias de servicios se hace muy larga, la latencia adicional se convierte en un problema. Esto significa que tendr\u00e1 que crear las API con cuidado. Piense en los formatos de serializaci\u00f3n y busque lugares para utilizar patrones de comunicaci\u00f3n as\u00edncrona. <\/li>\n\n\n\n
- Desarrollo y pruebas. El dise\u00f1o de un peque\u00f1o servicio que depende de otros servicios dependientes requiere un enfoque diferente al de la escritura de un programa tradicional por capas. Las herramientas disponibles no siempre est\u00e1n creadas para funcionar con dependencias de servicios. La refactorizaci\u00f3n a trav\u00e9s de las fronteras de los servicios se vuelve extenuante, y probar las dependencias de los servicios es complejo, especialmente cuando la aplicaci\u00f3n evoluciona r\u00e1pidamente. <\/li>\n<\/ul>\n\n
Migraci\u00f3n de monolitos a microservicios<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-liz-lauren-6000599-1024x683.jpg\")
<\/figure>\n\nLa escalabilidad es la principal raz\u00f3n por la que los desarrolladores pasan de una arquitectura monol\u00edtica a una de microservicios. La escalabilidad en componentes poco utilizados es insignificante. Los componentes utilizados por la mayor\u00eda de los usuarios deben tenerse en cuenta en primer lugar a la hora de trasladarse. He aqu\u00ed un procedimiento t\u00edpico para pasar de un sistema monol\u00edtico a un enfoque de microservicios. <\/p>\n\n
- \n
- Identifique los componentes l\u00f3gicos.<\/li>\n<\/ol>\n\n
Existen principalmente tres componentes de informaci\u00f3n con los datos utilizados en el sistema: objetos de datos, acciones, trabajos a realizar y casos de uso. Las construcciones l\u00f3gicas son los objetos de datos que representan los datos que se utilizan. Las acciones de datos son \u00f3rdenes para ejecutar una tarea en uno o varios objetos de datos. Los trabajos a realizar representan las funciones que los usuarios llaman para desempe\u00f1ar sus funciones. <\/p>\n\n
- \n
- Refactorizar componentes<\/li>\n<\/ol>\n\n
Una vez identificados y ensamblados todos los componentes, organ\u00edcelos internamente: antes de aplicar el microservicio hay que ocuparse de algunas funciones duplicadas. S\u00f3lo debe haber un microservicio que ejecute cualquier funci\u00f3n. <\/p>\n\n
- \n
- Identificar las dependencias de los componentes<\/li>\n<\/ol>\n\n
Tras identificar y organizar los componentes para la migraci\u00f3n, el sistema debe reconocer las dependencias dentro de los componentes. En esta tarea se suele utilizar un an\u00e1lisis est\u00e1tico del c\u00f3digo fuente para buscar llamadas entre distintas bibliotecas y tipos de datos. <\/p>\n\n
- \n
- Grupos de componentes puntuales<\/li>\n<\/ol>\n\n
El arquitecto del sistema debe concentrarse en categorizar los componentes en grupos que puedan transformarse en microservicios. El objetivo es encontrar un peque\u00f1o conjunto de objetos y sus acciones elementales que deben separarse en el sistema final. <\/p>\n\n
- \n
- Crear una API para la interfaz de usuario remota<\/li>\n<\/ol>\n\n
La interfaz de usuario remota es la \u00fanica v\u00eda de comunicaci\u00f3n entre el sistema, sus componentes y los usuarios del sistema. Esta interfaz debe planificarse sistem\u00e1ticamente y ser escalable para evitar problemas a medida que crece el sistema. <\/p>\n\n
- \n
- Mueva los grupos de componentes a macroservicios.<\/li>\n<\/ol>\n\n
Los macroservicios tienden a tener una postura moderada hacia el reparto de los repositorios de datos y permiten interacciones m\u00e1s complejas con los objetos de datos. Por lo tanto, es vital considerar su uso como un paso provisional para completar la migraci\u00f3n. <\/p>\n\n
- \n
- Trasladar macroservicios a microservicios<\/li>\n<\/ol>\n\n
La extracci\u00f3n de objetos de datos, componentes y funciones de la arquitectura monol\u00edtica a los macroservicios ofrecer\u00e1 una visi\u00f3n de c\u00f3mo estos componentes pueden dividirse a\u00fan m\u00e1s en microservicios. Recuerde que cada microservicio contiene su base de datos y ejecuta s\u00f3lo un conjunto limitado de acciones sobre sus objetos de datos. <\/p>\n\n
- \n
- Despliegue y pruebas<\/li>\n<\/ol>\n\n
El siguiente paso consiste en las pruebas de integraci\u00f3n y el despliegue cuando el microservicio est\u00e9 listo. La arquitectura monol\u00edtica debe personalizarse para que utilice el nuevo servicio para sus demandas de datos en lugar de su base de datos heredada. <\/p>\n\n
Conclusi\u00f3n<\/strong><\/p>\n\n
Adoptar una arquitectura de microservicios no es un enfoque polivalente. A pesar de ser infame y menos famosa, la arquitectura monol\u00edtica tiene ventajas robustas y de peso sobre los microservicios, as\u00ed como sus puntos fuertes. Deber\u00eda empezar con una arquitectura monol\u00edtica para validar su nueva idea de negocio. Un peque\u00f1o equipo de desarrolladores le acompa\u00f1a para desarrollar una aplicaci\u00f3n sencilla sin necesidad de microservicios. <\/p>\n\n
La arquitectura de microservicios es m\u00e1s satisfactoria para aplicaciones extensas y complejas. Proporciona soluciones de producto para un sistema complejo con varias funciones y servicios dentro de una \u00fanica aplicaci\u00f3n. Los microservicios son perfectos para plataformas que abarcan muchos recorridos y flujos de trabajo de los usuarios. <\/p>\n","protected":false},"excerpt":{"rendered":"
Estoy seguro de que se ha encontrado con un tema como la arquitectura monol\u00edtica VS microservicios con menos frecuencia de la que ha o\u00eddo a la gente hablar de paradigmas de programaci\u00f3n, herramientas o marcos de software. Debe seleccionar el tipo de arquitectura de software al emprender su proyecto. Ayuda a definir el dise\u00f1o de […]<\/p>\n","protected":false},"author":1,"featured_media":16701,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[86],"tags":[],"writer":[],"class_list":["post-19694","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19694","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/comments?post=19694"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19694\/revisions"}],"predecessor-version":[{"id":19697,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19694\/revisions\/19697"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/16701"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19694"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Despliegue y pruebas<\/li>\n<\/ol>\n\n
- Trasladar macroservicios a microservicios<\/li>\n<\/ol>\n\n
- Mueva los grupos de componentes a macroservicios.<\/li>\n<\/ol>\n\n
- Crear una API para la interfaz de usuario remota<\/li>\n<\/ol>\n\n
- Grupos de componentes puntuales<\/li>\n<\/ol>\n\n
- Identificar las dependencias de los componentes<\/li>\n<\/ol>\n\n
- Refactorizar componentes<\/li>\n<\/ol>\n\n
- Identifique los componentes l\u00f3gicos.<\/li>\n<\/ol>\n\n