Me han pedido que escriba una pequeña introducción al Departamento Técnico de RETAbet y, como siempre tiene que haber una primera vez para todo, aquí me he puesto a hacerlo.

Me encuentro mucho más cómodo contando historias viejunas, en plan Abuelo Cebolleta que escribiendo cosas que realmente interesen a la gente, así que haré honor a esto del abuelo y empezaré remontándome a cuando conocí el Proyecto RETA, allá en abril del año 2004.

Sí, hace 15 años ya.

Para evitar confusiones, permitidme que haga un par de apreciaciones: EKASA (Euskal Kirol Apostuak, S.A.) es el nombre de la empresa dónde trabajamos y RETA, posteriormente RETAbet, es el nombre de la plataforma de apuestas deportivas.

A lo que íbamos; yo acababa de aterrizar en una nueva empresa y ésta, entre otros proyectos, estaba participando en uno relacionado con “apuestas deportivas”. Este proyecto, que luego desembocaría en RETA y años más tarde en RETAbet, lo estábamos realizando entre varias empresas. A nosotros nos tocaba la parte de HAL, mientras que otras se encargaban de la parte frontal, backend y base de datos.

Nuestro HAL era un control ActiveX DCOM programado en Visual Basic 6 que era invocado desde una página en Internet Explorer 6. Como se decía entonces de manera irónica: era “lo mejor de cada casa”.

Cuando yo llegué este proyecto estaba bien encaminado, así que a mí me tocó otro muy interesante: desarrollar un aplicativo de apuestas que funcionase en los teléfonos móviles. Hablamos de mediados de 2004, tres años antes de que apareciese el iPhone y cuatro años antes de lo que hiciese Android. Aunque parezca increíble, unos meses después vio la luz la primera versión de RETAMóvil, con capacidad para apenas unos pocos deportes diferentes, unas pocas docenas de apuestas y, en la versión que había desarrollada, soporte únicamente HTTP; HTTPS era serious business en aquellos tiempos y no había muchos móviles que lo soportasen.

Deportes en la primera versión de RETA sobre móviles

Hasta mediados de 2007 seguimos desarrollando y completando la plataforma HAL con nuevas funcionalidades e, incluso, desarrollamos dos placas electrónicas conocidas como DCP y DCM. Estas placas se integraban dentro del terminal de apuestas y hacían de interface eléctrico y electrónico entre el HAL y los diferentes dispositivos. Como anécdota, simplemente comentar que del DCP se fabricaron 600 unidades y del DCM, 1300.

DCP
DCM

Asimismo, se habían construido cinco unidades del prototipo de la RT1, la primera terminal en el mundo específicamente diseñada para apuestas.

RETA TERMINAL 1 (RT1)

A mediados de 2007 se presentó por fin el concurso público para la explotación de las apuestas deportivas en el País Vasco. Se otorgaban tres licencias y era entonces cuándo EKASA, que llevaba desarrollando este proyecto desde 2003, se jugaba el todo por el todo. Si no quedaba entre los tres primeros, adiós al proyecto y a la enorme inversión llevada a cabo.

EKASA, que tenía un prototipo viable y un proyecto muy bueno, consiguió una de las licencias, así que al final todo salió bien. Lo siguiente que supimos, en verano de 2007, fue que el equipo de Dirección había decidido que se iba a hacer un overhauling de la tecnología existente, con lo que se descartaba absolutamente todo lo que se había estado desarrollando durante cuatro años y se empezaba de nuevo, utilizando esta vez Visual Basic .NET

La tecnología del terminal también se cambió completamente: se descartó que el frontal fuese una página web y se optó por utilizar Windows Presentation Foundation (WPF), desarrollando un aplicativo pesado en Visual Basic .NET utilizando ORCAS (más tarde Visual Studio 2008)

Página Web del terminal de apuestas en 2007

Toda la tecnología backend también se descartó: en vez de Java se utilizó Visual Basic .NET, con los servicios basados en Windows Communication Foundation (WCF).

Los aplicativos de gestión del negocio se reimplementaron de nuevo, utilizando VB .NET y un patrón llamado CAB (Composite UI Application Block), que pasó por el mercado con (mucha) más pena que gloria.

Y, por último, también se cambió la base de datos; de Oracle se pasó a SQL Server 2005 y, al igual que había ocurrido con el resto de las tecnologías, se tuvo que rehacer completamente.

Para no dejar títere con cabeza, la venerable RT1 también sufrió la purga, esta vez por cuestiones puramente regulatorias, y hubo que diseñar la RT2 lo más rápidamente posible.

RETA TERMINAL 2 (RT2)

Por contextualizar un poco, hubo que realizar más trabajo del que se había llevado a cabo en cuatro años, de 2003 a 2007, en sólo uno: de mediados de 2007 a mediados de 2008, porque EKASA tenía muy clara una cosa: había que salir antes del comienzo de liga de 2008-2009.

EKASA, que poco a poco había ido creando los diferentes Departamentos de la empresa, decidió que era hora de crear el Departamento Técnico y en mayo de 2008 me contrataron para ello.

Mi primera responsabilidad fue conseguir, junto al resto de proveedores tecnológicos de EKASA, salir antes del primer partido de liga y después de un enorme esfuerzo por toda la gente involucrada en proyecto: marketing, comercial, trading, tecnología, administración, recaudación, tiendas, … el día 26 de agosto de 2008, martes, hicimos nuestra primera apuesta oficial en producción.

En aquellos tiempos éramos muy, muy poquitos en EKASA y, de todos los Departamentos, el Técnico era el más escueto: únicamente estábamos Álvaro, que todavía sigue con nosotros, y yo. Ni que decir tiene que nos sentíamos muy orgullosos, pero a la vez muy preocupados por lo que se nos avecinaba, porque éramos muy conscientes de que salir a producción no había sido nada más que el principio del camino.

Y luego el Departamento Técnico comenzó a crecer poco a poco. A finales de 2008 éramos ya cuatro, al terminar 2009 éramos seis y cerrando el año 2018, más de 50.

Y los proyectos comenzaron a aumentar en consecuencia: en 2008 no teníamos más de 30 proyectos, en 2009 no serían más de 40 y a finales de 2018, ya teníamos más de 200…y siguen creciendo.

Y algunas de las tecnologías que usamos también fueron evolucionando: de VS 2008 pasamos a VS 2017 (pronto 2019), de VB .NET pasamos a C#, de SQL Server 2005 pasamos a SQL Server 2016, dejamos WCF con HTTPS Binary Binding y nos movimos a RESTFUL WCF, luego transitamos a Webapi y, desde hace un par de años, casi todos los servicios se han hecho en ASP .NET Core. En los frontales web también ha habido cambios: pasamos de VB .NET, Knockout.js y SASS a C#, React y PostCSS.

Y, por supuesto, también los aplicativos han evolucionado: descartamos CAB, nos centramos en WPF y, con el tiempo, comenzamos a utilizar el patrón MVVM.

Nuestra infraestructura tampoco se ha quedado atrás, y más que la vamos a cambiar. Desde un punto de vista cuantitativo, pasamos de tener equipamiento en dos datacenters a tenerlo en seis datacenters; de utilizar poco más de una docena de servidores físicos a tener más de 80 entre físicos y virtuales y de tener una infraestructura muy acotada, de la que nos sabíamos de memoria todas las direcciones IP de todos los elementos, a una en la que ya las tenemos que tener apuntadas en algún sitio.

Y por el camino han ido apareciendo nuevas tecnologías que ya se han hecho o se van a acabar haciendo un hueco en nuestro stack tecnológico: Swift, Kotlin, RabbitMQ, CouchBase, Kafka, Spark streaming, MongoDB, Elastic Search, Kibana, Logstash, Docker, Kubernetes, Redis, ECMA Script 6, …

En fin, que después de 11 años seguimos creciendo; cada día tenemos más proyectos, cada día estos proyectos son más complejos y cada día nos enfrentamos a nuevos retos con la ilusión de saber que, si queremos desarrollar un producto a la altura de lo que demanda el mercado, tenemos que dar lo mejor de nosotros mismos para lograrlo.