Todo sistema requiere de una arquitectura que defina su diseño para asegurar un funcionamiento estable, así como su escalabilidad en crecimiento y mantenimiento.
En Podemos los sistemas que sustentan nuestra infraestructura tecnológica no son la excepción, y en este breve post pasamos a detallar algunos aspectos importantes de la arquitectura que define el diseño de la mayoría de nuestros sistemas.
Básicamente, la arquitectura en Podemos TI entra en lo que se conoce como arquitectura en capas, en tres capas específicamente. Las clásicas Modelo (datos), Control (negocio) y Presentación (interfaz).
Antes de detallar cada una, tenemos también unos principios que respetamos siempre, nos los tomamos muy en serio, cuando se trata de integrar las distintas capas:
- Independencia de capas. Ninguna capa debería depender de la existencia de alguna otra para existir, de forma que exista un bajo acoplamiento entre cada capa y podamos sustituir un pedazo de alguna sin afectar a otra de la manera lo más limpia posible. Por supuesto, como veremos, una capa de interfaz necesariamente depende de una de Control para funcionar, pero esto solamente es a nivel del consumo de las APIs que proporciona cada capa inferior.
- Especificidad de capas. Como corolario de esto último, el código que pertenezca a una capa específica debe tener prohibido terminantemente realizar funciones de una capa distinta a la que pertenece. Y como consecuencia logramos que el código no repita funciones innecesariamente. Aquí promovemos el principio DRY, entre capas por lo menos.
- Comunicación entre capas. APIs, todo son APIs, para que cada capa se comunique limpiamente con las otras, deben existir APIs bien definidas, limpias, escalables, probadas, de forma que el acoplamiento baje aún más. El hecho de que sean escalables implica que la API de una capa inferior pudiera cambiar en los detalles de implementación, sin que la capa superior se inmute ni se vea afectada.
- Jerarquía de capas. Las capas están jerarquizadas de una manera muy estricta. De esta forma, cada capa sólo debe poder comunicarse con la capa inmediatamente inferior a través de sus APIs, y proporcionar sus propias APIs a la capa inmediatamente superior.
Modelo
El rol del modelo, los datos que sustentan todo nuestro negocio, residen en esta capa. Básicamente se trata de nuestras bases de datos y las APIs con que accedemos a los datos.
Bueno, tenemos que aclarar algo, no siempre tenemos la base de datos con nosotros. En ese caso accedemos a los datos usando las APIs que un SaaS nos proporciona. Básicamente, esto es MambuPy (aunque MambuPy también tiene su propio ORM diseñado para acceder a respaldos de la base de datos del SaaS, funcionando entonces como cualquier API ORM del resto de nuestros sistemas).
Nuestras bases de datos son principalmente relacionales (aunque incursionamos un poco en NoSQL también). Para el caso de las clásicas E-R, las APIs que el Modelo proporciona a la capa inmediatamente superior consisten en ORMs.
Y como nuestro stack de tecnología depende en gran medida de Python, usamos SQLAlchemy para esto último.
Control
En esta capa reside todo el negocio de Podemos. Básicamente es un conjunto de paquetes y módulos con APIs de Python que pueden ser importadas por cualquier interfaz (incluyendo otras APIs).
Siguiendo el principio de la jerarquía de capas, esta es la única que tiene permitido acceder a la capa inferior, la del Modelo, para acceder y modificar los datos, a través de los ORMs.
La capa de control es la más variopinta de todas, cubre innumerables funciones y puede utilizar una gran variedad de librerías, dependiendo de la necesidad de cada módulo del sistema.
Presentación
La capa más externa es la interfaz o presentación. Sin embargo algunos sistemas en esta capa son interfaces pero no necesariamente amigables a un usuario final, puede tratarse de APIs.
Un ejemplo claro de esto último es el conjunto de APIs REST de Podemos, que solo funcionan como 'interfaz' a la capa de control inferior, pero proporcionan información a manera de objetos JSON que pueden ser consumidos a su vez por otras aplicaciones.
En cuanto a tecnología, también usamos una gran variedad. Django para las aplicaciones web y la API REST. Cordova para las aplicaciones móviles. La librería Argparse para nuestras CLIs...
Siguiendo estas definiciones y aplicando los principios antes mencionados, la arquitectura de los sistemas en Podemos tienen por lo general la estructura de una cebolla dividida en capas, como se puede apreciar a continuación:
Niveles
Por otro lado, la arquitectura está organizada en dos niveles, cliente-servidor.
El cliente suele ser una máquina en la que despliega la interfaz de una aplicación web, o móvil, aunque también puede ser una aplicación de consola, con CLI o un demonio que se ejecuta en segundo plano.
Mientras tanto en el servidor residen tanto las capas de control como de datos.
Puedes encontrar más información acerca de este tipo de arquitectura, en este breve artículo en wikipedia.