Hace más de dos decadas, el autor de este artículo, Gustavo De la Cruz, estudiaba y devoraba la arquitectura de CORBA y marcos de objetos distribuidos similares (COM, SOM y otras decenas de tecnologías similares) con el fin de lograr un esquema de aplicaciones integradas a través de objetos. En esos tiempos los lenguajes Orientados a objetos eran C++, Objective C, Smalltalk, Eiffel y todos prometian una pronta integración entre ellos. SUN Microsystems tenía un proyecto muy fuerte entre manos para revolucionar el computo distribuido. Estoy hablando de inicios de la decada de los 90.
La arquitectura se basaba en servicios comunes para lograr la persistencia, ciclo de vida, concurrencia, seguridad, eventos, transacciones y un sin fin de servicios que parecía el paraíso de los programadores para hacer aplicaciones distribuidas basadas en objetos. El protocolo unificador era IIOP y parecia que nadie iba a poder igualar esta labor, ni Microsoft con su COM.
En esos tiempos este era mi libro de referencia y lo leía casi todos los días
Y llego Java, y los jovenes proyectos acabaron devorando a los viejos proyectos de CORBA. Aunque al principio Java fue un lenguaje excelente para implementar CORBA, en ese momento también el uso del protocolo HTTP como el gran transportador de mensajes síncronos entre aplicaciones y elevando el nivel de estandarización y la capacidad de exponer objetos no solo en redes privadas, sino via la naciente Internet. Así se unió al modelo multicapa, una capa adicional, de 3 a 4 capas, la capa de Web.
Muchos saben ya la historia, salió J2EE (hoy JEE) y muchos servicios de CORBA vieron su simil, Transacciones y ciclo de vida se volvieron EJBs, Persistencia EJB de entidad, Naming a JNDI y con eso se elevó el nivel de reuso de servicios. Y si, los programadores ya teniamos las herramientas para hacer la magia que tanto soñabamos con objetos. Llegó la epoca del servidor de aplicaciones. Decenas de compañías te ofrecían en el JavaONE su producto, empresas que ya no figuran. Podría decir que los únicos sobrevivientes de esos tiempos que ahora veo con una particular nostalgia de mi epoca de juventud adulta, son WebLogic, Websphere y JBoss, TomCat (es un appserver ??) donde se pueden edificar arquitecturas de despliegue que pueden usar procesamiento de manera escalable y formando clusters.
En esos tiempos, los que eramos arquitectos de software, con un pequeño nivel de soberbia, no pensabamos tanto en el hardware. Al final, la magia de la portabilidad permitia que el diseño pudiera ejecutarse en cualquier tipo de computadora que soportara la JVM y podiamos confiar que la ingeniería del JIT se podía encargar de ejecutar de manera optima el código...
Esta arquitectura aun es la reina en muchos ambientes de aplicaciones empresariales. Hemos educado a las nuevas generaciones a confiar sin cuestionar la magia de los servidores de aplicaciones. De igual manera, el mundo Microsoft .NET hizo lo similar y aprovechó las lecciones dolorsamente aprendidas en temas de desempeño para simplificar el modelo de aplicaciones con objetos distribuidos.
Llegó la revolución de la simplificación, 2003, cuando Rod Johnson y varios más cuestionaron el enfoque de utilizar/desperdiciar recursos de computo y volvieron a los Plain Old Java Objects. Se dieron arquitecturas livianas, corriendo con TomCat y rompiendo la ortodoxia de que todo era un EJB.
Los clusters de Weblogic o Websphere seguían teniendo sentido para aplicaciones que necesitaban de escalabilidad y de manera mágica se hacia la migración y manejo de las fallas, así como unir al cluster una JVM más. Así es el estado de los actuales servidores de aplicaciones y se han optimizado con esquemas de base de datos en memoria o caché (Terracota, Coherence)
La última complicación del lado del mundo Java fueron sus JSF, con el intento de hacer componentes web reutilizables, pero con demasiado énfasis en que todo lo resuelve el servidor.
Y el resurgimiento de Javascript, dado que el navegador ya no es una pieza tonta de software que solo desplegaba HTML e imágenes, sino toda una gama de componentes para visualizar, almacenar, comunicar que ahora es HTML5, CSS3 y Javascript y donde el procesamiento se puede hacer en la computadora cliente que ya tiene capacidades respetables.
Agregado a la aparición de aplicaciones móviles que muchas veces tienen que trabajar fuera de línea; todo ha llevado que los servicios distribuidos tienen una clara definición de que es lo que deben de hacer y estandarizados a través de modelos basados en REST o intercambio con JSON.
Esto ha llevado a una nueva variante de implantar los servicios. Muchos usando software abierto. Modelos de base de datos donde ya no solo es SQL la única opción, distribución de la carga de trabajo usando esquemas de mensajes asíncronos y capacidades para analizar grandes volumenes de datos usando procesamiento distribuido.
El hardware se ha vuelto un "commodity" y los procesadores, almacenamiento y redes se pueden manejar por decenas y abaratando los modelos de computo distribuido e implantar masivamente servicios de software que están reemplazando al modelo de servidores de aplicaciones pero usando directamente las capacidades del hardware "virtualizado".
Como dije, hace un par de decadas no era el hardware el modelo primordial al diseñar la arquitectura, hoy en día es fundamental y la escalabilidad y tolerancia a fallas ya no es tanto de un sistema operativo o de un middleware, sino de mecanismos que permiten replicar imagenes virtuales sobre múltiples procesadores y almacenamiento y con la capacidad de resistir a fallas. Ya nadie queda impactado si un nodo de computo tiene un problema, puede ser reemplazado por uno similar y en cuestión de segundos o minutos.
Todo esto es lo que se llama computo en la nube. Al final es lo que narro, muchos servicios disponibles con un pool de recursos casi infinito de procesadores, almacenamiento y redes y disponible de manera ubicua a través de Internet.
Nunca he comprobado esta teoria, pero presiento que la manera como se están solucionando los diversos temas relacionados con ofrecer un servicio de la nube viene desde lo aprendido por muchos en sus clases de sistemas operativos o ambientes distribuidos, de un sistema operativo llamado Amoeba, que nacio de la escuela de Andrew Tanenbaum. El siguiente diagrama muestra la arquitectura y vean que el pool de procesadores es lo que ahora se llama computo elástico. Los invito a leer los libros de Tanenabaum en esta materia y se van a ver sorprendidos que hace 20 años ya las ideas actuales estaban definidas
A lo que voy de toda esta historia es que el momento que estamos viviendo de computo en la nube es el momento de madurez de un tipo de computo que fue concebido como objetos y que se transformo a servicios que son ubicuos, portables, interoperables y con la capacidad de explotar hasta el "tuetano" las capacidades de virtualización de hardware.
Hoy mucha gente está preocupada sobre la nube, que implica. Puesto de manera simplificada es poner en Internet tus aplicaciones. Ese puede ser el primer foco de usar una nube pero no es el mejor en términos de arquitectura por que es llevarse todo lo que tienes bien y mal en los sistemas empresariales y no usar el total potencial de la tecnología de la nube. Muchos aún se preocupan por subir el servidor de aplicaciones, clusters, la complejidad de un RDBMS en la nube. Como primer paso quizá está bien pero ...
Es importante que los especialistas de TI se abran y entiendan el estado actual del arte de la tecnología. Ya no hay un solo lenguaje de progamación, ya no hay una plataforma que predomine, la guerra de CPUs (CISC vs RISC) o de sistemas operativos (Windows vs UNIX-Linux) se acabó y hubo ganadores que ni siquiera pueden ya cantar victoria.
Lo que se debe aprovechar es la riqueza y variedad potencial de los servicios distribuidos que se ofrecen y usarlos por sus caracteristicas (disponibilidad, confiabilidad, capacidad, seguridad, portabilidad e interoperabilidad) y ya no ponerse en modo ortodoxo si es de un fabricante o una tecnología en particular. En este momento, la visión inicial de los objetos distribuidos como componentes reutilizables (o de re uso) ya es un hecho pero no es el resultado del esfuerzo de un fabricante o grupo (como era DCE o CORBA) sino de la apertura del software abierto y que ha sido adoptado por cuestiones técnicas y no comerciales y se han vuelto estándares de facto.
Asi que si en el servicio existe una arquitectura MEAN o JEE o .NET, o con servicios NoSQL o Hadoop o Spark o RabbitMQ o AMQ, con Windows o Linux; no es preocupante la variedad tecnológica, es bueno dejar la libertad y creatividad a los arquitectos y programadores del software y garantizando los requerimientos técnicos y el nivel de calidad de servicio; y controlar (gobernar) a través de buenas definiciones de arquitectura empresarial y estándares la enorme variedad de tecnologías.
Pensar entonces como servicios de plataforma es el enfoque, o lo que se conoce como Platform as a Service (PaaS) es lo que permite explotar el modelo de encapsular la complejidad.
La siguiente presentació de Slideshare,
Pizza as a Service, ayuda a entender el modelo de la nube. Muchos de los lectores ya usan SaaS, dado que tienen una dirección de correo electrónico personal basada en algun servicio (Gmail, Outlook, Yahoo?)
Empezando a pensar en el futuro. Hoy grandes empresas ofrecen las nubes. Tiene buenos puntos por que podemos delegar la pizza y administrar a través de niveles de servicios. Pero la contraparte es que se sigue concentrando el procesamiento en grandes cúmulos controlados por grandes empresas, lo cual es contrario a la filosofia de Internet.
Voy a repetir (en español) lo que un articulo de SUN sobre
JXTA dice al respecto:
"The Internet was founded on a simple vision: to build a highly decentralized and resilient worldwide network infrastructure that would scale and that could resist any denial-of-service attacks"
"Internet fue creado con una visión simple: constituir una infraestructura de red de alcance mundial y que es altamente descentralizada y resilente que puede escalar y resistir cualquier denegación del servicio"
JXTA, que es una tecnología que siento aún no se comprendió, y la última obra de Bill Joy en SUN, tuvo la visión de tomar P2P como el siguiente paso. Yo identifico que en la epoca del IoT, JXTA tiene mucho por decir.
Analizando la arquitectura de JXTA, nos lleva a un nivel adicional de procesamiento. Se construyen redes virtuales de peers encima de la infraestructura estática de la actual Internet.
Pienso entonces, algún dia también las nubes se van a volver "commodity" y tendremos la libertad de usar nubes públicas abiertas (open cloud computing?) para constituir nuestros servicios personalizados o de una empresa. La nube se va convertir en una red de Peers y que de manera dinámica se van a enlazar. Espero en unos años leer esta entrada y ver que tanto atine a predecir sobre este tema.
Por mientras, si es importante considera el computo en la nube, identificar su beneficio a nivel de negocio, el cual siempre es hacia la agilidad de tener soluciones tecnológicas para lograr innovación y realización de la estrategia. Quien no tome esta oportunidad, va a quedar muy rezagado para el siguiente paso. No teman en cambiar los viejos paradigmas de procesamiento. No mas servidores de aplicaciones, no más grandes clusters, los servicios de la nube ya tienen la capacidad para dar el modelo equivalente.
Quien tenga el valor de hacer este cambio, ya está adelantando buenos pasos. Diria, está innovando ...
Esperando comentarios ...