This media is not supported in your browser
VIEW IN TELEGRAM
La bella y la bestia
¿Sería bueno que el código que escribimos se convirtiera automáticamente en diagramas de arquitectura?
Un repositorio de Github que hace exactamente esto: diagrama como código para la creación de prototipos de arquitecturas de sistemas en la nube.
¿Qué hace?
- Dibujar la arquitectura del sistema en la nube en código Python.
- Los diagramas también se pueden representar directamente dentro de Jupyter Notebooks.
- No se necesitan herramientas de diseño.
- Soporta los siguientes proveedores: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud, etc.
https://github.com/mingrammer/diagrams
Un repositorio de Github que hace exactamente esto: diagrama como código para la creación de prototipos de arquitecturas de sistemas en la nube.
¿Qué hace?
- Dibujar la arquitectura del sistema en la nube en código Python.
- Los diagramas también se pueden representar directamente dentro de Jupyter Notebooks.
- No se necesitan herramientas de diseño.
- Soporta los siguientes proveedores: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud, etc.
https://github.com/mingrammer/diagrams
Dejo estas notas aca para que cojan algunas buenas practicas de arquitectura de app y buenas practicas de cloud enginer o devops
Replicas de Lecturas
Para una aplicación con mucha lectura, deberíamos considerar migrar la carga de lectura para leer réplicas. Con este método, agregamos una serie de réplicas de lectura a la base de datos principal para manejar las lecturas. Podemos hacer que diferentes réplicas manejen diferentes tipos de consultas de lectura para distribuir la carga.
El inconveniente de este enfoque es el retraso en la replicación. El retraso de replicación se refiere a la diferencia de tiempo entre el momento en que se realiza una operación de escritura en la base de datos principal y el momento en que se refleja en la réplica de lectura. Cuando se produce un retraso en la replicación, puede provocar que se devuelvan datos obsoletos o inconsistentes a los clientes cuando consultan la réplica de lectura.
Si esta ligera inconsistencia es aceptable se determina caso por caso, y es una compensación por apoyar una escala cada vez mayor. Para la pequeña cantidad de operaciones que no pueden tolerar ningún retraso, esas lecturas siempre se pueden dirigir a la base de datos principal.
Para una aplicación con mucha lectura, deberíamos considerar migrar la carga de lectura para leer réplicas. Con este método, agregamos una serie de réplicas de lectura a la base de datos principal para manejar las lecturas. Podemos hacer que diferentes réplicas manejen diferentes tipos de consultas de lectura para distribuir la carga.
El inconveniente de este enfoque es el retraso en la replicación. El retraso de replicación se refiere a la diferencia de tiempo entre el momento en que se realiza una operación de escritura en la base de datos principal y el momento en que se refleja en la réplica de lectura. Cuando se produce un retraso en la replicación, puede provocar que se devuelvan datos obsoletos o inconsistentes a los clientes cuando consultan la réplica de lectura.
Si esta ligera inconsistencia es aceptable se determina caso por caso, y es una compensación por apoyar una escala cada vez mayor. Para la pequeña cantidad de operaciones que no pueden tolerar ningún retraso, esas lecturas siempre se pueden dirigir a la base de datos principal.
Cache
Otro enfoque para manejar la carga de lectura cada vez mayor es agregar una capa de almacenamiento en caché para optimizar las operaciones de lectura.
Redis es un caché en memoria popular para este propósito. Redis reduce la carga de lectura de una base de datos al almacenar en caché los datos a los que se accede con frecuencia. Esto permite un acceso más rápido a los datos ya que se recuperan del caché en lugar de la base de datos más lenta. Al realizar menos operaciones de lectura en la base de datos, Redis reduce la carga en el clúster de la base de datos y mejora su escalabilidad general. Las soluciones administradas de Redis están disponibles a través de muchos proveedores de nube, lo que reduce la carga de operar un nivel de almacenamiento en caché en el día a día.
Otro enfoque para manejar la carga de lectura cada vez mayor es agregar una capa de almacenamiento en caché para optimizar las operaciones de lectura.
Redis es un caché en memoria popular para este propósito. Redis reduce la carga de lectura de una base de datos al almacenar en caché los datos a los que se accede con frecuencia. Esto permite un acceso más rápido a los datos ya que se recuperan del caché en lugar de la base de datos más lenta. Al realizar menos operaciones de lectura en la base de datos, Redis reduce la carga en el clúster de la base de datos y mejora su escalabilidad general. Las soluciones administradas de Redis están disponibles a través de muchos proveedores de nube, lo que reduce la carga de operar un nivel de almacenamiento en caché en el día a día.
Fragmentación de bases de datos
La fragmentación de bases de datos es una técnica que se utiliza para particionar datos en varios servidores de bases de datos en función de los valores de una o más columnas de una tabla. Por ejemplo, una tabla de usuarios grande se puede dividir según el ID del usuario, lo que da como resultado varias tablas más pequeñas almacenadas en servidores de bases de datos separados. Cada servidor maneja un pequeño subconjunto de las filas que anteriormente administraba la única base de datos principal, lo que mejora el rendimiento de las consultas, ya que cada fragmento maneja un subconjunto más pequeño de datos.
Sin embargo, la fragmentación de la base de datos tiene un inconveniente importante, ya que agrega complejidad tanto a la capa de la aplicación como a la de la base de datos. Administrar y mantener un número cada vez mayor de fragmentos de bases de datos se vuelve más complejo. Los desarrolladores de aplicaciones deben implementar lógica de fragmentación en el código para garantizar que se acceda al fragmento de base de datos correcto para una consulta o transacción determinada. Si bien la fragmentación mejora el rendimiento de las consultas, también puede dificultar la realización de consultas entre fragmentos o la unión de datos de varios fragmentos. Esta limitación puede restringir los tipos de consultas que se pueden realizar.
A pesar de estos inconvenientes, la fragmentación de bases de datos es una técnica útil para mejorar la escalabilidad y el rendimiento de una base de datos grande, especialmente cuando el escalado vertical ya no es factible. Es esencial planificar e implementar la fragmentación cuidadosamente para garantizar que sus beneficios superen su complejidad y limitaciones adicionales.
La fragmentación de bases de datos es una técnica que se utiliza para particionar datos en varios servidores de bases de datos en función de los valores de una o más columnas de una tabla. Por ejemplo, una tabla de usuarios grande se puede dividir según el ID del usuario, lo que da como resultado varias tablas más pequeñas almacenadas en servidores de bases de datos separados. Cada servidor maneja un pequeño subconjunto de las filas que anteriormente administraba la única base de datos principal, lo que mejora el rendimiento de las consultas, ya que cada fragmento maneja un subconjunto más pequeño de datos.
Sin embargo, la fragmentación de la base de datos tiene un inconveniente importante, ya que agrega complejidad tanto a la capa de la aplicación como a la de la base de datos. Administrar y mantener un número cada vez mayor de fragmentos de bases de datos se vuelve más complejo. Los desarrolladores de aplicaciones deben implementar lógica de fragmentación en el código para garantizar que se acceda al fragmento de base de datos correcto para una consulta o transacción determinada. Si bien la fragmentación mejora el rendimiento de las consultas, también puede dificultar la realización de consultas entre fragmentos o la unión de datos de varios fragmentos. Esta limitación puede restringir los tipos de consultas que se pueden realizar.
A pesar de estos inconvenientes, la fragmentación de bases de datos es una técnica útil para mejorar la escalabilidad y el rendimiento de una base de datos grande, especialmente cuando el escalado vertical ya no es factible. Es esencial planificar e implementar la fragmentación cuidadosamente para garantizar que sus beneficios superen su complejidad y limitaciones adicionales.
Cambiando la carga de trabajo a NoSQL
En lugar de fragmentar la base de datos, otra solución factible es migrar un subconjunto de datos a NoSQL. Las bases de datos NoSQL ofrecen escalabilidad horizontal y altas tasas de escritura, pero a expensas de la flexibilidad del esquema en el modelo de datos. Si hay un subconjunto de datos que no depende del modelo relacional, migrar ese subconjunto a una base de datos NoSQL podría ser un enfoque eficaz para escalar la aplicación.
Este enfoque reduce la carga de lectura en la base de datos relacional, lo que le permite centrarse en consultas más complejas mientras la base de datos NoSQL maneja cargas de trabajo de alta escritura. Es importante considerar cuidadosamente qué subconjunto de datos se migra, y el proceso de migración debe planificarse y ejecutarse cuidadosamente para evitar inconsistencias o pérdidas de datos.
En lugar de fragmentar la base de datos, otra solución factible es migrar un subconjunto de datos a NoSQL. Las bases de datos NoSQL ofrecen escalabilidad horizontal y altas tasas de escritura, pero a expensas de la flexibilidad del esquema en el modelo de datos. Si hay un subconjunto de datos que no depende del modelo relacional, migrar ese subconjunto a una base de datos NoSQL podría ser un enfoque eficaz para escalar la aplicación.
Este enfoque reduce la carga de lectura en la base de datos relacional, lo que le permite centrarse en consultas más complejas mientras la base de datos NoSQL maneja cargas de trabajo de alta escritura. Es importante considerar cuidadosamente qué subconjunto de datos se migra, y el proceso de migración debe planificarse y ejecutarse cuidadosamente para evitar inconsistencias o pérdidas de datos.
Blog de ArmandoF
para que entiendan cual ha sido la evolucion SysAdmin -> DevOps -> SRE -> Cloud Engineer
DevOps como concepto fue presentado en 2009 por Patrick Debois y Andrew Shafer en la conferencia Agile. Buscaban cerrar la brecha entre el desarrollo y las operaciones de software promoviendo una cultura colaborativa y una responsabilidad compartida durante todo el ciclo de vida del desarrollo de software.
Google fue pionero en SRE, o ingeniería de confiabilidad del sitio, a principios de la década de 2000 para abordar los desafíos operativos en la gestión de sistemas complejos a gran escala. Google desarrolló prácticas y herramientas de SRE, como el sistema de gestión de clústeres Borg y el sistema de monitoreo Monarch, para mejorar la confiabilidad y eficiencia de sus servicios.
La ingeniería de plataformas es un concepto más reciente que se basa en la ingeniería SRE. Los orígenes precisos de la ingeniería de plataformas son menos claros, pero generalmente se entiende como una extensión de las prácticas de DevOps y SRE, con un enfoque en ofrecer una plataforma integral para el desarrollo de productos que respalde toda la perspectiva empresarial.
Vale la pena señalar que si bien estos conceptos surgieron en diferentes momentos. Todos ellos están relacionados con la tendencia más amplia de mejorar la colaboración, la automatización y la eficiencia en el desarrollo y las operaciones de software.
Google fue pionero en SRE, o ingeniería de confiabilidad del sitio, a principios de la década de 2000 para abordar los desafíos operativos en la gestión de sistemas complejos a gran escala. Google desarrolló prácticas y herramientas de SRE, como el sistema de gestión de clústeres Borg y el sistema de monitoreo Monarch, para mejorar la confiabilidad y eficiencia de sus servicios.
La ingeniería de plataformas es un concepto más reciente que se basa en la ingeniería SRE. Los orígenes precisos de la ingeniería de plataformas son menos claros, pero generalmente se entiende como una extensión de las prácticas de DevOps y SRE, con un enfoque en ofrecer una plataforma integral para el desarrollo de productos que respalde toda la perspectiva empresarial.
Vale la pena señalar que si bien estos conceptos surgieron en diferentes momentos. Todos ellos están relacionados con la tendencia más amplia de mejorar la colaboración, la automatización y la eficiencia en el desarrollo y las operaciones de software.