La edad del monolito

Introducción a los microservicios.

Stonehenge (imagen descargada de Internet puede tener derechos).

Monolito, ademas de hacer referencia a una piedra enorme, es un termino técnico usado para identificar un tipo en particular de aplicación. Una aplicación monolítica tiene todos sus componentes viviendo juntos como una unidad. Una aplicación web es un programa de software corriendo en un servidor web. Una aplicación consiste de tres componentes principales:

  • Interfaz de usuario (UI)
  • Base de datos
  • Servidor

Una aplicación monolítica contiene todos estos tres componentes y es escrita y liberada como un sola unidad. Internamente, el código base puede ser modular, pero los componentes todo son entregados juntos y solamente están diseñados para trabajar dentro de la misma aplicación.

Recordemos los inicios del “internet”, más o menos por el año de 1995. En ese tiempo, puede ser que pienses en ti y tus amigos juntando los CDs — de la famosa compañía en aquel tiempo American On Line (AOL), para conectarte a internet, revisar tu correo y hacer manualidades.

Ejemplo de una manualidad con los CDs de AOL.

Con el paso de los años y la evolución del internet, los CDs de AOL solo eran buenos para eso, para hacer manualidades. El CD de AOL contenía una aplicación y esa aplicación era un monolito. Esta era un pieza de software auto-contenida que era capaz de correr — de manera independiente , por si misma. Para poder actualizar la version de AOL, tenias que obtener un CD completamente nuevo y reemplazar el programa. Así es como un monolito maneja sus ciclos de liberación de software (el proceso en el cual una aplicación es actualizado o modificado) — el programa entero debe ser reemplazado y así es como también las primeras aplicaciones web fueron diseñadas.

Si avanzamos rápidamente a días presentes y a la compra de modernos equipos de computo, pensemos que estas máquinas vienen con una gran cantidad de software pre instalado y al conectarse a Internet tienes que esperar, dependiendo de tu conexión, un par de horas o minutos, instalando actualizaciones a ese software.

Este software que esta siendo actualizado son un ejemplo de aplicaciones monolíticas, que pueden ser actualizadas, pieza por pieza, este es un ejemplo de como las aplicaciones han cambiado desde los días de los Cds de AOL.

Para aquellos jóvenes que leen este artículo y no conocieron los CDs de AOL eran algo así (los regalaban afuera de las estaciones del metro).

AOL Cd

Ventajas del monolito

Similar a las aplicaciones de escritorio que fueron diseñadas para ser entregadas a través de medios como los discos de 3 1/2 (floppy disks) o discos compactos y luego ser instalados en el escritorio, las aplicaciones web monolíticas fueron diseñadas primero para ser auto contenidas y tener todo los que el usuario necesitase para lograr su trabajo.

Podía ser más fácil entregar aplicaciones monolíticas por que toda la funcionalidad estaba en un solo lugar. Y cuando las pruebas eran ejecutadas, aun si el diseño interno de la aplicación era modular, externamente solo existe o existía una entidad a probar.

Es menos complicado hacer que la aplicación corra en el servidor. El proceso de mover la aplicación de la laptop del desarrollador al ambiente de pruebas, y eventualmente a producción, es generalmente definido como la entrega de software.

Si existe un incremento en la demanda de la aplicación, entonces más copias pueden ser entregadas detrás de un sistema llamado balanceador de cargas. El balanceador de cargas entonces distribuirá las peticiones a cualquier servidor disponible.

Desventajas del monolito

Si la aplicación crece en complejidad, en líneas de código y en el número de características, los desarrolladores que han estado alrededor por más tiempo seguramente serán los más efectivos para realizar cambios. Y a los nuevos desarrolladores, tomará mas tiempo subirlos al barco, por que ellos necesitan entender un sistema grande para ser efectivos.

Desde que la aplicación es tan grande, la habilidad de hacer cambios importantes llega a ser más difícil también. Un desarrollador necesita probar todos y cada uno de los cambios en los que trabaja y probar el sistema entero antes de tener la confianza de liberar los cambios a producción. Como resultado, es mucho más difícil adoptar nuevas tecnologías, por que el sistema entero se ve comprometido.

Cuando el tamaño de la aplicación es menor, es más rápido de entregar. Ahora que la aplicación ha crecido a un nuevo tamaño y correo en muchos servidores, el tiempo que toma hacer las entregas es más largo. Cada cambio, grande o pequeño, requiere que la aplicación entera sea entregada de nuevo.

El tiempo no solo incrementa cuando se quiere liberar a producción, por que este necesita ser probado primero. Si este ya es más lento para entregar en producción, es lento para ser entregado a cualquier ambiente que es usado para pruebas antes de ser entregado a producción.

Las aplicaciones monolíticas ciertamente tienen su lugar cuando tienes una aplicación simple que sirve a un propósito básico. Cuando tu aplicación necesita crecer, cambiar, ejecutarse bien, el monolito no es más una buena opción y será tiempo de voltear a ver los microservicios.

Del sitio de microservices.io obtenemos:

Microservices — también conocido como arquitectura de microservicios — es un estilo de arquitectura que estructura una aplicación como una colección de servicios que son: altamente mantenibles y altamente testeables, desacoplados (loosely coupled) , entregables de manera independiente (independently deployable) y organizados alrededor de las capacidades del negocio.

La arquitectura de micro servicios permite la entrega continua y deployment de grandes y complejas aplicaciones. Esta también permite que la organización evoluciones su stack tecnológico.

Una “arquitectura de microservicios” es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno ejecutándose de forma autónoma y comunicándose entre sí.

Introducción al Microservicio

Partes individuales de la aplicación necesitan ser divididas en sus funciones independientes. Estas también necesitan ser capaces de conectar con las otras partes. Cada uno de estos pequeños servicios (o micro servicios, como se conocen ahora) son pequeñas aplicaciones que contienen piezas bien definidas de lo que fue alguna vez un monolito.

Para trabajar juntos, los servicios necesitarán hablarse entre ellos. Las reglas de interacción entre los componentes son llamadas APIs ( Application Programmer Interface).

Con monolitos, las piezas diversas de la aplicación típicamente comparten una sola base de datos. Los microservicios normalmente no comparten base datos, cada microservicio es responsable de su propio almacenamiento. La comunicación entre micro servicios es realizada via la API, en lugar de una base de datos compartida.

Tener una base de datos separada para cada servicio asegura que se desacople (loose coupling), lo cual permite que los servicios se ajusten entre si. Con esta separación podemos decidir si algunos servicios necesitan diferentes bases de datos.

Las aplicaciones que han sido divididas a través de muchos servicios (y por lo tanto muchos servidores) son llamados sistemas distribuidos. Algunos servicios son visibles al usuario, mientras que otros son solo usados internamente por otros servicios. Este ultimo son llamados servicios back-end.

Sercicios back-end.

Ventajas de los microservicios

Descomponer la aplicación en pedazos más manejables hacen todo el código fuente más sencillo de entender, desarrollar y mantener. A la medida que l aplicación crece, podemos dedicar equipos enteros a servicios particulares. Cada equipo se concentra en un solo servicio, en vez de toda la aplicación.

Tan pronto como cada componente pueda permanecer desacoplado con otros servicios en el sistema, cada equipo tendrá la libertad de desarrollar como vea que encaja. Por lo tanto, la barrera de adoptar nuevas tecnologías, entornos de trabajo o lenguajes se hace mucho mas baja.

Ahora, cada entrega puede ser controlada al nivel del servicio, no a nivel del sistema. Rompiendo la gran y monolítica entrega o deployment en separadas y mucha más pequeñas entregas, para los desarrolladores sera más fácil hacer cambios, correr las pruebas y enviarlas a producción.

Aún escalar cada uno de los servicios es más fácil ahora. Cada componente puede ser monitoreado y tener la cantidad correcta de recursos, en lugar de agregar un servidor completo para soportar las nuevas características.

Desventajas de los microservicios.

En algunas ocasiones puede ser más difícil solucionar problemas de servicios separados que si fueran solo un monolito. Pero esto se puede superar si tienes las herramientas correctas y la tecnología en su lugar.

Por ejemplo, Cloud Foundry lo hace más sencillo (pero ese es tema de otro artículo), juntando los logs y poniéndolos a nuestra disposición a través de la línea de comandos.

Cada microservicio en tu sistema es responsable de su propia base de datos o algún otro almacenamiento. Esto crea el potencial de tener datos duplicados a los largo de los multiples servicios. La solución es dibujar los limites de los servicios en los lugares correctos y siempre asegurar que cualquier dato en particular tenga una sola fuente de verdad.

También realizar las pruebas de aplicaciones con arquitectura de micro servicios son más complejas que hacer pruebas en un monolito.

Si el servicio A se basa en el servicio B, entonces el equipo de pruebas del servicio A debe proveer una instancia del servicio B para realizar pruebas con este o proveer una versión simplificada de B como placeholder. Estos placeholders son llamados talones (stubs) .

Dividir las cosas en partes más pequeñas puede llegar muy lejos. Y sabrán que han llegado demasiado lejos cuando los gastos generales — overhead, (comunicaciones, mantenimiento, etc.) superan la utilidad. En lugar, podemos ver la posibilidad de combinar los servicios en back con otros que sean similares.

En conclusión

Tanto el desarrollo como la entrega de las aplicaciones web ha cambiado mucho en los últimos 20 años. Para la entrega de aplicaciones web modernas. los desarrolladores están usando las nubes. Y esto requiere una aproximación cloud-native. Todo lo que significa es que el sistema puede ser dividido en muchas partes, luego distribuido en muchas piezas y comunicarse a través de Internet.

Cloud Native (Imagen de Internet, puede tener derechos).

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.