En noviembre, OTUS lanza un nuevo programa educativo, "Arquitecto de software", en relación con esto, continuamos una serie de publicaciones para futuros estudiantes del curso y lectores de nuestro blog.
Lee la primera parte
Arquitectura de microservicios
Los microservicios son un tipo de arquitectura de software orientada a servicios que se centra en la creación de una serie de componentes independientes que componen la aplicación. A diferencia de las aplicaciones monolíticas creadas en su conjunto, las aplicaciones de microservicio consisten en varios componentes independientes que se unen a través de la API.
La estructura de microservicios y arquitectura monolítica en comparación.El enfoque de microservicio se centra principalmente en las prioridades y oportunidades comerciales, mientras que el enfoque monolítico se organiza en torno a niveles de tecnología, interfaces de usuario y bases de datos. El enfoque del microservicio se ha convertido en una tendencia en los últimos años a medida que más y más empresas se vuelven más flexibles y cambian a DevOps.
Los microservicios son importantes simplemente porque agregan un valor único para el cliente al simplificar los sistemas. Al dividir su sistema o aplicación en muchas partes más pequeñas, está implementando una forma de reducir la duplicación, aumentar la consistencia y reducir la comunicación entre las partes, lo que hace que sus partes comunes del sistema sean más comprensibles, más escalables y más fáciles de cambiar.
Lucas Kraus, autor de Microservicios
Hay muchos ejemplos de empresas que han evolucionado desde un enfoque monolítico a los microservicios. Entre los más conocidos se encuentran Netflix, Amazon, Twitter, eBay y PayPal. Para determinar si los microservicios son apropiados para su proyecto, identifiquemos los pros y los contras de este enfoque.
Pros de microservicios
Fácil de desarrollar, probar e implementar
La mayor ventaja de los microservicios sobre otras arquitecturas es que los pequeños servicios individuales se pueden crear, probar e implementar de forma independiente. Debido a que la unidad de implementación es pequeña, hace que el desarrollo y el lanzamiento sean más fáciles y rápidos. Además, el lanzamiento de una unidad no se limita al lanzamiento de otra, que aún no está completa. Y la última ventaja aquí es que los riesgos de implementación se reducen a medida que los desarrolladores lanzan partes del software, no toda la aplicación.
Mayor flexibilidad
Con la ayuda de microservicios, varios equipos pueden trabajar en sus servicios de forma independiente y rápida. Cada parte individual de la aplicación se puede construir de forma independiente debido al aislamiento de los componentes del microservicio. Por ejemplo, puede tener un equipo de 100 personas trabajando en toda la aplicación (como en un enfoque monolítico), o puede tener 10 equipos de 10 personas desarrollando diversos servicios.
Imaginemos visualmente.
La mayor flexibilidad permite a los desarrolladores actualizar los componentes del sistema sin cerrar la aplicación. Además, la flexibilidad proporciona un proceso de implementación más seguro y un mayor tiempo de actividad. Se pueden agregar nuevas funciones según sea necesario sin esperar a que se inicie toda la aplicación.
La capacidad de escalar horizontalmente
El escalado vertical (usando el mismo software, pero en máquinas más potentes) puede estar limitado por el ancho de banda de cada servicio. Pero el escalado horizontal (la creación de más servicios en un grupo) no está limitado y puede funcionar con microservicios dinámicamente. Además, el escalado horizontal puede ser totalmente automatizado.
Contras de microservicios
Dificultad
La mayor desventaja de los microservicios es su complejidad. La separación de la aplicación en microservicios independientes implica más artefactos de control. Este tipo de arquitectura requiere una planificación cuidadosa, un esfuerzo tremendo, recursos y habilidades de equipo. Las razones de la alta complejidad son las siguientes:
- Mayor demanda de automatización, ya que cada servicio debe ser verificado y controlado
- Las herramientas disponibles no funcionan con dependencias de servicio
- La coherencia de los datos y la gestión de transacciones se está volviendo más difícil ya que cada servicio tiene una base de datos
Preocupaciones de seguridad
En una aplicación de microservicio, cada funcionalidad que interactúa a través de la API desde el exterior aumenta la probabilidad de ataques. Estos ataques solo pueden ocurrir si no se toman las medidas de seguridad adecuadas al crear la aplicación.
Diferentes lenguajes de programación
La capacidad de elegir diferentes lenguajes de programación es una espada de doble filo. El uso de diferentes idiomas complica la implementación. Además, es más difícil cambiar los programadores entre etapas de desarrollo, cuando cada servicio está escrito en un idioma diferente.
Al final
Los microservicios son buenos, pero no para todo tipo de aplicaciones. Esta plantilla es ideal para desarrollar aplicaciones y sistemas complejos. Puede pensar en elegir una arquitectura de microservicio cuando tenga varios equipos experimentados y cuando la aplicación sea lo suficientemente compleja como para dividirla en servicios. Cuando una aplicación es grande y necesita ser flexible y escalable, una arquitectura de microservicio es beneficiosa.
Ahora podemos comparar estas tres arquitecturas de software para identificar visualmente las diferencias entre ellas.
Las aplicaciones monolíticas consisten en bloques interdependientes e indivisibles y tienen una velocidad de desarrollo muy baja. SOA se desglosa en servicios más pequeños y moderadamente relacionados y su desarrollo es lento. Los microservicios son servicios independientes muy pequeños y poco acoplados que se caracterizan por un desarrollo rápido y una integración continua.
Arquitectura sin servidor
La arquitectura sin servidor es un enfoque de computación en la nube para crear y ejecutar aplicaciones y servicios sin la necesidad de una administración de infraestructura. En las aplicaciones sin servidor, la ejecución de código está impulsada por la plataforma, lo que permite a los desarrolladores implementar código sin preocuparse por el mantenimiento y el mantenimiento del servidor. De hecho, la falta de servidor no significa "sin servidor". La aplicación aún se ejecuta en los servidores, pero un servicio en la nube de terceros como AWS es totalmente responsable de estos servidores. La arquitectura sin servidor elimina la necesidad de recursos adicionales, escalado de aplicaciones, mantenimiento de servidores y sistemas de almacenamiento y bases de datos.
La arquitectura sin servidor incluye dos conceptos:
- FaaS (Function as a Service) es un modelo de computación en la nube que permite a los desarrolladores cargar partes de la funcionalidad en la nube y permite que estas partes se ejecuten de forma independiente
- BaaS (Backend as a Service) es un modelo de computación en la nube que permite a los desarrolladores externalizar aspectos de back-end (gestión de bases de datos, almacenamiento en la nube, alojamiento, autenticación de usuarios, etc.), así como escribir y admitir solo una parte interfaz externa
Así es como se ve una estructura sin servidorUtilizando una arquitectura sin servidor, los desarrolladores pueden centrarse en el producto en sí sin preocuparse por la administración del servidor o los tiempos de ejecución. Esto permite a los desarrolladores concentrarse en desarrollar productos con alta confiabilidad y escalabilidad.
Hay muchos proveedores de soluciones en la nube en el mercado. Estos son algunos de los principales proveedores de informática sin servidor:
Principales proveedores de informática sin servidorPara averiguar si este tipo de arquitectura es necesaria para su proyecto, determinemos las ventajas y desventajas de implementar un modelo sin un servidor.
Ventajas de la arquitectura sin servidor
Fácil de implementar
En las aplicaciones sin servidor, los desarrolladores no necesitan preocuparse por la infraestructura. Esto les permite enfocarse en el código mismo. La arquitectura sin servidor le permite implementar rápidamente una aplicación, ya que la implementación toma solo unas pocas horas o días (en comparación con días o semanas con el enfoque tradicional).
Reducción de costos
El cambio a la arquitectura sin servidor reduce los costos. Dado que no necesita procesar bases de datos, algunos lógicos y servidores, no solo puede crear un mejor código, sino también reducir costos. Cuando usa un modelo sin servidor, solo paga por los ciclos de CPU y la memoria que realmente usa.
Escalabilidad mejorada
Muchos propietarios de negocios quieren que sus aplicaciones sean potentes y escalables, como Google o Facebook. La informática sin servidor hace que el escalado sea automático y fluido. Su aplicación se escalará automáticamente cuando aumente la carga o la base de usuarios, sin afectar el rendimiento. Las aplicaciones sin servidor pueden manejar una gran cantidad de solicitudes, mientras que las aplicaciones tradicionales se sobrecargarán con su repentino aumento.
Desventajas de la arquitectura sin servidor
Proveedor vinculante
La vinculación del proveedor describe una situación en la que le otorga al proveedor un control completo sobre sus operaciones. Como resultado, los cambios en la lógica empresarial son limitados y la migración de un proveedor a otro puede ser difícil.
No para tareas a largo plazo.
El modelo sin servidor no es adecuado para operaciones largas. Las aplicaciones sin servidor son buenas para procesos cortos en tiempo real, pero si la tarea lleva más de cinco minutos, la aplicación sin servidor requerirá características FaaS adicionales.
Al final
La arquitectura de software sin servidor es útil para resolver tareas únicas y procesos de soporte. Funciona muy bien para aplicaciones ricas en clientes y aplicaciones que crecen rápidamente y necesitan escala ilimitada.
Finalmente, veamos la siguiente imagen para saber cuándo elegir cada uno de estos cuatro tipos de arquitectura:
Elegir la arquitectura adecuada para su MVP es un desafío, pero RubyGarage tiene muchos años de experiencia para ayudarlo con su elección. El autor del artículo estará encantado de responder todas sus preguntas sobre este tema.