Soy César Giospecha, CTO de Jopan Talent. Hoy os voy a contar un poco cuál ha sido
nuestro camino hasta los 5 millones de usuarios que tenemos ahora mismo y qué pretendemos
hacer para llegar a 10 millones a final de año. Como tampoco sé qué audiencia me iba
a encontrar, voy a hacer una charla técnica pero tampoco voy a entrar mucho en detalle
y me reservo para la parte de preguntas para que me preguntéis todo lo que queráis,
entonces podremos profundizar en cualquier parte que queráis. Os explico un poco qué es
Jopan Talent. Jopan Talent nace para revolucionar el mercado del empleo cambiando un poco las
reglas del juego. En lugar de que los candidatos tengan que ir a buscar ofertas de empleo, las
ofertas de empleo van a los candidatos. Tenemos desarrollado un algoritmo totalmente disruptivo
que está hecho 100% aquí en España por nosotros y bueno con él estamos un poco llevando estas
ofertas a todos los candidatos que se han inscrito en nuestro portal. Básicamente ¿cómo
lo hacemos? Por un lado buscamos ofertas de empleo ideales para nuestros usuarios candidatos,
al encontrar la oferta de empleo ideal para el candidato, también encontramos el candidato
ideal para las empresas, para nuestros clientes empresas y luego por otro lado vamos buscando
cómo mejorar la carrera profesional de nuestros usuarios ofreciendo cursos y proponiendoles
ofertas para pasar al siguiente nivel ¿no? Bueno ya basta un poco de explicaros qué es,
os voy a contar un poco los números de Jopan Talent. Esto es la gráfica de crecimiento
de usuarios, podemos decir que empezó el crecimiento exponencial a finales de 2012,
a finales de 2013 perdona y cuando más se ha pronunciado esta curva ha sido a principios
de este año. Ahora mismo estamos en 5 millones de usuarios, todo esto hasta aquí son datos
reales, a partir de ahí es una estimación que es bastante, no es para nada optimista
sino que bueno lo vamos a conseguir. Por otro lado estos usuarios que adquirimos también
vuelven, tenemos un 33% de tasas de retorno que vamos también incrementando mes a mes,
luego nos acaban generando unos 40 millones de páginas vistas, esperamos acabar el año
con alrededor de más de 100 millones y estos usuarios a veces se ponen todos de acuerdo
nuevamente cuando hay un anuncio y vienen todos de golpe y eso nos provoca que de golpe
pasamos a tener 20 veces el tráfico habitual, los retos tecnológicos que supone estos son
inmensos, por eso os voy a explicar un poco las cosas que hacemos. Aunque estos usuarios
vengan así de golpe los queremos mucho y les generamos 18 millones de sugerencias cada
día en total. Bueno, os voy a contar un poquito la historia de Chopin Talent, digamos que
desde 2009 hasta 2013 estuvimos un poco pues encontrando el modelo de negocio y generando
una plataforma que fue estable y a partir de la cual pues poder construir un negocio.
En 2013 teníamos en producción ocho servidores, dos frontales, dos para ejecutar tareas en
background, la base de datos replicada y dos de las tixels también replicados para hacer
búsquedas. Teníamos un esquema bastante clásico de lo que es una aplicación Rails
con la aplicación en si, la base de datos primaria, una réplica por si se nos caía
la base de datos primaria no estar caído mucho tiempo, teníamos la gestión de tareas
en background con Redis y Psykit que es un gestor de tareas en background y todo lo que
era temas de búsqueda lo gestionamos con elasticsearch. En 2015 ahora mismo tenemos más de cien
servidores en producción, 24 frontales que también escalan, cuando va a venir anuncio
ponemos más, 24 utilites que son los que ejecutan tareas en background y entre ellas
pues la generación de estos 18 millones de sugerencias diarias, el algoritmo que es
el que se encarga, tenemos varios algoritmos y estos son los que se encargan un poco de
responder a dar las ofertas para los candidatos. Luego mancatch, bases de datos, elasticsearch
se ha crecido también, monitorización, tenemos RevitMQ que es para un sistema de mensajería
que luego os comentaré, esto ha crecido mucho ahí, la pregunta es cómo hemos conseguido
pasar de 8 servidores a más de 100 servidores, la clave para nosotros ha sido pasar a una
arquitectura de microservicios y aquí viene la cuestión, mucha gente dice microservicios
o monolito, ahora en lugar de llamarle monolito que suena muy mal están empezando a llamar
integrated systems en los que la gente que es muy pro monolito, cuando me preguntan qué
es mejor, una arquitectura de microservicios, una arquitectura basada en monolito, siempre
digo pues que depende, depende del caso, nosotros empezamos con una arquitectura como monolito
y menos mal que lo hicimos así porque si no no llegaría no hubiésemos llegado a donde
estábamos, el monolito te permite poder y te dar muy rápido, poder pivotar muy rápido,
poder sacar nuevas features rápidamente, te da un entorno de desarrollo relativamente
fácil de manejar, pero llega un punto en que es difícil escalarlo, ahí es donde entra
y donde es muy interesante los microservicios, no todos son ventajas, o sea los microservicios
aumentan mucho la complejidad, el entorno de desarrollo se complica, los test de integración
que te permiten saber si todo tu site está funcionando a nivel global también son más
complicados, pero a cambio te facilitan por un lado escalar los equipos y por otro lado
escalar la base de datos, que es el punto más crítico a la hora de escalar sistemas.
Otros más o menos ahora, esto es lo que tenemos en producción, todos estos servicios, alrededor
de 12 servicios, clases distintos de bases de datos para cada servicio, aplicaciones nativas
iOS y Android, tenemos diferentes clases de elastic sets, unos para operación, para búsquedas
de ofertas de candidatos y otros para logs, para ver qué está pasando en nuestra plataforma,
el habit en queue que lo usamos para mensajería y estamos empezando a hacer pruebas con nuevos
bases de datos como DynamoDB y hemos probado MongoDB, luego puedo profundizar en esto más
adelante si estáis interesados.
Me gustaría comentaros un poco desde la perspectiva de Jopan Tallen, qué ha sido importante
tener en cuenta de cara a crear una arquitectura de microservicios, para nosotros los puntos
clave han sido que nos ha permitido desacoplar servicios, hemos tenido que trabajar mucho
en la comunicación y la coordinación de estos servicios y prestar mucha atención
a la gestión de base de datos, la Cache y la automatización de todos los servicios.
Desacoplar servicios, cuando empiezas a plantear una arquitectura en microservicios, partiendo
de una aplicación monolítica, siempre tienes la tendencia de decir, bueno, este código
que voy a utilizar en este servicio y en este otro que es muy similar, ¿por qué no lo
comparto, no, creo otra librería que lo comparta, qué tal, eso suele ser un problema, no hay
que tener miedo a repetir código, a copiar código, sobre todo cuando se ve claro que
va a evolucionar, que va a tener su evolución, porque muchas veces le añadir casuísticas
para intentar gestionar todos los casos que particulares de cada servicio, acabas teniendo
librerías que no son para nada mantenibles, y luego otra cosa muy importante es que entre
los servicios no deberían compartir la base de datos, cada servicio tiene que tener la
responsabilidad de escribir en una base de datos, porque si empiezas a escribir en base
de datos desde diferentes servicios, estás un poco perdiendo toda la lógica de negocio
que quieres aplicar y puedes conseguir inconsistencias en la base de datos, ¿no?
Estos servicios que se van creando es muy importante definir una manera en la que se
van a comunicar entre ellos, ¿no?
Básicamente, hay dos necesidades de comunicación entre los servicios, la comunicación síncrona
y la comunicación asíncrona, la comunicación síncrona, nosotros la gestionamos mediante
APIs, que es cuando necesitamos un dato de un servicio en ese mismo momento y no nos
podemos esperar, pero siempre intentamos todo lo posible utilizar comunicación asíncrona
para que, para también al final desacoplarlo todo, ¿no?
Y ahí es donde entra un juego en MessageBass, que es lo que es el sistema que utilizamos
para comunicar, para comunicar intraservicios eventos, ¿no?
Como un ejemplo, tres servicios que tenemos en nuestra plataforma son la web en si, donde
hay todo el registro de los candidatos, el servicio que genera todas las sugerencias
a los candidatos y luego también tenemos otro servicio que se encarga de indexar esos
candidatos en un elastic set, ¿vale?
Tenemos muchos más.
Cuando se registra un candidato en nuestro site, se lanza un mensaje a través de MessageBass,
que es candidate create, y se pasa la serialización de ese candidato, o sea, el candidato en sí
en ese mensaje.
Ese mensaje, por un lado, lo está escuchando el generador de sugerencias y coge y genera
sugerencias para ese candidato.
Y por otro lado, está escuchándolo el indexador del elastic set y coge ese candidato y lo indexa
en el elastic set.
Si lo hubiésemos tenido que hacer con APIs, tendríamos que, cuando el usuario se registra,
está haciendo una llamada a generar sugerencias y otra llamada elastic sets, y cuando añadamos
otro servicio que también quiera hacer cosas con la generación de cuando se crea un usuario
como, por ejemplo, enviarle un e-mail, tendríamos que volver al código ese y añadir, y añadir
también, pues, avísame a este otro nuevo servicio de que se ha creado un usuario.
De esta manera, todo se puede ir creando nuevos servicios, se puede ir gestionando servicios
de manera más desacoplada, es importante.
Por final, todo el sistema tiene un cuello de botella, y en nuestro caso, y el cuello
de botella más habitual es el de la base de datos.
En esta línea, nosotros lo que hemos trabajado mucho en intentar crear cada servicio que íbamos
creando, que se llevan sus tablas de la base de datos principal a su servicio, quitándole
carga a la base de datos principal, pero también hemos trabajado mucho en desnormalizar muchos
datos cuando al principio tienes muy pocas peticiones, pues, evidentemente, lo puedes
calcular, puedes contar cuántas ofertas han inscrito un candidato, todo al vuelo y no
pasa nada.
Pero llega un momento en que todas esas queries te están colapsando la base de datos, y aunque
vaya un poco en contra de lo que a un ingeniero le enseñan en la universidad, que es a tener
lo todo normalizado y todo separadito y los datos no repetidos, si sigues eso, te caes,
se cae la base de datos.
Entonces, hay que empezar a desnormalizar y guardarte, pues, por ejemplo, que este candidato,
cuando se inscriba una nueva oferta de empleo, pues decirle que aparte de guardarle la redacción
a esa inscripción, sumarle el contador de ofertas de empleo a las que ha aplicado, sumarle
uno.
Luego, lo que os comentaba que es muy importante tener una base de datos por servicio que encapsule
toda su lógica y que la saque de lo que es la base de datos principal de la que partía
el monolito.
Y luego, otra clave es utilizar siempre bases de datos de réplicas, de bases de datos de
lectura que te permitan sacar la máxima carga posible del máster.
La idea es que en los principales sistemas de bases de datos racionales solo puedes tener
un máster todo esto con muchas comillas, pero puedes tener entre comillas también infinitas
réplicas de lectura.
Entonces, si consigueses llevar el 98% de tus queries a las bases de datos, a las réplicas
de lectura, pues ya escala tu aplicación prácticamente sola, pero bueno, esto es también muy difícil.
El tema es que no solo hay que invitar a hacer peticiones a la base de datos máster,
intentar enviarlo todo al esclavo, sino lo que ya es genial es no hacer ninguna petición
a la base de datos, ¿no?
Cachearlo.
Una regla importante es tener, intentar que te recache por todos lados, ¿no?
Nosotros en Jopantal en ahora mismo dividimos nuestra cacha en dos cosas, por un lado tenemos
cacheado todos partes de HTML que utilizamos memcache para guardar ahí HTML ya generado
y por otro lado tenemos datos que usamos mucho, los cacheamos en Redis que nos permite tener
un poco más de una estructura un poco más lógica y podemos sacar datos mucho más fácil,
¿no?
Intentando no tocar las mínimas veces posibles la base de datos.
Bueno cuando tienes cien servidores, si pretendes hacer montar cada servidor a mano, está bastante
jodido, ¿no?
Es clave cuando pienses en una arquitectura de microservicios que al final vas a tener
muchos servidores más grandes o más pequeños, es muy importante intentar automatizarlo, automatizarlo
todo, escriptar todo lo que es la creación de todas las máquinas, ¿no?
Nosotros usamos Ansible para hacer esto porque lo encontramos simple y tenemos la máxima
de intentar tenerlo todo lo más simple posible y nos está funcionando muy bien.
Y bueno, según nosotros, cuál ha sido el secreto para poder haber conseguido pasar
de servir peticiones a 300.000 usuarios con una arquitectura monolítica a estar sirviendo
a 5 millones de usuarios con una arquitectura de microservicios y durante ese tiempo seguir
sacando nuevas fichas porque somos una compañía que estamos muy enfocados, sobre todo también
desde el equipo técnico a negocio y queremos siempre seguir aportando a negocio funcionalidades,
¿no?
Y cuál ha sido la clave para todo esto?
Es mucho trabajo y mucho talento y entonces en final es el equipo, ¿no?
Todos tenemos como una máxima que intentamos siempre fichar gente muy buena y gente muy
maja, ¿no?
De manera que es muy fácil trabajar con ellos y se crea un ambiente de trabajo pues muy
bueno, ¿no?
Ahora mismo tenemos alrededor de 30 ingenieros que trabajan mucho, bueno, a veces se disparan
y esas cosas, ¿no?
Y bueno, y seguimos fichando gente, si alguien está interesado pues me puede escribir.
Y bueno, todo esto es muy bonito pero no lo es tanto, o sea, hemos hecho un primer paso
hacia la arquitectura, sabemos hacia dónde queremos ir pero todavía nos queda mucho trabajo
por hacer, ¿no?
El monolito todavía está ahí, todavía hay que sacar muchísimos servicios de ahí, todavía
hay que sacar muchas cosas, ¿no?
Nuestro principal, nuestros principales retos de cara a los próximos meses, los próximos
años es ir añadiendo nuevos microservicios que nos permitan por un lado seguir escalando
equipos y seguir escalando nuestra plataforma, principalmente los servicios que hemos sacado
ahora son los más obvios, ¿no?
Tenemos por un lado lo que es la parte web del candidato, tenemos por otro lado la parte
web de las compañías, tenemos por otro lado lo que te genera sugerencias, tenemos un servicio
que te guarda acciones que hacen los candidatos, tenemos por otro lado también el indexador
en las tixas que ya os he comentado, bueno, notificadores, también tenemos también importamos
ofertas de empleo de partners, tenemos también un sistema de importación, bueno, pero ahora
nos falta hacer el siguiente paso que es extraer en APIs lo que es el acceso a los datos más
correo de la compañía, ¿no?, sacar APIs de acceso a ofertas de empleo, APIs ya internas,
ya no APIs que salen al exterior, a las aplicaciones y bueno, a los candidatos.
El objetivo al final es ser capaces de poder escalar horizontalmente cualquier servicio,
o sea, ahora mismo al final tenemos, somos capaces de escalar lo que son los servidores
de aplicaciones, podemos ir añadiendo un montón de servidores de aplicaciones y aguantaríamos
a más gente, pero esa gente al final no tendría datos porque llegaría a la base de datos le
diría estoy a tope de proceso, no puedo hacer nada, ¿no?
Y en esa línea todavía tenemos mucho trabajo que hacer para ser capaces de escalar totalmente
nuestra capa de datos, principalmente vamos a empezar nuestra fase de hacer sharding para
poder escribir a la vez más de un servidor master y por último lo que queremos, o sea,
nos da mucha envidia los tiempos del monolito en el que desarrollar era relativamente fácil
en los que podías hacer cualquier query a la base de datos y no pasaba nada.
Ahora, según qué query haces a la base de datos, pues, un, error 500, que añoramos
los tiempos, ¿no?
Entonces, estamos trabajando en tanto generar tooling como simplificar el acceso a estas
fuentes de datos para ser capaces de volver a ese entorno en el que no sea tan difícil
y no sea tan peligroso según qué acciones que se hacen en desarrollo, ¿no?
Estamos también trabajando probando nuevas fuentes de datos, hemos hecho pruebas con
DynamoDB, que es una base de datos en el SQL de Amazon que nos está funcionando bastante
bien, queremos seguir probando con Cassandra, hemos hecho cositas con Mongo, bueno, estamos
intentando pues llevar las nuevas tecnologías que son Production Ready ya a nuestra plataforma.
Bueno, ha ido un poquito rápido por todo porque no sabía tampoco la, no sé qué perfil
tenéis y bueno, o sea, sería si tenéis alguna pregunta o queréis que suscundíste en alguna