División de la aplicación de rieles monolíticos en microservicios

A medida que una empresa crece, requiere más funcionalidades y, por lo tanto, no puede evitar agregar nuevos modelos/controladores a la aplicación Rails existente y, a veces, se convierte en un monolito. Si se enfrenta a una aplicación monolítica que se ha vuelto imposible de mantener y difícil de implementar, necesita conocer algunas formas de administrarla. Si tu equipo tiene que recorrer miles de líneas para entender el proyecto y realizar algunos cambios, es hora de dividirlas.

Cuando dividir la aplicación

• Cuando sus pruebas se ejecutan durante más de 20 minutos.
• Los modelos crecieron a varios cientos o miles.
• Funcionalidad independiente.
• Cuando los desarrolladores no pueden trabajar de forma independiente para desarrollar/implementar sus propios módulos.

Diferentes formas de dividir una aplicación monolítica

• Usando microservicios.
• Using ‘faster’ technologies.
• Agrega un montón de servidores.

¿Qué es el microservicio?                                                                                                                                           Los microservicios son una forma estratégica de descomponer un proyecto grande en partes más pequeñas y manejables. Un microservicio es una pieza de funcionalidad de la aplicación refactorizada en su propia base de código, que se comunica con otros microservicios a través de un protocolo estándar. Para lograr esto, primero divida sus requisitos comerciales en grupos relacionados, como lógica de administración de usuarios, lógica publicitaria y una interfaz de usuario web.

Por que microservicio
The first force that led to the surge in microservices was a reaction against normal monolithic architecture. While a monolithic app is One Big Program with many responsibilities, microservice-based applications are composed of smaller programs, each with a single responsibility. This allows teams of devs to work independently on different services. The inherent decoupling also encourages smaller, simpler programs that are easier to understand, so new devs can start contributing more quickly. Finally, since no single program represents the whole of application, services can change direction without massive costs. If new technology becomes available that makes more sense for a particular service, it’s feasible to rewrite just that service. Similarly, since microservices communicate across a different languages, an application can be composed of several different platforms – Ruby, Java, PHP, Node, Go, etc without any issue.

Ventajas

• Los módulos se pueden reutilizar.
• La implementación se realiza sin problemas, independientemente de toda la gran aplicación.
• Funciones fáciles de agregar.
• Reduce el tiempo de prueba para probar un módulo en lugar de todos.
• Las aplicaciones grandes tienden a ser más difíciles de mantener que las pequeñas.
• Tener un conjunto de pequeñas aplicaciones nos permite centrarnos en trabajar en piezas aisladas.
• Es posible que tengamos más posibilidades de no dañar otras partes de la aplicación.
• Fiabilidad y tolerancia a fallos.
• Fácil de migrar o actualizar.
• Diversidad tecnológica.
• Si alguna función de la aplicación no funciona, la aplicación completa no se cae.
• Facilita que un nuevo desarrollador comprenda la funcionalidad de un servicio.

Desventajas
Because everything is now an independent service, you have to handle requests carefully travelling between your modules. There can be a scenario where any of services may not be responding.
Multiple databases and transaction management can be painful.
Productivity will be less till the microservice base is set.

Microservicios monolíticos versus s
El siguiente diagrama muestra la diferencia entre la aplicación monolítica tradicional y los microservicios en términos de recursos humanos, tiempo, mantenimiento y complejidad de manejo de las aplicaciones.

Cómo configurar microservicios
Una forma estratégica de reducir la aplicación monolítica es dividir capas como presentación, lógica empresarial y acceso a datos. Una aplicación empresarial típica consta de al menos tres tipos diferentes de componentes:

• Presentation layer – Components that handle HTTP requests and implement either a (REST) API or an
  HTML-based web UI. In an application that has a sophisticated user interface.
• Capa de lógica empresarial: componentes que son el núcleo de la aplicación donde se implementan las reglas comerciales.
• Capa de acceso a datos: componentes que tienen acceso a componentes de infraestructura, como bases de datos y intermediarios de mensajes.

RailsCarma ha estado implementando aplicaciones Ruby on Rails desde sus etapas iniciales para desarrollo, capacitación, implementación y contribución a la comunidad Rails. A través de experiencia técnica confiable y un servicio al cliente consumado combinados para brindar una experiencia placentera a los clientes, RailsCarma brinda servicios de extremo a extremo. Desarrollo de Ruby on Rails,consultoría, arquitectura, gestión y extensión a empresas de todo el mundo. Contáctanos para saber más.