Tarugos, microservicios y cintas de video

Esta semana, al comienzo de la irreverente e imprescindible Tarugoconf, David “El Tarugo Jefe” Bonilla se preguntaba ¿qué somos?, ¿qué nos define? pues en la audiencia habría gente de derechas, de izquierdas y mediopuntas rematadores. Al final concluía que lo único que nos unía era el desprecio por el establishment y el status quo.

En K Fund, por supuesto, nos unimos a la lucha contra el establishment (es la única forma de hacer retorno…) pero también queremos que otras cosas unan a nuestras participadas. Cuando me preguntan en qué invertimos, mi respuesta no es por modelo, geografía o importe. Para nosotros los tres pilares de las oportunidades que más nos gustan en K Fund son:

  • Diseño
  • Datos
  • Tecnología.

Estos últimos días han sido un fiel reflejo de esta voluntad.

El miercoles pasado organizamos un evento con Adrian Cockcroft, VP de Amazon Web Services, donde nos expuso su experiencia escalando arquitecturas de compañías como Netflix, Docker o Ebay. En las oficinas de Carto (muchísimas gracias Miguel & Co.) nos mostró su roadmap recomendado para arquitecturas en startups: empezar serverless por razones de coste, rapidez de desarrollo y escalabilidad potencial.

En su charla nos acabó por convencer de que el coste y la complejidad de controlar y gestionar los microservicios no tiene sentido en una fase seed de vuestra compañía, donde aún no tenéis los requerimientos de tráfico y volumen para justificar ese sobrecoste y el tiempo de desarrollo de una solución basada en microservicios.

Si queréis una charla similar de Adrian, recomiendo esta donde explica las ventajas de serverless vs. microservicios.

Cuando nos tenía convencidos de las bondades de optar por arquitecturas serverless, Adrian nos introdujo su otra obsesión: “No puedes legislar contra el fallo” fue el resumen de la siguiente parte de la charla.

Desgraciadamente no puedes prohibir el fallo en tu sistema por ley (aunque gobiernos han tratado de promover leyes obligando a los ciudadanos a ser felices… con poco éxito) sino que debes desarrollar tu sistema para que resista el fallo, pues es inevitable. En ese contexto de producir sistemas resistentes al fallo se enmarca la labor de Adrian en el desarrollo de agentes del chaos (Chaos Monkeys), que son programas que se desarrollan desde el comienzo y en paralelo a tu sistema que permiten simular fallos en instancias, servicios u otros componentes de tu sistema.

Al final estos dos conceptos — no diseñar todo tu producto final antes de tener tracción y crear un equipo y una organización que resista al fallo — son dos conceptos que se pueden aplicar al desarrollo de tu compañía.

Cuántas veces decimos algo como “quiero ser Lean y Agile”… pero luego nuestra arquitectura es monolítica y corre en servidores en el cuarto de baño… o “quiero ser resilente” … pero no me toques el sistema que se cae… la coherencia es la madre de la ciencia!

He empezado haciendo referencia a la Tarugo y me gustaría acabar agradeciendo a mi compañera Carina el momento “Pimpinela” que tuvimos cuando presentamos juntos el funcionamiento de un fondo de venture.

Fue un placer compartir escenario con ella y con todos los asistentes, que la verdad hacen que sea un evento especial… como el CTOs Land donde espero veros el 11 de Noviembre.

P.D. Por favor rellena la encuesta del CTOs Land que estamos preparando un super informe sobre el estado del arte de los CTOs en España y queremos saber vuestra opinión!!