SOA ágil
La comunidad de metodologías ágiles en Colombia, particularmente la de Medellín, logró convocar a más de 600 personas en un mismo lugar para compartir conocimiento y experiencias fundamentadas en los 12 principios del manifiesto ágil. Tuve la fortuna de asistir y de escuchar varias charlas y presentaciones las cuales por su calidad superaron mis expectativas.
Hubo una en particular cuyo nombre me llamó muchísimo la atención: “SOA ágil”. A pesar de los esfuerzos del expositor, pienso que la charla dejó muchos vacíos pues percibí que sus ideas estaban sesgadas por analogías a una reconocida metodología de un proveedor de tecnología.
Esta entrada la debía de tiempo atrás y gracias a una invitación me animé a escribirla. La idea de esta entrada es dejar escritas ideas que he venido recopilando para luego unirlas y así poder proponer lo que considero puede ser un buen aproximamiento a una “SOA ágil”.
Algunas notas de historia
En el año 2006 Jim Webber introdujo el concepto de Guerilla SOA la cual proponía, para ese entonces, la subversiva idea de eliminar los largos ejércitos de consultores, los middleware grasosos, los cronogramas de años, y el acercamiento STOP THE WORLD de los proyectos “SOA” típicos de ese entonces.
Su idea se fundamentaba en el hecho de que ese acercamiento a SOA es demasiado pesado. Propuso una forma de hacerlo más ligera y sin depender de productos o middleware particulares para obtener resultados visibles en corto tiempo y que generaran valor de negocio medible.
Según Webber Guerilla SOA es ligera cuando los equipos de ejecución de tales proyectos son pequeños y si se focalizan en una capacidad de negocio a la vez, entregando resultados de manera incremental e iterativa. Así mismo, el hecho de eliminar las grasosas cajas negras como BPMS o ESB encontró que REST (en esa época la bautizó MEST) cumplía de mejor manera las los atributos de calidad que el cliente esperaba y respondiendo rápido a sus exigencias.
Unos meses después, en Septiembre del 2007, me encontré con que Amazon hacía uso de una arquitectura basada en servicios y que seguía los principios no solo de Guerilla SOA sino que proponía algunas ideas radicales para su época tales como: un equipo pequeño por servicio (de 8 a 10 personas por servicio); que el 70% de sus servicios fuesen REST; una infraestructura en la que no se compartan recursos entre servicios (tales como bases de datos, eliminando así SPOF); entre muchas más que pueden encontrar en ese artículo.
Pasaron unos años y en Junio del 2012 Netflix publicó una serie de artículos donde cuentan cómo pasaron de una aplicación monolítica a todo un ecosistema de servicios que sobra decir, son distribuidos. Lo que más me llamó la atención de la serie fue cómo, el hecho de distribuir los servicios no solo impactó positivamente la velocidad de entrega de las capacidades de negocio requeridas sino a que los equipos se vieron forzados a dividirse por servicio y la infraestructura se particularizó por servicio.
¿Y el mal llamado “Gobierno SOA”? Se dieron cuenta que tal cosa sólo iba en contravía de su objetivo estratégico como unidad de negocio que es entregar valor a la organización YA. ¿Qué hicieron? Abrazar el caos, volverlo parte de su operación y dejar de luchar contra ese hecho.
Lo más increíble de cómo Netflix opera es que luego empezaron a abrir a la comunidad muchos de sus componentes clave para su arquitectura de servicios distribuidos. ¿Quién “gobierna” esos componentes? Un pequeño equipo. ¿Quién reutiliza los servicios de esos componentes? Quien lo necesite y quiera. ¿Y si necesito reutilizar uno de esos servicios pero con un par de diferencias? Cópielo, modifíquelo, publíquelo y manténgalo.
Esa lógica pone en evidencia las caóticas cualidades de cualquier sistema distribuido y que, en vez de pelear contra ellas, las asume y las hace parte de su cotidianidad.
En Marzo del 2012 leí por primera vez acerca de los micro-servicios, una idea propuesta e implementada por James Lewis. Dejo esta idea cronológicamente después de la serie de artículos de Netflix pues pienso que así, cuando mezcle las ideas, será más fácil para el lector entenderme.
Los micro-servicios son una manera muy interesante de implementar una SOA. En pocas palabras un micro-servicio es una pequeña aplicación (en funcionalidad y en líneas de código) que cumple una sola función y la cual se comunica con otras pequeñas aplicaciones a través de un mecanismo común, tal y como funcionan las aplicaciones de Unix que se comunican a través de cadenas de caracteres.
Piensen en los comandos cat y grep por ejemplo. Estas aplicaciones pueden componer su funcionamiento a través del pipe "|". Solo que los micro-servicios en vez de comunicarse a través de cadenas de caracteres se comunican a través del intercambio de mensajes usando respetuosamente el protocolo HTTP.
Una de las ideas más valiosas de los micro-servicios es que, en palabras de Lewis, si un micro-servicio necesita cambiar su comportamiento o tiene algún error de programación, es preferible rehacer el micro-servicio que modificarlo. Si necesita reutilizar un micro-servicio existente pero omitiendo o agregando un comportamiento particular, copie pegue modifique y publique un nuevo micro-servicio.
A primera vista esa idea puede llevar al lector incauto a pensar que eso no respeta el principios de “Don’t Repeat Yourself” (DRY), pero en serio pregúntense ahora, evitar el “copy + paste” ¿es realmente DRY?
Les pregunto ¿un cambio de comportamiento de un servicio existente, por mínimo que sea, no implica que es un comportamiento distinto? ¿Quién les mintió diciéndoles que factorizar comportamiento es la forma a través de la cual se logra mayor reutilización?
En marzo de este año el equipo técnico de Gilt publicó un corto artículo describiendo las causas de la indisponibilidad que presentó su aplicación y cómo esta los llevo a pensar e implementar “LOSA” (Lots of Small Applications). Para su momento la idea no es nueva y es muy parecida a lo que venía haciendo Webber, Amazon, Netflix y Lewis tiempo atrás: muchas aplicaciones altamente desacopladas y aisladas permitiendo caídas parciales (bulk pattern) y protegiéndose así de indisponibilidades generales.
SOA ágil
Una SOA tiene una naturaleza caótica debido a que hereda todas las características de un sistema distribuido. Normalmente un sistema distribuido es caótico pues es difícil predecir cómo se va a comportar, particularmente ante fallas. De ser fácil, la industria no tendría que hacer extensivas pruebas de capacidad a las aplicaciones para saber cómo se van a comportar ante situaciones límite o de borde.
Las fallas en este tipo de arquitectura se vuelven tan difíciles de predecir que Netflix diseño y publicó el proyecto Chaos Monkey el cual permite simular fallas al azar para así poder diseñar e implementar mecanismos que les permita responder ante distintas eventualidades.
Si a esta naturaleza caótica de una buena SOA le sumamos que el negocio necesita sacar productos o servicios nuevos antes que su competencia para no quebrar y nosotros como desarrolladores estamos constantemente agregando o modificando funcionalidades ¿Qué hacemos? ¿”Gobierno de servicios” con un UDDI por unas cuantas decenas de miles de dólares para estandarizar y reutilizar? ¿Qué es reutilizar realmente? ¿Más plata para el proveedor para que meta más servidores en “alta disponibilidad” sin saber que al ser mi aplicación tan monolítica no se va a aprovechar los recursos disponibles de manera eficiente? ¿Desplegar varios ESB en “alta disponibilidad” donde está significa comprar más hardware y software propietario?
Aquí es donde entra la fresca, simple y ágil SOA. La idea es atacar con simplicidad el comportamiento de un sistema distribuido y abrazando confiado su entropía.
Si se fijan en las referencias de la sección anterior todas buscan simplificar el modelo de implementación de sus servicios. Todas las ideas buscan eliminar puntos únicos de falla. Todas buscan responder eficaz y eficientemente a las necesidades del negocio. Todas buscan adaptarse al caos y asumirlo.
Así, parándome en los hombros de gigantes, les propongo 8 heurísticas de una SOA ágil:
1. No hay gobierno
¿Qué es gobierno? ¿Comprar un producto? ¿Quiere salir con un producto nuevo de su empresa al mercado en el menor tiempo posible? No limite a su equipo de desarrollo en seguir políticas inútiles que no le ayudan a disminuir entropía sino que la aumenta y la burocratiza.
El problema no es controlar. Lo que se debe buscar es estandarizar aspectos generales tales como seguridad y protocolos y deje que la innovación emerja. Más de esto en las siguientes heurísticas.
2. No hay restricciones en tecnología
Si se especializa un equipo por servicio ¿quién tiene el mejor criterio para saber cuáles son las tecnologías más adecuadas para su implementación? El equipo que lo va a desarrollar. No impida que su organización obtenga mejores resultados en consumo de recursos o en la velocidad en salir al mercado por viejas y acartonadas costumbres o por “tranquilidad”.
3. Sí hay restricciones vía estilos arquitectónicos
Las restricciones son necesarias como las reglas mínimas de un juego. Las restricciones propuestas por REST son la mejor alternativa para liberar de restricciones de tecnología a sus equipos de trabajo pues todos los servicios se acoplan a un protocolo y no a contratos RPC.
Entrene a sus equipos en patrones arquitectónicos. Defina arquitecturas de referencia de uso opcional y publíquelos en una wiki. Si la wiki es buena y útil tendrá adopción.
4. No hay jerarquía sino equipos con responsabilidades bien definidas
Especialice y responsabilice a los equipos de trabajo por capacidad de negocio. No separe al desarrollo de la infraestructura. Logre que sus equipo de desarrollo se responsabilicen de la infraestructura. Permita que la arquitectura de su organización emerja. (En alguna otra ocasión escribiré sobre la “nube”, la idea más gaseosa de todos los tiempos)
5. Fork, Clone, Pull request
¿Reutilización? Métase ya mismo a Github y disfrute de lo que en realidad es reutilización. Reutilización no es factorizar comportamiento, es especializarlo (algún día escribiré sobre este punto). Es usar librerías que voy encontrando por ahí y que están mantenidos por alguien con quien nunca he hablado. Lo importante es que el código está ahí para leerlo, tocarlo, modificarlo, copiarlo.
Imagine por un segundo que su empresa tiene un Github pero en vez de proyectos se publican servicios pequeños. Luego, si otro equipo necesita ese servicio, sencillamente lo clona y lo usa. Si necesita reutilizar algo de ese servicio, le hace fork y reutiliza el pedazo que le interesa. Si descubre un bug lo puede reportar o inclusive reparar y proponer un Pull Request. Si necesita un servicio parecido a uno ya publicado, hágale fork, modifique y publique.
6. Auto-organización
Si no controla la exposición de servicios debe aprender que el caos tiende al orden. Por ejemplo, los servicios más transversales y utilizados por lo demás serán aquellos que maduren más rápido (como los proyectos Apache o Linux). Los servicios con mayor tendencia a reutilizarse emergerán solos y madurarán por su uso e importancia. Aún más interesante: si todos sus servicios publican métricas de su comportamiento usted los podrá identificar y priorizar por su uso y comportamiento más que porque un Arquitecto Empresarial lo decidió así.
7. Distribuido.
SOA es distribuido. Los servicios son pequeñas aplicaciones que se comunican por red que modelan una capacidad de negocio. ¿Tiene una sola base de datos? No tiene SOA (sad panda). ¿Tiene integraciones por datos? No tiene SOA (sad panda). ¿Tiene una base de datos por servicio? ¡Sí tiene SOA! (happy panda) ¿Si se cae un servidor su empresa queda sin aplicación? No tiene SOA (sad panda). ¿Si se cae un servidor sólo se cae un servicio y el resto de su empresa sigue funcionando sin problemas? Sí tiene SOA (happy panda). Fácil.
8. Reutilización, redundancia, replicación y duplicidad.
No sé quién nos metió en la cabeza que reutilizar es factorizar comportamiento (acoplamiento vertical, ¿alguien?). No sé quién nos vendió la idea de que replicar datos es tan malo como duplicarlos. No sé quién nos enseñó que la única manera de tener aplicaciones disponibles es a punta de plata comprando infraestructura redundante (pura fuerza bruta y cero ingeniería).
Para este punto si lea, estudie, analice y observe como aplicaciones Web como Facebook, Amazon, Netflix, Instagram, Gmail, Google Maps, Simple Bank, entre muchísimas más funcionan. Estoy seguro que su empresa no está ni cerca de lo caótico y complejo ni del volumen de transacciones que estas aplicaciones soportan. ¡Y sin middleware!
Cierre
Soy consciente que no todas las heurísticas son fáciles de digerir. Obviamente por alguna razón del perverso universo usted no se sienta capaz de políticamente asumir el reto de tener una SOA ágil.
Abrace el Caos. Deje que él mismo lleve a que su ecosistema de aplicaciones tienda al orden. Construya aplicaciones simples, pequeñas y autónomas desde su comportamiento hasta su infraestructura. No se mate buscando que estructura factorizar para después arrepentirse. No desperdicie plata en middleware innecesario que sólo le da tranquilidad al político y no al técnico. Permita que su equipo técnico innove. Permita que su arquitectura emerja restringiendo su estilo y orientandola a través de múltiples arquitecturas de referencia. Sea costo eficiente y use la ingeniería no la fuerza bruta. Respóndale rápido al negocio y apalanque el crecimiento de su empresa.
¿Qué opinan?