arquitecturas evolutivas

ARQUITECTURAS EVOLUTIVAS

Vamos hablar de las arquitecturas evolutivas o arquitecturas ágiles, de dónde surge su necesidad de implementación, su rol versus la forma tradicional de ver a la arquitectura de software, los problemas que resuelve, y vamos a analizar las líneas base y las prácticas relacionadas para implementarlas.

“… es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución”

Arquitectura de Software

Bueno y esto para que nos sirve dentro del desarrollo de software; porque podemos realizar aproximaciones a nuestro problema mediante la abstracción y el entendimiento del mismo.

Forma tradicional

Cuándo queremos iniciar un proceso de desarrollo de software en la manera tradicional tratamos de entender el problema lo más posible, tratando de contemplar todos los problemas a los que nos vamos a enfrentar, hacemos predicciones de aquello que se puede presentar y las posibles soluciones hacia ello. Y por consecuencia lo primero que hacemos es el plano bajo el cuál nos vamos a amparar en todo el proceso de desarrollo. Definimos un marco sobre el cuál se deberían construir las aplicaciones, sistemas o módulos. Todo parece ir bien

Esperado vs Real

A medida que el proyecto avanza, evidenciamos que los supuestos que nos imaginamos, nunca se dieron, y nuestro proyecto más complejo de lo que debería, en donde invertimos tiempo y esfuerzo en un diseño que no se necesitó, y tiempo y esfuerzo en la etapa de desarrollo tratando que la construcción calce con el diseño, sin embargo esto no siempre es factible y nuestra solución comienza a tomar formas diferentes a las esperadas. Por otro lado, a medida que el proyecto avanza surgen nuevas necesidades que nunca fueron consideradas, no por una mala planificación si no porque simplemente no somos adivinos, y tratar de incluir estos aspectos en una etapa intermedia es una encrucijada, más aún cuando estos aparecen en una etapa avanzada.

El cambio es una realidad y complica

Hemos evidenciado que el cambio es una realidad sino en todos, en la mayoría de los proyectos de software que nos hemos visto involucrados. Si ya es dificil y costoso introducir cambios a funcionalidades en los requerimientos de usuario, imaginemos la magnitud en introducir cambios en la arquitectura que nos hemos planteado desde el inicio. Simplemente hay ocasiones en las que no se puede, es imposible, entonces comenzamos a martillar con un destornillador o atornillar con un martillo, ¿Funciona? quizás a veces y si simplemente no funciona?

El mundo de la tecnología y el software a avanzado tanto que tenemos herramientas para todo y que unas funcionan mejor para ciertos problemas que otras, entonces porque no hacer uso de estas y aprovechar sus beneficios para agregar valor, en lugar de encasillarnos con la elegida que generalmente fue escogida por motivos de estandarización y porque así lo dijo el entonces gurú del asunto, o también es por toda la plataforma empresarial que adquirimos y tenemos que darle sentido a tanta inversión. Aquí el ejemplo de haber seleccionado una BDD relacional como estándar y de repente queremos manejar documentos en xml, o data inmutable que puede ser tratada con una base no relacional, porque limitarnos a las capacidades de unas pocas herramientas si tenemos un mundo que nos puede hacer esto más fácil.

t

Arquitectura EsperadaRealidad

t

Tradicional

Agile

Las restricciones de las arquitecturas se mantienen en el tiempo y lo que se definió como la arquitectura en un momento después de un para de años luce muy diferente, lo que nos lleva a la conclusión que las arquitecturas cambian, se redefinen, entonces porque no darles esa facilidad desde un inicio, porque tratamos incesantemente de idear todo desde el inicio, cuando podemos ir creciendo paulatinamente.

Muchas veces se ha tratado de establecer un símil entre la ingeniería de software y las demás disciplinas de la ingeniería, sin embargo lo que nosotros buscamos no es precisamente eso. Hemos evidenciado que en el mundo del desarrollo existen prácticas probadas que han generado buenos resultados, ir de lo pequeño a lo grande, xp, piar programming, tratar de construir conocimiento granularmente a medida que el proyecto avanza, no tratamos de hacer analogías con otras disciplinas de la ingeniería, tratamos de hacer lo que hemos visto que funciona en este mundo, dejemos que el diseño sea algo que emerge, que la arquitectura sea algo que evolucione a medida que se necesita

Charles Darwin

En definitiva porque en lugar de seguir tratando de contemplar lo incontemplable, de predecir lo impredecible, nos enfocamos mejor en que sea menos costoso realizar cambios, y en lugar de predecir, nos concentremos en reaccionar al futuro. La única certeza que tenemos es que no hay certezas, el cambio es lo único que permanece en el tiempo.

Diseño Emergente

Requerimientos específicos y cortos Test based Encontrar abstracciones y patrones. Se puede buscar métodos que se llamen o empiecen con las mismas palabras para ver que el código se esté repitiendo (con un simple grep se lo puede hacer) Harvesting idiomatic patterns: (Hay una herramienta que sirve para esta nota CKJM) cyclomatic complexity Coupling Afferent (incoming): cuantos dependen de mí (Nos dice cuales son las clases más importantes) Efferente (outcoming): de cuantos dependo: Cosechar frameworks en lugar de construirlos !Las responsible moment to make decisions: por cada decisión importante que tengas que hacer tienes que preguntarte: hay una forma segura en la que pueda tomar esa decisión o puede ser más tarde, porque mientras más tarde se pueda tomar esa decisión, más elementos de juicio tendrás para acertar. [The longer the delay => more relevant data for decision] Tenemos que juntar lo más que se pueda de información para tomar una decisión.

Reducir el Acoplamiento

El principal factor para que el cambio sea tan difícil es el acoplamiento Lo que más restricciones y más dificultades presenta en los proyectos de software para que la arquitectura cambie y evolucione es el acoplamiento, la dependencia que se tiene entre componentes, sea de entrada o de salida. El acoplamiento es lo que enreda las cosas y evita que podamos cambiar, es lo que nos fuerza a que tratemos de seguir haciendo lo mismo.

CÓMO

Micro ServiciosEntrega Continua

Entonces para permitir que la arquitectura evolucione más fácilmente, lo que tenemos que hacer primordialmente es evitar el acoplamiento sea entre componentes o acoplamiento a las tecnologías. Que cuándo después de años decidamos que hay algo mejor, el cambiar de tecnología no sea un proceso duro. !!Esto lo podemos hacer mediante el uso de micro servicios y entrega continua.

Entrega Continua

La entrega continua nos permite tomar un requerimiento del cliente, diseñar una solución (en nuestro caso sería definir ciertos aspectos de la arquitectura) y basándonos en la automatización de pruebas y la integración continua poder llegar a los usuarios rápida y eficazmente.

Integración Continua

La entrega continua nos permite tomar un requerimiento del cliente, diseñar una solución (en nuestro caso sería definir ciertos aspectos de la arquitectura) y basándonos en la automatización de pruebas y la integración continua poder llegar a los usuarios rápida y eficazmente.

Automatización de pruebas

De esta manera podemos probar teorías y diseños y adaptarnos al cambio. Como bien decíamos antes, reduciremos acoplamiento, ya que trataremos coma característica de la solución independientemente. Las pruebas también nos pueden ayudar a reducir este acoplamiento, ya que lo que buscan es la validación de que esta funcionalidad funciona independientemente y en conjunto con el resto del sistema.

Aplicaciones Monolíticas

Aplicación

HTML, JS, etc.

Se tiene que hablar de los micro servicios en contraste con el estilo monolítico. Múltiples cosas corriendo sobre un mismo proceso, tenemos bases de datos, servidores de aplicaciones, aplicaciones sobre estos, etc. Generalmente cuando construimos aplicaciones en el mundo empresarial, lo hacemos en una arquitectura multicapa (que la interfaz de usuarios, los controladores, la capa de manejo de negocio, acceso a datos), sin embargo todo se reduce a tres cosas: base de datos, aplicación en el servidor y en el mejor de los casos desacoplamos la interfaz de usuario. esta aplicación en el lado del servidor se conoce como una aplicación monolítica. Cualquier cambio a la funcionalidad de esta aplicación implica una nueva versión de construcción y despliegue, tratamos de hacer todo lo posible para no desplegar de nuevo, los pasos a producción son un dolor de cabeza y nos comenzamos a inventar cualquier cosa para que la cuestión sea parametrizable o configurable.

Micro Servicios

Es un enfoque en el cual construimos aplicaciones como un conjunto de pequeños servicios, cada uno totalmente independiente, corriendo en su propio proceso y comunicándose con los demás con mecanismo livianos, generalmente http mediante rest. No comparten recursos entre ellos porque al hacerlo estarían acoplados, lo que buscamos con esto es evitar el acoplamiento a un nivel de implementación lo que evitaría la evolución de cada componente independientemente Cuando se aprende orientación a objetos una de las primeras cosas que nos dicen es “Tus clases deben tener alta cohesión y bajo acoplamiento”: así como en las clases pero ahora a nivel de componentes desplegables.

Gobierno decentralizado

ruby

node js

clojure

java

Una de las consecuencias de tener gobernanza centralizada, es que tratamos de estandarizar todo en una sola tecnología (monolíticos), hablamos que debemos escoger la mejor herramienta para enfrentar los problemas y que ahora tenemos un millón de posibilidades para hacerlo, con micro servicios podemos sacar provecho a esto.

Equilibrio

Estandarización

Los micro servicios son independientes, corren en diferentes procesos, eres totalmente libre de desarrollar tus servicios como te plazca, en la tecnología que quieras, eso da un campo de acción más amplio, por otro lado los sistemas monolíticos se basan en la estandarización, que no es malo tampoco, tiene sus beneficios al menos cuando queremos ínter operar entre aplicaciones por ejemplo. Se trata entonces de elegir la una o la otra? NO, creo que se trata de ambas, la pregunta es dónde ¿Dónde estandarizar y dónde ser flexible?

Estandarización- Integración - Interfaces - Monitoreo - Despliegue

Flexibilidad- Construcción Interna

Se flexible en la forma en la que se construyen los micro servicios, se flexible en lo que pasa adentro. Pero normaliza la forma en la que se conectan, en la que se integran y comunican. Existen varias formas de hacerlo, lo mejor es escoger una manera general, lo más común que se hace en estos casos es con http mediante REST, hay que evitar los mecanismos de serialización y deserialización compartidos, esto aumenta el acoplamiento. REST in Practice

DDD y Descentralización de Datos

Los micro servicios surgen de forma natural de los contextos del negocio que se habla en DDD, son la representación de las capacidades o competencias del negocio hechas servicios. De esto se puede deducir que cada micro servicio debe tener su propio mecanismo de persistencia, es responsable de guardar y de leer su propia información sin que nadie más pueda acceder a ella directamente. !

Transacciones distribuidas

tx

tx

Evitar las transacciones distribuidas. Nadie utiliza two phase commmit, dentro de nuestros servicios es perfectamente válido tener transacciones pero hay que evitar el querer propagar esas transacciones a otros boundaries. Teorema de CAP es imposible para un sistema de cómputo distribuido garantizar simultáneamente: La consistencia (Consistency), es decir, que todos los nodos vean la misma información al mismo tiempo. La disponibilidad (Availability), es decir, la garantía de que cada petición a un nodo reciba una confirmación de si ha sido o no resuelta satisfactoriamente. La tolerancia a fallos (Partition Tolerance), es decir, que el sistema siga funcionando a pesar de algunas pérdidas arbitrarias de información o fallos parciales del sistema.

Automatización de la infraestructura

automatizar la creación de los microservicios

Monitoreo

Metrics


Despliegue


Escalabilidad

Monolíticas Micro Servicios

Es muy fácil escalar horizontalmente en este tipo de arquitecturas a diferencia de las monolíticas.

Ley de Conway

“Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.”

Si favorecemos una estructura donde hay un equipo de UI, otro de aplicación, otro de base de datos y otro de operaciones, pues seguiremos en el mismo escenario. En microservices se trata de tomar ventaja de la Conways Law, donde se tendrían los grupos distribuidos en cada proyecto y cada equipo se hace cargo de su producto desde el inicio hasta el final, desde la interfaz de usuario, logica del negocio, base de datos e incluso operaciones.

Productos en lugar de Proyectos

Si lo diseñas lo implementas

“you build, you run it”

Si lo implementas, lo despliegas

about.me/faustodelatog

MUCHAS GRACIAS

@mariascandella