¿Qué es el RPC?

Aunque ciertos conceptos de programación son más viejos que yo, hay ciertas técnicas muy potentes que son desconocidas o ignoradas por mucha (demasiada) gente.

A principios de los 80 (la Wikipedia cita un RFC de 1975 y, cómo no, Xerox) se hizo la formulación obvia que la comunicación entre sistemas se podía modelar como una llana y simple llamada a una función que se ejecuta en otro sistema y nos devuelve el valor.

El mecanismo que se utilice para ello debe ser irrelevante, nosotros sólo queremos ser capaces de escribir:

resultado = suma(a,b)

y que la suma se realice en el sistema remoto. A esto le llamaron llamada de procedimiento remoto o Remote Procedure Call en inglés.

Sun implementó uno de los primeros sistemas de RPC para implementar el sistema de archivos distribuido NFS, y a lo largo del tiempo han ido apareciendo diferentes mecanismos de RPC para diferentes plataformas y necesidades.

Con la popularización de la WWW, el protocolo HTTP y Javascript en los 90, pronto la gente comenzó a implementar comunicaciones entre sistema utilizándolos. Por ejemplo, una web podía exponer algunos de sus contenidos y funcionalidades en HTML para consumo humano, pero también exponerlos para consumo de otros sistemas. Mecanismos simples como poner una URL en la que si hacemos un POST http con unos argumentos, nos devuelve el resultado de una operación en un formato fácilmente parseable.

Pronto, uno de los padres fundadores del HTTP, procesó los principios fundamentales del HTTP y la WWW, en concreto que todo era una cuestión de URLs y acciones como GET/POST/PUT/DELETE que soporta el protocolo HTTP; cada URL representa un recurso y podemos expresar acciones mediante los “verbos” HTTP. A esto le llamó REST y supuso una perspectiva limpia y poderosa de lo que es la WWW.

De allí se pasó a los RESTful Web Services, maneras de exponer servicios en Internet utilizando los principios del REST.

Típicamente, los desarrolladores de servicios web utilizan técnicas similares a las del desarrollo de aplicaciones web para publicar servicios REST, y los desarrolladores de servicio ejecutan las llamadas HTTP correspondientes para utilizarlos. Los formatos se intercambian en cualquier formato de intercambio de datos; desde texto plano, a XML u otros formatos como JSON, YAML o lo que se le ocurra la persona, teniendo que codificarse en origen y decodificarse e interpretarse en destino.

Pero paralelamente, otros desarrolladores recordaron el RPC y desarrollaron sistemas de RPC sobre HTTP. Uno de los primeros fue XMLRPC, que posteriormente evolucionaría hacia el denostado SOAP. Muchas implementaciones de RPC sobre HTTP inicialmente eran malas; en parte por ser nuevas y primitivas, pero principalmente por la interoperabilidad. Mucho RPC anterior era entre sistemas muy homogénenos, con el mismo lenguaje en cliente y en servidor y desarrollados por las mismas personas, pero en el mundo de la WWW, son comunes entornos más heterogéneos, con lo que el RPC es mucho menos sencillo; diferentes modelos de datos y convenciones en cada extremo de la comunicación trae muchas dificultades y muchos RPC primitivos tenían grandes problemas de interoperabilidad.

La visión de la transparencia entre sistemas no se daba. A veces, incluso, utilizando el mismo lenguaje pero diferentes implementaciones del mismo protocolo se tenían muchos problemas.

Queda claro que una idea, por buena que sea, está limitada por sus implementaciones, y el pobre estado de los RPC sobre http ha impulsado muchísimo el uso de REST en vez de RPC. Eso es malo, porque en general REST te da más trabajo que RPC; mientras que en REST uno debe definir el formato de datos de intercambio e implementar la codificación y decodificación de estos, los mecanismos RPC realizan todo el trabajo sucio sin que el programador se tenga que preocupar de nada.

Además, para invocar un servicio REST, simplemente has de usar las librerías de HTTP y de codificación que hayas escogido (parseo de texto plano, XML, JSON, etc.); con un sistema de RPC has de aprender a usar la librería, que si bien te puede ahorrar código, es más complicada conceptualmente.

Esto llevó a que SOAP fuese condenado por gran parte del mercado (la interoperabilidad era siempre problemática, las librerías complejas, etc.) y el REST se popularizase mucho e incluso fuese en la práctica la mejor opción en muchos casos.

Sin embargo, el RPC ha avanzado mucho. Disponemos de librerías decentes de SOAP, XML-RPC y otros protocolos como JSON-RPC para la mayoría de lenguajes, y hoy en día ya no me sorprende consumir un servicio implementado en un lenguaje desde otro sin ningún problema.

Por otra parte, gente como Facebook y Google han inventado protocolos nuevos que son decididamente interoperables y multilenguaje, como Thrift de Facebook (ahora Apache) y los protobuf, que resuelven el RPC de una manera limpia y eficiente.

Con RPC nos podemos ahorrar mucho código repetitivo de comunicación que supone REST, con el consiguiente aumento de productividad.

¿Deja de tener sentido REST y sólo debemos comunicarnos mediante mecanismos RPC, por tanto?

No, desde luego que no. Aún pueden existir problemas de interoperabilidad entre algunas plataformas poco populares, o los mecanismos de RPC puede que no sean buenos. REST es siempre un mínimo común denominador y la verdadera manera de asegurarnos que nuestros servicios pueden ser utilizados universalmente- incluso yo recomendaría que aunque implementemos RPC, ofrezcamos también REST para quien no pueda utilizarlo (recordemos igualmente que puede ser sencillo exponer un mismo servicio tanto con XML-RPC, como con JSON-RPC simultáneamente sin mucho esfuerzo, ampliando horizontes), y REST sigue siendo útil para exploración y “descubribilidad”.

Pero, cuando sea posible y adecuado, ahorrémonos escribir código de más.

Dineropelota

El éxito de Nate Silver prediciendo las últimas elecciones en USA ha sido todo un acontecimiento público. Los medios se han hartado de comentar los métodos que le han permitido acertar correctamente el resultado en todos los estados con un margen de error mínimo, humillando a la legión de comentaristas políticos que extienden un dedo, lo levantan y miran de dónde sopla el viento para hacer sus predicciones.

Pero para mi lo realmente interesante ha sido indagar en su biografía. A parte de haberse ganado la vida jugando al póker, Nate trabajó durante mucho tiempo en el campo de estadísticas en el béisbol.

Tradicionalmente, el béisbol ha sido siempre un deporte con estadísticas al milímetro; como descendiente del cricket (que ya por el XVIII generaba bastantes datos), desde el siglo XIX durante cada partido se lleva un registro cuidadoso de todas las jugadas. El hecho de que sea un deporte con jugadas aisladas con inicio, final y resultado concreto hace que sea relativamente sencillo anotar una ingente cantidad de anotaciones sobre cada partido.

Así pues, no es raro que ya hace mucho tiempo los equipos intentasen emplear las estadísticas para mejorar el rendimiento de su equipo mediante el análisis de datos para determinar táctica y estrategia o incluso para fichar jugadores. Las estadísticas de cada partido son públicas y los almanaques que recogen éstas son abundantes y populares, el uso avanzado de las estadísticas no se límita a los equipos y los comentaristas, sino que los mismos aficionados suelen estar muy familiarizados con los números.

En 2002, los Oakland Athletics y su manager Billy Beane, consiguieron ensamblar un equipo extremadamente competitivo pese a no contar con unos ingresos comparables a los titanes tradicionales del deporte (su presupuesto para ese año era un tercio del de los Yankees). Para ello, bebieron de una corriente de pensamiento estadístico originada en los 50 que reanalizaba las estadísticas disponibles y creaba unas nuevas métricas que servían para valorar mejor el rendimiento de un jugador. Pasaban de estadísticas simples y evidentes como el porcentaje de bolas que conseguía batear un jugador a otros indicadores más complejos que tenían en cuenta más factores.

Mediante el uso de estos indicadores, los Athletics conseguían encontrar buenos jugadores cuyas estadísticas tradicionales no eran excelentes y por tanto no estaban muy valorados, pero que sus métricas (denominadas sabermetrics) los destacaban como jugadores que podían aportar mucho a un equipo. Estos resultados también iban en direcciones opuestas, como en el caso de Silver contra los comentaristas de sillón, del olfato de los ojeadores.

De esta manera, mediante el uso de estadísticas, los Athletics pudieron fichar jugadores baratos cuyo rendimiento estaba infravalorado y conseguir un éxito deportivo.

Todo esto se plasmó en la película Moneyball con Brad Pitt, basada en el libro del mismo nombre, que explica la temporada de explosión de los Athletics.

Por supuesto, el éxito de los Athletics llevó a otros equipos a utilizar los mismos métodos y seguir estas vías de investigación. El resultado fue el obvio; los jugadores con buenos números de sabermetrics subieron de valor, impulsando todo hacia el antiguo status quo- los equipos con dinero son los que pueden fichar a mejores jugadores según las sabermetrics, y se establece una carrera armamentística para ver quién puede encontrar métricas más efectivas que permitan descubrir a más jugadores infravalorados.

Así pues, tenemos que un análisis estadístico concienzudo nos lleva a unos resultados deportivos tangibles y un cambio sustancial en la operativa de los equipos deportivos y una validación del método analítico en un terreno aparentemente tan caótico y subjetivo como el deporte.

¿Es esto aplicable a otros deportes? ¿Podemos medir y optimizar el rendimiento deportivo?

Seguramente sí. Sin embargo, está clarísimo que hay muchos y populares deportes que están en pañales estadísticamente. El fútbol, deporte rey, prácticamente no tiene estadísticas. Su naturaleza fluida y continua no parece proporcionar muchas oportunidades de generar datos; aún hoy tras los partidos no vemos más que un puñado de estadísticas muy genéricas, de las cuáles muchas no parecen tener mucho valor. Se han hecho esfuerzos analíticos y ahora vemos estadísticas como los kilómetros recorridos por cada jugador, pero al menos no se han hecho públicas ninguna métrica que parezca útil. Así pues, sigue en la época de los analistas de sillón que dictaminan sobre la cualidad de los jugadores y muy probablemente, existe una ventana de oportunidad para que un analista logre un salto cualitativo que cambie el fútbol moderno. Seguramente dentro de las casas de apuestas (que cuentan con unos sofisticados métodos de análisis que estiman probabilidades en tiempo real durante el desarrollo de los partidos), ya haya quien esté trabajando en ello.

Por otra parte, observando el campo del motor vemos un caso bien distinto. Los equipos disponen de sofisticados datos telemétricos que permiten analizar hasta el más mínimo detalle de los movimientos del coche sobre la pista. Los sistemas de medición generan una cantidad de datos que seguramente hacen palidecer en cuanto al volumen a los datos de un partido de béisbol. Los datos de telemetría se utilizan extensivamente para analizar el rendimiento del coche y afinar su configuración, y para analizar la conducción de los pilotos y hallar puntos de mejora. Sin embargo, estos datos son coto privado de cada equipo y no circulan. Desgraciadamente, estos datos quizás nos permitirían responder a preguntas como quiénes son los mejores pilotos, que dado el gran peso del rendimiento del coche sobre el del piloto, a día de hoy son muy difíciles de contestar y quedan con un análisis muy superficial.