Además de la escalabilidad, una de las mejores características de la arquitectura de microservicios es que si uno de los servicios falla, se implementará otro en su lugar.
En el mercado hipercompetitivo actual, el camino ideal para su negocio debería ser obvio. En otras palabras, usted quiere estar siempre por delante o por delante de la curva. Esto significa que sus desarrolladores y su equipo de TI siempre estarán aprendiendo nuevas tecnologías y mejores prácticas. A medida que aprenda nuevas habilidades y adopte nuevas pilas de software, descubrirá que debe tomar una serie de decisiones.
Una decisión importante a la que se enfrentará es si optar por una arquitectura de microservicios o una arquitectura monolítica. Tome la decisión correcta para su empresa y obtendrá grandes ganancias. Si toma la decisión equivocada, se encontrará en una batalla constante y cuesta arriba para mantener su centro de datos funcionando sin problemas.
Una decisión tan mala puede ser una pesadilla para sus desarrolladores, ya sea que trabajen con Java, JavaScript, Ruby o .NET. Esto también puede afectar todo el proceso de desarrollo de la aplicación. Por lo tanto, es fundamental que aquellos en su empresa que toman decisiones tan importantes comprendan en qué se está metiendo.
Entonces, ¿cuáles son estas arquitecturas? Veámoslos y veamos cuál podría ser el adecuado para usted.
| Criterio | Microservicios | Monolítico |
|---|---|---|
| Estructura | Divide la aplicación en servicios pequeños, poco acoplados e independientes. | Construye la aplicación como una unidad única e indivisible. |
| Desarrollo | Permite el desarrollo y la implementación independientes de servicios. | Todos los componentes están interconectados, por lo tanto deben desarrollarse juntos. |
| Escalabilidad | Los componentes individuales se pueden escalar según sea necesario | Toda la aplicación debe escalar incluso si una sola función tiene una mayor demanda. |
| Pila de tecnología | Cada servicio puede utilizar una pila de tecnología diferente. | Todos los componentes deben utilizar la misma pila de tecnología. |
| Implantación | Permite la implementación e integración continuas | Es necesario volver a implementar toda la aplicación para obtener actualizaciones. |
| Aislamiento obligatorio | El fracaso en un servicio no afecta a los demás | Un solo error puede hacer caer toda la aplicación |
| Actuación | Alto rendimiento y velocidad debido al trabajo liviano | El rendimiento depende del tamaño y la complejidad de la aplicación |
| Gestión de datos | Cada servicio puede tener su propia base de datos. | Se utiliza una única base de datos para toda la aplicación. |
| Complejidad | Más complejo debido a los desafíos del sistema distribuido | Al principio es menos complejo, pero puede volverse difícil de gestionar con el tiempo. |
| Velocidad de desarrollo | Inicialmente más lento debido a la necesidad de una planificación cuidadosa | Inicialmente más rápido debido a la simplicidad. |
| Modificación | Es más fácil actualizar o agregar nuevas funciones sin interrumpir otros servicios | Las actualizaciones o modificaciones pueden requerir cambios en todo el sistema |
| Pruebas y depuración | Más fácil de probar y depurar servicios específicos de forma independiente | Las pruebas y la depuración pueden ser más desafiantes debido a la interconectividad de las aplicaciones. |
| Comunicación entre servicios | Los servicios se comunican a través de API, lo que puede agregar latencia | Los componentes interactúan directamente y generalmente ofrecen una latencia más baja. |
Arquitectura monolítica
Empezamos con monolítico porque es el más sencillo de entender. ¿Por qué? Porque la arquitectura monolítica existe desde hace mucho tiempo. De hecho, las aplicaciones monolíticas son lo que la mayoría de la gente entiende como "software".
En pocas palabras, una aplicación monolítica es aquella creada como una sola unidad, aunque esto no significa necesariamente que esté incluido todo para ejecutar esa aplicación. Analicémoslo para que podamos entender mejor lo que está pasando.
Sí, hay aplicaciones instaladas como clientes independientes. Tomemos, por ejemplo, una suite ofimática como LibreOffice . Esta aplicación no depende de ningún software o servicio externo o de terceros para ejecutarse. Todo se ejecuta en la máquina cliente local.
Por otro lado, la plataforma de blogs WordPress requiere lo siguiente para funcionar:
- Un servidor de base de datos
- Una aplicación del lado del servidor
- Una interfaz de usuario del lado del cliente
Cada uno de estos componentes es monolítico y trabaja en conjunto para crear el todo.
¿Confundido? Simplifiquemos mirando desde la perspectiva del desarrollador.
Supongamos que su empresa ha implementado un sistema de gestión de contenidos monolítico desarrollado internamente. Este sistema incluye una base de datos, una aplicación del lado del servidor y una interfaz de usuario del lado del cliente. Funciona perfectamente y tu equipo depende de ello todos los días.
Sin embargo, en algún momento sus desarrolladores querrán agregar nuevas funciones al componente del lado del servidor. Para hacer esto, los desarrolladores tendrán que reconstruir y reimplementar toda la aplicación del lado del servidor. Si bien el resultado final puede valer la pena, lleva un tiempo considerable recorrer todo el proceso de desarrollo (diseño, desarrollo, pruebas de preguntas y respuestas e implementación).
Arquitectura de microservicios
Ahora veamos la arquitectura de microservicios. Mientras que una aplicación monolítica está contenida en una sola unidad, los microservicios la dividen en un conjunto de unidades independientes mucho más pequeñas. Cada una de estas unidades funciona para servir a todos los servicios de aplicaciones que luego se combinan como un todo unificado.
Uno de los mejores ejemplos de arquitectura de microservicios son los contenedores.
Podría implementar un servidor NGINX como un servicio monolítico. Instale NGINX en un servidor Linux y estará listo para servir sus sitios web. Podrías agregar una base de datos a la mezcla instalando Maria DB . Sin embargo, este despliegue plantea dos problemas importantes.
Primero, si desea actualizar su servidor web, debe actualizar cada componente en su conjunto: el servidor web y la base de datos. En segundo lugar, es posible que este tipo de implementación no pueda escalarse para satisfacer las necesidades de la empresa.
La otra ruta sería implementar este servidor web como una colección de microservicios, a través de contenedores. Puede implementar un pod de Kubernetes que contenga el servidor web NGINX, un pod que contenga la base de datos y luego conectarlos a un servicio de red y un volumen de almacenamiento para almacenar datos.
Cuando necesite ampliar su implementación, Kubernetes puede implementar automáticamente más contenedores NGINX y MariaDB en el clúster.
Además de la escalabilidad, una de las mejores características de la arquitectura de microservicios es que si uno de los servicios falla, se implementará otro en su lugar. Por lo tanto, la conmutación por error está integrada. Y dado que todos sus componentes se implementan de forma independiente, las perspectivas de actualización son mucho más sencillas. Esto es especialmente cierto con los contenedores, donde el tiempo de inactividad inducido por actualizaciones es casi inexistente.
¿Cuál es mejor para tu empresa?
Esto se puede responder de manera bastante simple:
- Si su empresa necesita alta escalabilidad, conmutación por error y confiabilidad, debe utilizar una arquitectura de microservicios.
- Si su empresa requiere principalmente herramientas basadas en cliente (instaladas en computadoras de escritorio) o si no considera la expansión horizontal a nivel empresarial, la arquitectura monolítica es la mejor opción.
La advertencia
Esto viene con una advertencia. La arquitectura de microservicios no es tan fácil de implementar. Kubernetes supone un desafío en casi todos los niveles imaginables. Entonces, si está interesado en la arquitectura de microservicios, asegúrese de contar con desarrolladores y administradores de TI a la altura de la tarea; de lo contrario, se encontrará en un estado constante de resolución de problemas.
Además, para tener una implementación exitosa de microservicios, necesita recursos. Para aprovechar verdaderamente la escalabilidad de los microservicios, se necesita un centro de datos con suficiente potencia para manejar esta arquitectura. En la mayoría de los casos, esto significa implementar en un host en la nube de terceros, como AmazonAWS , Google Cloud , Linode , Rackspace o Microsoft Azure . A menos que tenga un centro de datos local realmente impresionante, no alcanzará los niveles de escala que alcanzaría con uno de estos hosts.
Al final, la decisión es tuya. Pero para la mayoría de las empresas que buscan crecer mucho más allá de lo que ya han logrado, los microservicios son el camino a seguir.
Fuente: BairesDev
