gRPC – Un poco de historia I

Introducción

Normalmente la gente empieza explicando qué es una cosa para pasar luego a mostrarlo de forma práctica.
En mi caso, decidí hacerlo al revés.

Por esa razón, escribí una entrada en mi blog sobre gRPC en la que explicaba cómo realizar un típico ejemplo «Hola Mundo», pero ahora ha llegado el momento de explicar un poco más que es esto de gRPC desde un punto de vista más teórico.

gRPC son las siglas que definen a un framework desarrollado por Google sobre Remote Procedure Call, con el cual podremos desarrollar servicios basados en RPC y clientes que los consuman.

Pero antes de entrar un poco más en detalles y explicaciones, vamos a hacer un pequeño recorrido introductorio para ubicarnos bien.

Historia de RPC

La idea detrás de RPC no es otra que la de ejecutar una subrutina (método o función) que está en otro sistema y que actuará como si fuera una llamada a un proceso local.

Dicho de otro modo y más directo.
Un cliente realizará una llamada a un servidor para hacer una llamada, y por lo tanto ejecutar, una subrutina que está en el servidor, obteniendo el cliente la respuesta de dicha ejecución.

Los protocolos de petición/respuesta (request/response) tienen su base en la informática distribuida a finales de los años 1960s.
Las primeras propuestas y borradores sobre llamadas a procedimientos remotos (remote procedure calls) como modelo de red tienen sus primeras aproximaciones en los años 1970s.
Y las implementaciones prácticas de estos modelos tendrían lugar ya en los primeros años de la década 1980.

Bruce Jay Nelson que trabajaba en Xerox PARC es la persona que acuñó en 1981 el nombre de RPC – Remote Procedure Call.

Las primeras demostraciones y pruebas de RPC fueron realizadas por Xerox para sistemas operativos Unix.

Posteriormente, RPC fue poco a poco implementado en más sistemas operativos y mecanismos de comunicación.

Evolución arquitectónica

Sin ánimo de extender demasiado las explicaciones sobre arquitecturas y pasando de puntillas por ellas, podemos echar la vista atrás para ver que hace bastantes años lo que dominaba a los desarrollos Software eran las arquitecturas monolíticas.

Poco a poco, esas prácticas arquitectónicas fueron dejando paso a arquitecturas un poco más flexibles, pasándose a llamar arquitecturas modulares.

Estas dos bases arquitectónicas siguen vivas hoy, y cabe destacar que no todo debe ser definido como bueno o malo según el tiempo que tiene, simplemente debe asumirse la premisa de si es acorde con el contexto con el que se trabaja y con el momento concreto.

Posteriormente en los años 90 principalmente, nos encontramos con el auge de las redes, que propició un nuevo modelo de arquitectura idóneo (que no único) para aquel momento, hablo de la arquitectura basada en informática distribuida.

Así, aparecieron conceptos, mecanismos y modelos que a algunas personas sonará, como CORBA, DCOM o RMI.
Lo sensacional de estos modelos o mecanismos de comunicación que acabo de citar es que se basaban en algo denominado RCP.

RPC desde un punto de vista práctico era viable tal y como podemos apreciar.

Aunque lo que hoy se conoce como Web llevaba ya muchos años funcionando, es en el año 2000 cuando empieza a explotar de forma masiva.

El protocolo HTTP – Hypertext Transfer Protocol empieza a estar en boca de mucha gente al hablar de Internet y de redes de comunicaciones, y se extienden conceptos como Servicios Web XML, XML-RPC o SOAP – Simple Object Access Protocol que deriva de XML-RPC a su vez.

Los ingredientes para una tormenta perfecta ya están depositados, y un poco más adelante se empieza a acuñar el término Web 2.0 y «democratización de la red» que tanto daño han hecho (y siguen haciendo).

Aparecen conceptos como JSON – JavaScript Object Notation y REST – Representational State Transfer, y con ellos la ploliferación de APIs para establecer comunicaciones entre clientes/consumidores y servicios.

Por otro lado, se empezará también a oir hablar de Cloud o nube.
En el caso de Microsoft Azure (inicialmente denominado Windows Azure), ésta dará el pistoletazo de salida el 1 de Febrero de 2010.
Hoy en día existen más empresas que dan servicios en la nube, de donde AWS (Amazon Web Services) y la comentada Microsoft Azure son los dos mayores exponentes hoy día.

Y así, aunque sea de forma resumida y fugaz, llegamos hasta nuestros días, donde una nueva palabra satisface nuestros oídos.
Hablo de microservicios, cuyo término se empezó a tratar en el año 2005 como micro web services para posteriormente en el año 2011 acuñarlo como microservices.

Ahora bien, el cocktail perfecto lo conjuga la nube o cloud y los microservicios, si bien el uno sin el otro podría vivir perfectamente.

Cloud y Microservicios

Así que hago aquí una pequeña pausa y creo un nuevo apartado para hablar sobre Cloud y Microservicios, simplemente para definirlos y por dejarlos bien situados dentro de su contexto sin interés de mal interpretarlo con lo hablado hasta ahora.

No debemos tratar a los microservicios como algo que debe sustituir a nada, simplemente una estrategia más a nuestro alcance.
Y lo mismo sucede con la nube o Cloud, que aunque muchas empresas lo estén consumiendo, muchas otras siguen usando con éxito sus sistemas on-premise aún.

Dentro de los microservicios se recoge prácticamente todo lo visto anteriormente pero con alguna pequeña anotación.
De hecho, no debemos perder el foco de que son interfaces que definimos a través de una API.
Dicho de otra forma y por no liarnos, es una estrategia para desarrollar nuestra aplicación a través de pequeños servicios autónomos, ejecutándose cada uno de ellos de forma individual y pudiendo comunicarse entre todos ellos con sus APIs a través de peticiones HTTP.

Llegados a este punto de la historia, no es raro que oigamos hablar también de Arquitecturas de Microservicios

El auge de los microservicios llega sobre todo a causa no sólo de la extensión de la Web y el Cloud, sino para cubrir todas las nuevas demandas que se producen, incluyendo aplicaciones móviles y dispositivos IoT, el aprovechamiento del ancho de banda existente en un momento dado (sobre todo si éste fluctúa), la demanda uso y crecimiento de usuarios, el volumen de información a tratar, el uso de recursos de quién consume los datos y disponer de información en tiempo real.

Así que la pregunta obligada es si podríamos usar microservicios fuera de la nube, lo cual es correcto, pero indudablemente usar la nube nos va a ahorrar mucho tiempo y muy posiblemente y aunque a priori pueda no parecerlo, dinero también y sobre todo quebraderos de cabeza.

¿Y ahora qué?

Llegados a este punto, todo esto está muy bien, pero… ¿dónde entra gRPC en toda esta historia?.

Eso es algo que veremos en la próxima entrada.

Happy Coding!