La verdad (y la técnica) detrás de 560.000€

scroll

Este artículo es la segunda parte de la entrevista que me concedió Diego Mariño a propósito de la ronda de financiación de 560.000€ que consiguió Ducksboard, la startup de la que es CEO y accionista.

Mientras que la primera parte se centró en los aspectos más económicos del día a día de una compañía tecnológica, en esta ocasión, hablaremos de la parte más técnica de la misma. Los CEOs «de salón» y los orgullosos poseedores de un MBA por la Universidad de Wichita o Canford pueden sufrir un síncope vasovagal al leer este artículo.

Diego, Ducksboard es el primer proyecto de la era DA -después de Abiquo- ¿Cómo se te ocurrió pasar de algo tan serio y corporativo como el cloud al trendy y bohemio mundo de los dashboards?

La idea original me la venía planteando ya desde la época de Abiquo. Vi la necesidad cuando empezamos a crecer y empecé a tener cada vez menos información de mi propia empresa. Pensé que no debía ser tan complicado eso de ir llamando a diferentes SaaS para traer datos y poder compartirlos con el equipo en una pantalla.

[no_blockquote text=»Vi la necesidad cuando empezamos a crecer y empecé a tener cada vez menos información de mi propia empresa.» text_color=»» title_tag=»h3″ width=»» line_height=»» background_color=»» border_color=»» show_quote_icon=»yes» quote_icon_color=»» quote_icon_size=»»]

Unos meses después de dejar el día a día de Abiquo, nos encontramos en Madrid mi mediohermano Aitor, su colega Jan y yo, con muchas ganas de hacer algo juntos y un hervidero de ideas en la cabeza. Retomé la idea de los dashboards y, finalmente, nos lanzamos, por la capacidad técnica del equipo -lo podíamos afrontar sin ayuda externa- y por la probabilidad de exit. Veíamos clara la posibilidad de venta de la empresa.

El equipo técnico de Ducksboard

Aitor disfruta de su habitual siesta de 3 horas mientras Jan sigue preguntándose porque tiene un teclado delante del portátil

¿Cómo engañaste al equipo técnico?

Con respecto a los fundadores, fue relativamente sencillo. Aitor y yo habíamos trabajado juntos hacía muchos años y teníamos clavada la espinita de montar un proyecto propio, y Jan sólo tuvo que rechazar una MEGAOFERTA económica para seguir desarrollando sus proyectos Open Source de forma sponsorizada.

Para el resto de contrataciones, nos hemos traído a gente con la que ya habíamos trabajado anteriormente. La siguiente incorporación será la primera que hagamos fuera de nuestro círculo más inmediato.

¿Por qué lenguaje de programación y plataforma tecnológica optasteis?

Pues optamos por programar tanto Java y  XML como nos fuese humanamente posible mantener…

Diego, a ver si vas cambiando de broma que esa es muy «de los 90». Actualmente, casi todo en Java se puede configurar con anotaciones en el propio código…

(risas) Vale, ahora en serio, la «lingua franca» de Ducksboard es Python. Tanto nuestro backend, que se encarga de la recopilación y almacenamiento de datos, como nuestro frontend, la aplicación web expuesta a los usuarios, están escritos en Python.

El backend está escrito usando Twisted, un framework para el desarrollo de aplicaciones de red para Python. Gran parte del trabajo del backend es gestionar miles de conexiones concurrentes a cantidad de servicios web y nuestra prioridad era poder escribir esa parte de la aplicación usando código asíncrono. Twisted cubre esa necesidad proponiendo un modelo de programación basado en eventos.

Para la aplicación web estamos usando algo mucho más «mainstream«: Django, un framework MVC en Python muy conocido.

La elección de Python se debe a la experiencia previa con el lenguaje de los dos fundadores técnicos. Nos parece un lenguaje muy expresivo y mantenible.

¿Qué requisitos teníais a la hora de diseñar la arquitectura?

Teníamos muy claro que backend y frontend debían estar totalmente separados. Son aplicaciones independientes, el único punto en común es la base de datos: el backend escribe en ella, el frontend lee de ella.

[no_blockquote text=»Teníamos muy claro que backend y frontend debían estar totalmente separados. Son aplicaciones independientes.» text_color=»» title_tag=»h3″ width=»» line_height=»» background_color=»» border_color=»» show_quote_icon=»yes» quote_icon_color=»» quote_icon_size=»»]

Usamos PostgreSQL. Queremos una base de datos relacional porque nuestro datos son, claro está, relacionales, y su consistencia juega un rol crítico en nuestro servicio. PostreSQL ^_^ PostgreSQL en concreto porque Jan es colaborador del proyecto, y nuestras experiencias previas con MySQL no fueron demasiado buenas.

Eso me recuerda a la anécdota de los figuras de Mint, que tuvieron que contratar a un Administrador de Base de Datos antes de una demo importante porque su MySQL no «iba bien», sólo para descubrir que la habían instalado limitándola al uso de 64MB de memoria… ¿Y encima de vuestra capa de datos que podemos encontrar?

La aplicación como tal tiene tres características principales:

  1. Arquitectura «shared nothing» para poder escalar horizontalmente sin volvernos locos. Los distintos componentes del backend corren como procesos independientes en máquinas separadas. La comunicación entre los mismos se lleva a cabo vía HTTP y los componentes de un mismo tipo se balancean con un Nginx. Al no haber un estado compartido, podemos escalar la aplicación horizontalmente añandiendo instancias tras el balanceador.
  2. Frontend en tiempo real, queda muy chulo, y los datos nunca esperan (risas). Somos de las primeras aplicaciones comerciales en hacer uso intensivo de Web Sockets. El frontend web recibe notificaciones cuando hay datos nuevos sin tener que hacer requests constantes. Usamos RabbitMQ para que los componentes de backend puedan dejar mensajes pendientes de enviar al frontend en un lugar común.
  3. Somos los principales usuarios de nuestra APIs. Usamos las mismas APIs para construir la aplicación que ofrecemos posteriormente a los usuarios. Tanto para empujar datos al backend, como para gestionar tu configuración en el frontend. El frontend, de hecho, es una API JSON en sí mismo, y usamos backbone.js para interactuar con esa API y dibujar los widgets y demás en el navegador del usuario.

Si estás interesado en conocer más sobre la arquitectura y tecnología de Ducksboard, puedes echarle un vistazo a estos slides.

¡66 diapositivas! Una presentación digna de Mordor. Yo suelo pedirle a Jero que me explique todas las decisiones técnicas y aportar todo lo que puedo. ¿Hasta qué punto te involucras tú? ¿Crees que un CEO debe saber lo que está haciendo su equipo técnico?

Para empresas tecnológicas, sin duda alguna. Has de saber lo suficiente como para poder discutir todas las decisiones, pero recordando que la última palabra la tienen ellos.

Como tú comentas, realmente lo que hago es preguntar «¿Por qué?» a menudo e ir comprobando que las decisiones técnicas no limitan las posibilidades de negocio en el largo plazo.

¡Oh! Yo sólo lo hago por irritar a Jero (risas) ¿Y qué herramientas habéis utilizado durante el desarrollo?

Muchas. Te hago una lista:

Vamos, startup de manual…

No tan «de manual» ya sabes que lo trendy es utilizar las herramientas de 37signals (risas).

Me sorprende que utilicéis GitHub en vez de Bitbucket, que también te proporciona repositorios de Git, sobre todo con lo popular que es en la Comunidad de Python… lo de que no hayáis sido capaces de haceros con JIRA, sabes que no te lo perdono. Un día voy a pasar por el Patoplex con el látigo listo para atizar a Jan y Aitor… pero en cualquier caso, no puedo quejarme: debéis ser una de las pocas compañías españolas que pagan licencias…

Ya hemos hablado de la parte financiera y hoy hemos hablado de tecnología, pero aún me queda material para una tercera parte en la que hablar de negocio puro y duro (coste de adquisición de usuarios, canales de venta y demás…) En el anterior artículo, pedimos 20 comentarios para escribir la segunda parte y ¡superamos los 60! Con este va a ser difícil llegar a ese número, porque un contenido tan técnico habrá espantado a mucho emprendedor de Excel y Powerpoint. En cualquier caso, hay que subir un poco el nivel: [highlight]si llegamos a los 40 comentarios, tendréis la tercera y definitiva entrega[/highlight] del Mariño versus Bonilla…

Disclaimer anti-bocachanclas

Soy el orgulloso embajador español de Atlassian, la compañía desarrolladora de JIRA, el mejor gestor de proyectos del mundo mundial de la vida vital. Una herramienta TAN potente (algunos confunden potencia con complejidad) que ni siquiera los cracks técnicos de Ducksboard han podido controlar su poder desatado… ^_^

Bitbucket -mucho «más mejor» y más sexy que GitHub- también es de Atlassian. Que, por cierto, hace poco, también compro HipChat.